Edit a published agent safely by working in draft, understand graceful handover for in-flight runs, apply low-risk vs. high-risk changes, and coordinate schema changes with upstream systems.
Editing without affecting the live version
When you open a published agent in the visual editor, Cotonity automatically creates a new draft based on the current published version. All edits you make apply only to the draft — the live agent continues running the published version unaffected. You can see the draft/live split at the top of the editor window: a badge shows which version is currently live and how many pending changes are in the draft. This means you can freely experiment, test, and revise the agent logic without any risk to ongoing runs or incoming triggers.
Running in-flight completions
When you publish a new version of an agent that has concurrent runs in progress, Cotonity does not kill those runs. By default, in-flight runs continue to completion using the version they started with. The new version takes effect for all runs that start after the publish event. This behavior is called graceful handover and ensures that no run is left in a half-executed state due to a mid-run version change. You can observe the handover in the Live Runs panel: runs from the old version are labeled with the previous version number, while new runs show the updated version.
Safe change patterns
Some changes to a live agent carry higher risk than others. Low-risk changes include refining prompt wording, adjusting retry counts, updating notification text, and adding new optional enrichment steps. Higher-risk changes include altering the trigger schema (which may break incoming payloads from external systems), renaming or removing steps that downstream steps reference, and changing the output schema of an LLM node that feeds structured data into later actions. For high-risk changes, use the traffic-splitting deployment pattern described in the Deploying agents to production article to validate the new version on a small percentage of traffic before full rollout.
Coordinating with external systems
If your agent update involves a change to the webhook payload schema — for example, you are adding a required field that the upstream system must now send — coordinate the change with the team managing that upstream system. Deploy the new agent version in a backward-compatible way first (accepting both the old and new schema shapes) and verify it works correctly before asking the upstream system to start sending the new field. Once all incoming traffic uses the new schema, you can remove the backward-compatibility logic in a follow-up update. Document schema changes in the agent's description field for future reference.