Kata CI GuidePublish and versions
Ship agent changes deliberately, with drafts, versions, and a quality gate.
Agents follow a draft and publish model, the same way serious software ships releases. Users never see your work in progress.
How the lifecycle works
Edit freely. Every change you make (prompt, models, features, skill and knowledge bindings) stages into the agent's draft. The running agent keeps serving its last published version, untouched.
Test the draft against real scenarios: actual documents, actual questions, the awkward edge cases users will find on day one. Match the depth of testing to the risk of the work.
Publish. Publishing promotes the draft to a new immutable version and makes it live. A first publish also activates the agent, making it visible in Chat.
Every publish creates a version, so an agent's history is a sequence of deliberate releases rather than a drift of untracked edits. The agent page header shows the live version number, and History lists every prior version.
One nuance to internalize: channel and app changes bypass the draft and apply immediately, because they are connections rather than content. Everything else (instructions, models, features, skill and knowledge bindings) waits for your publish.
The publish gate
Publishing triggers an automated evaluation of the agent. The gate catches regressions before users do: an agent that suddenly fails scenarios it used to pass is a problem you want at publish time, not in production conversations. Results land with the rest of your quality signals; see Improve your agents.
Practical release habits
- Stage boldly, publish deliberately. The draft is free; a publish is a release with users on the other end.
- Batch related changes into one publish so versions correspond to meaningful releases, which makes "what changed" answerable later.
- After publishing, watch. The first hours of real traffic tell you more than any rehearsal. Traces and feedback are your release monitor.