> ## Documentation Index
> Fetch the complete documentation index at: https://docs.voiceinfra.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Drafts, Publishing and Rollback

> Editing an agent never changes what your callers hear. Save your work as a draft, preview it, publish when you are ready, and roll back if you change your mind.

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:

| Chip | Meaning |
| - | - |
| **Published** | The live version and your edits match. Callers get exactly what you see. |
| **Draft** | You have changes that are not live yet. Callers still get the last published version. |

## 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

<Note>
  **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.
</Note>

## Editing and publishing

<Steps>
  <Step title="Make your changes">
    Edit the agent, its functions, its knowledge base attachments, or its workflow. The status chip switches to **Draft**.
  </Step>

  <Step title="Test it">
    Use **Test Call** to speak to the draft exactly as a caller would. Adjust and repeat until it sounds right.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

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

| Resource | Versioned |
| - | - |
| Agents | Yes — including their workflow nodes, edges, and attachments |
| Functions | Yes |
| MCP servers | Yes |
| Call widgets | Yes |
| Knowledge base documents | No — changes take effect when they are added or removed |
| Phone numbers | No — routing changes take effect immediately |

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.

<Warning>
  Discarding a draft cannot be undone. If you might want the changes back, publish them instead — you can always roll back afterwards.
</Warning>

## 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.

<Tip>
  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.
</Tip>

## Frequently asked questions

<AccordionGroup>
  <Accordion title="Do I have to publish to test?">
    No. Testing always uses the draft, so you can hear your changes before publishing. Live callers are unaffected until you publish.
  </Accordion>

  <Accordion title="Does publishing interrupt calls in progress?">
    No. Calls already connected finish on the version they started on. New calls get the new version.
  </Accordion>

  <Accordion title="Can I edit something after publishing it?">
    Yes. Any edit puts the resource back into **Draft**. Publish again when you are happy, and the change becomes the next version.
  </Accordion>

  <Accordion title="What happens to my changes if I roll back?">
    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.
  </Accordion>

  <Accordion title="How many versions are kept?">
    Every published version is kept in the history.
  </Accordion>

  <Accordion title="Why can't I publish my agent?">
    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.
  </Accordion>
</AccordionGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.