Build an agent by describing it
The Builder is a chat at app.kelam.sh that can read and write your workspace. You say what you want the phone to do; it writes the configuration, the instructions and any tools, deploys the agent, and hands you something you can call. You never have to learn a field name.
Your first build
Open the Builder and type what you want. It runs a short interview — direction, tone, languages, escalation, a name — mostly as tappable options rather than a wall of questions. Answer briefly, or say "just make it" and it'll pick sensible defaults and build.
You Build a booking agent for my clinic. Kelam A couple of things and I'll build it. Should it answer your line, or call people? [ Answers ] [ Calls out ] [ Both ] Voice — what should it sound like? [ Warm ] [ Brisk ] [ Formal ] English only, or Spanish and French too? [ English ] [ All three ] You Answers. Warm. All three. Kelam Built clinic-desk and put it on +1 (978) 274-3508. It greets in the caller's language, books cleanings, reads the appointment back before confirming, and offers to transfer urgent calls. Want to try it?
Two things happened there: an agent was created, and it was deployed. There's no separate publish step to remember.
Writing a brief it can build from
The Builder is good at filling gaps, but the difference between a passable agent and a good one is in what you tell it. Cover these:
| Who's on the line | Customers? Suppliers? People who don't know they're getting a call? It changes the pacing and the opening line completely. |
| What counts as done | "A booked slot with a name and a time." "A yes/no on whether they stock it." Give it a finish line, not a topic. |
| What it must never do | Quote a price, promise a refund, give medical advice, keep someone on the line. Say so explicitly. |
| The escape hatch | Where does a call go when the agent can't handle it — your mobile, a colleague agent, a message you'll read later? |
| Facts it needs | Hours, address, price list, the booking link. Paste them, or attach a document — it can read one. |
A brief that covers those five in four sentences beats a page of prose.
Things you can reference in the chat
- @ an agent to point at one you already have — "make @front-desk hand emergencies to @on-call".
- # a call to talk about a specific conversation — "listen to #call and tell me why it ended early".
- Attach a file — a screenshot, a price list, a PDF of your FAQ. It reads it and builds from it.
Correcting it
You improve an agent by saying what was wrong, in the same chat. Each accepted change is a new version, deployed in seconds. Corrections that work well:
"It rambles — two short sentences per turn, max." · "Always spell the name back." · "Stop offering times we don't have."
"Warmer voice, a bit slower." · "It jumps in too fast when I pause." · "Drop the office background noise, make it a quiet line."
"Let it text people the address after it books." · "Give it a way to reach me mid-call." · "It should be able to press 2 through phone menus."
"Listen to the last call and fix whatever made the caller repeat themselves." — it can read the transcript and act on it.
Fastest loop there is: talk to it in the browser → say what was wrong → talk to it again. Browser calls have no telephony cost, so iterate there and save the phone for the final check.
The agent's page
Every agent has its own page. What each section is for:
| Overview | Its number, its status, what it's for, and what it costs so far. |
| Talk to agent | A real conversation in the browser over WebRTC. Steer this one call, or start it in another language, without changing the agent. |
| Recent calls | Every call, with recording, transcript, per-turn timings, cost and extracted fields. Flag a bad one for review. |
| Callers | Who may call it. Open to anyone, or an allowlist. |
| Tests | Its test suite and past runs — text-only assertions and real $0 voice tests. |
| Experiments | A/B two versions on live traffic and see which actually wins. |
| Context | The facts it carries into every call, editable in place. |
| Files | The actual agent.yaml, scenarios and tools — the same files the CLI pulls. |
| Compiled prompt | Exactly what the model sees at call time: the assembled system prompt and the tool list. The place to look when behavior surprises you. |
The workspace-level nav has the rest: Calls across every agent, Memory, Test runs, Members, and Usage.
Memory
The Memory page is the three context lanes in one screen — what the whole workspace knows, what each agent knows, and what each agent remembers about each caller. All editable by hand.
This is the fix for two very common complaints. "It keeps asking for my address" — put the address in the workspace lane. "It doesn't remember me" — check the caller lane; that's where what it learned about someone lives, and you can seed or correct it directly.
Tests and experiments, without writing YAML
Ask for them. "Add a test that it never invents an appointment." writes the test file and runs it. "Try a warmer voice against the current one and tell me which books more." sets up the experiment, splits real traffic, and reports when there's enough data to say something honest.
Both are the same underlying things the CLI drives, so a test written in the Builder shows up in your pulled folder and runs in CI if you want it to.
When to drop to files
The Builder is not a walled garden — it edits the same files the CLI pulls. Move down a level when you want:
- Version control — agents reviewed in pull requests like any other code.
- Real tools — Python that talks to your systems. You can ask the Builder to write one, but if it needs your internal auth or a library, write it yourself.
- Volume — a few hundred calls from a shell loop, or a nightly job.
- Your coding agent — Claude Code or Cursor driving the whole loop. See coding agents.
$ kelam pull clinic-desk # the Builder's agent, now as files on disk $ kelam push clinic-desk # your edits, back as a new version
Nothing is lost either direction. Pull an agent, edit it in an editor, push it back, and the Builder picks up right where you left off.