Publish
By the end of this page your system will have a production version — the prerequisite for deploying it.
Prerequisites
- A system you’ve tested in the builder (Test the MAS).
- No unsaved changes.
- Admin or Developer role.
Save and publish are different
| Action | What it does |
|---|---|
| Save | Writes your configuration into a draft version. Safe to do constantly; the live deployment is untouched. |
| Publish | Promotes that draft to production — an immutable snapshot that deployments can run. |
The header badges track this: New before your first save, v2 • DRAFT for an unpublished draft, and Prod: v1 for the live version. You can hold a draft and a production version at the same time — that’s how you iterate safely on a deployed system.
Publish a version
Save first
Publish is disabled while the Unsaved badge shows (“Save changes before publishing”) and before any draft exists (“Save first to create a version”). Click Save.
Click Publish
The dialog is titled Publish Conversation Router — “This will create an immutable version snapshot and make the router available for production use.”
It runs a check first and shows the result inline.
| Result | Meaning |
|---|---|
| ”Configuration is valid” | Nothing to fix. |
| Warning | You can publish anyway, but read it first. |
| Error | Publish stays disabled until you fix it. |
The checks are:
- “Conversation router requires at least one specialist agent” — error. Add a member.
- “Default action is set to route to a fallback agent but no agent is selected” — error. Pick a fallback agent.
- “Fallback agent is not a member of this router” — error. The nominated agent was removed; choose a current member.
- “Agent has no skills — routing accuracy will be poor” — warning. The router has nothing to match that member on.
Confirm
Click Publish. You’ll see “Published version N”, the Prod: badge updates, and the previous production version is retired.
A published version snapshots the router configuration and the member list — which agents are in the system, their order, and their per-agent settings. It does not freeze the agents themselves: each member runs its own latest published version, resolved every time the system runs.
So the two kinds of change behave differently:
| You change | To make it live |
|---|---|
| A member agent — its skills, prompt, tools | Publish that agent. The system picks it up automatically; no need to republish the system. |
| The system — router prompt, default action, handoff, LLM settings, which agents are members | Publish the system, then point the deployment at the new version. |
Discard a draft
When a draft isn’t worth keeping, open the ⋮ menu and choose Discard Draft. The draft is deleted and the builder reloads from the production version, so the system returns to exactly what’s live. You’ll see “Draft discarded”.
The ⋮ menu only appears when there’s a draft to discard over an existing production version.
Discarding a draft can’t be undone. Anything in that draft and not in the production version is gone.
The safe iteration loop
- Edit and Save — the production version keeps serving traffic.
- Test the draft in the preview.
- Publish when you’re happy, or Discard Draft to abandon the attempt.
- Update the deployment to the new version — see Deploy.
Common issues
- Publish is greyed out — Unsaved changes, or no draft yet. Hover for the reason and click Save.
- The dialog lists an error — Fix it in the builder, save, and reopen. Errors block publishing; warnings don’t.
- The system state still reads DRAFT on the list — Reopen the list; the state moves to Published once a version reaches production.
- My member agent’s change isn’t live — The member’s new version is probably still a draft. Publish that agent to production; the system then picks it up on the next message.
Next
- Deploy — put the published system behind a URL.