Agents
The agent editor and lifecycle, from drafting and saving to validating, testing, and publishing.
An agent is one language model, one system prompt, and a flat list of tools it can call during a call. There is no diagram to draw and no visual builder: the prompt describes who the agent is and how it should behave, the tools give it things it can do, and the model decides turn by turn what to say and which tool to reach for. Voice and text agents share the same brain, so what you build here serves both surfaces.
Agents are inbound only. The agent answers calls and chats that come to it; it never dials out or starts a conversation.
A workspace can hold many agents, each its own slot with its own prompt, tools, voice, and phone numbers. You build each one in the agent editor.
How the editor is laid out
The editor is a sectioned form, not a visual builder. The left rail lists every section, grouped by what you are doing. Each section autosaves on its own, and each one has its own page. Most have a dedicated guide linked below.
Build
- General sets the agent name, description, and the timezone the agent reads the clock from on a call. The description also shows on a shared demo link.
- Prompt is the persona and the rules. The model reads it on every turn, so it is your largest lever.
- Tools are what the agent can do during a call: look up an order, book a meeting, transfer to a human. Per-tool filler phrases live here too.
- Variables are tokens like
{{booking_url}}that fill into tool URLs and headers at call time. Secrets are stored encrypted and never shown back in full. - Knowledge holds documents, web pages, and notes the agent draws on during a call. Voice and text agents share the same knowledge.
Voice and model
- Voice is how the agent sounds: voice, speed, emotion, and language.
- Model is the language model that powers the agent.
- Conversation controls how the agent speaks and behaves on a call, including turn detection, pronunciation, and the default filler phrases. Covered in Voice and fillers.
Deploy
- Phone routes inbound numbers to this agent. Numbers are bought at the workspace level and assigned here.
- Share mints a public demo link anyone can open. It is covered below under Sharing a demo link.
Compliance
- Privacy sets per-agent call retention and PII redaction, overriding the workspace defaults.
Danger zone
- Archive archives the agent (reversible) or deletes it permanently. See Archiving and deleting.
Saving
Most edits autosave. Each section owns its own save: type a prompt change or edit a tool and it saves the moment you stop. There is nothing to click.
Two moments force a save right away rather than waiting for the debounce:
- Pressing Cmd/Ctrl + S flushes every pending edit immediately.
- Opening the test panel or publishing flushes pending edits first, so what you test or ship is exactly what you have written.
Saving is not the same as going live
Saving writes to your draft. Edits do not reach callers until you publish.
Drafts, versions, and publishing
Every agent has versions. At most one version is published at a time: the live configuration callers actually reach. Everything you edit in the sections above edits a draft, which is the working copy. Publishing promotes that draft to live.
The version control sits at the top of the Build group in the rail. It reads
the current version and its status, for example Version 1 · Live, and it is
where you create and publish versions:
- On a published version, the action is Create draft. A published version is read-only, so to change a live agent you create a fresh draft from it, make your edits, then publish again.
- On a draft, the action is Publish. This runs the validator first and, if nothing blocks, promotes the draft to live.
Versions are immutable once published, so each publish is a clean snapshot you can point back to.
What the validator checks
Before a draft can publish, the validator runs. It is the single source of truth behind the readiness dots on the rail, the badge on the publish control, and the publish refusal itself, so what you see while editing is exactly what the publish gate enforces. Issues come in two severities:
- Errors block publishing. The publish is refused and the blocking issues are listed, each with a link straight to the section that needs fixing.
- Risks do not block. They flag a known weak spot so you can fix it or acknowledge it and ship anyway.
A few representative checks:
| Severity | Example check |
|---|---|
| Error | The prompt is empty, or references a variable you have not added |
| Error | A tool has a duplicate name, points at a missing prerequisite, or sits in a prerequisite loop |
| Error | A variable used by the agent has no value, or holds a placeholder |
| Error | No voice is selected |
| Error | A disclosure is switched on but its line is blank |
| Risk | No way to transfer to a human, or no way to end the call cleanly |
| Risk | A tool runs with no filler phrases, so the caller hears silence |
| Risk | The knowledge search tool is on but no sources are ready |
| Risk | The most recent run of a test failed |
The validator runs everywhere a draft can be changed, not just in the editor, so the same rules apply whether you edit by hand, through the Builder Chat, or over the API.
The Builder Chat
The right rail is the AI editor, the Builder Chat. Describe what you want in plain language, for example "add a tool that looks up an order by reference number", and it makes the change against the same controls you would use by hand. It runs in three modes:
- Plan reads the agent and proposes a plan. It makes no changes.
- Review proposes each change and waits for you to approve it.
- Auto applies changes immediately.
Secrets never reach the model. When a change needs a secret value, the Builder Chat asks you to type it into a passive dialog; the value goes straight to encrypted storage and is never sent through the chat. Your chat history is saved per agent, so you can pick up where you left off.
The Builder Chat edits the draft. Its changes are subject to the same validator and the same publish step as anything you do by hand.
Testing before you ship
Open the test panel and talk to the agent before any caller does. On desktop it is a side rail; on mobile it is a chat button. Because this is an inbound agent, the agent greets you first, the same way it would answer a real call.
The test panel is never blocked by the validator. Only publishing is gated, so you can test a half-finished draft freely. Iterate on the prompt and tools until the agent behaves correctly on every call, not just most of them. Reliability is the bar. For repeatable, graded testing across many scenarios, see Evals.
Sharing a demo link
The Share section mints a public URL anyone can open without signing in. Visitors see the agent's name and description and can start a short voice call. The link always serves the agent's current state, published or draft, so editing the prompt updates the demo on the next call with no need to republish or attach a phone number.
The public surface is deliberately constrained:
| Limit | Value |
|---|---|
| Maximum call length | 3 minutes |
| Maximum turns | 30 per call |
| Rate limit | 10 starts per IP per 10 minutes |
| Bot check | Vercel BotID |
Revoking the link sets it back to private and kills the URL. Re-enabling mints a fresh slug, so any link that leaked stays dead.
Archiving and deleting
The Danger zone holds the two lifecycle actions:
- Archive is reversible. An archived agent stops taking calls and drops out of the main list, and you can restore it later.
- Permanent delete removes the agent for good. Use archive unless you are certain.
Related
- Core concepts for how agents fit the wider platform.
- Transcripts and analytics for what happens after a call.
- Workspace and members for who can edit an agent.