Skip to main content
VoiceInfra separates what you are editing from what is live. You can change an agent’s greeting, prompt, voice, functions, or workflow at any time without affecting the callers talking to the current version. You will see a status chip on the agent telling you which state it is in:

​
Why drafts matter

Without drafts, every keystroke in the agent builder would change a live phone line. With them, you can:
  • Rewrite an agent’s instructions over several sittings and publish once, deliberately
  • Test the draft by voice before anyone else hears it
  • Change your mind and throw the draft away without touching production
Testing uses the draft; live calls use the published version. That is the point of the split — Test Call lets you hear your changes before you commit to them.

​
Editing and publishing

1

Make your changes

Edit the agent, its functions, its knowledge base attachments, or its workflow. The status chip switches to Draft.
2

Test it

Use Test Call to speak to the draft exactly as a caller would. Adjust and repeat until it sounds right.
3

Review what changed

Before publishing you can review the differences between your draft and the live version, including changes to what the agent has attached.
4

Publish

Click Publish. You can give the version a label and a change summary so the history reads well later. The new version goes live for new calls immediately.
Calls already in progress are not interrupted. They finish on the version they started on, and the next call picks up the new one.

​
What gets versioned

Attachments are versioned with the agent, so you can see when a function, MCP server, or document was added to or removed from an agent as part of a publish.

​
Version history and diffs

Every publish creates a version. Open View version history on a resource to see the list, newest first, each with its label, change summary, author, and date. From the history you can:
  • View a version to see the configuration as it was
  • View diff between any two versions to see exactly which fields changed
  • Roll back to an earlier version

​
Rolling back

Roll back restores an earlier version’s configuration. It does not rewrite history — the restored state is published as a new version, so you can see that a rollback happened and roll forward again if needed.

​
Discarding a draft

If you decide against your changes, discard the draft to throw them away and return the resource to its last published state. The forms on the page are re-filled from the restored version, so what you see matches what is live.
Discarding a draft cannot be undone. If you might want the changes back, publish them instead — you can always roll back afterwards.

​
Publishing resources that depend on each other

Agents depend on other resources: a workflow node can call a function, and an agent can have functions and MCP servers attached. Publishing checks those dependencies, because publishing an agent that points at an unreleased function would put something live that you have never tested end to end. Before an agent can be published, every function and MCP server it depends on must be:
  1. Published — it has a live version, not just a draft, and
  2. Free of pending changes — it has nothing unpublished sitting on top of that version
If either is untrue, publishing is refused and you are told exactly which resource is blocking you. Publish the dependency first, then the agent.
A function that is only ever meant to run before or after a call cannot be attached to a workflow tool node, because tool nodes run mid-conversation. Publishing tells you when this is the problem.

​
Frequently asked questions

No. Testing always uses the draft, so you can hear your changes before publishing. Live callers are unaffected until you publish.
No. Calls already connected finish on the version they started on. New calls get the new version.
Yes. Any edit puts the resource back into Draft. Publish again when you are happy, and the change becomes the next version.
Rollback replaces the current configuration with the version you chose. If you had unpublished changes, they are replaced too. Rolling back is itself a new version, so you can roll forward again.
Every published version is kept in the history.
Almost always a dependency: a function or MCP server the agent uses is unpublished, or has unpublished changes of its own. The message names the resource. Publish it first, then publish the agent.