Versions, testing and going live

Why it matters#

You can test a change while people keep using the version that works, and put an earlier version back if the new one doesn't hold up. A script or function can't go live over an operation that has never worked, so a broken connection shows up before people rely on it.

When a change reaches people#

An agent version records the five prompt fields, the model, the reply language, the name, the script text, the resources the agent may use, and its schedules with their briefs. It names the functions and widgets the agent uses, never a version of each, so the agent always calls the published one.

Over the admin MCP server, what the agent says and what it may use are two histories, agent_config_versions and agent_config_admin. An agent answers nobody until a version is active on both, and an edit there must say stage or activate. There is no default.

Activating#

An agent has at most one active version per environment, for everyone, so you can't keep one group of people on an older version. A new agent starts with version 1 and nothing active. A conversation moves to the new version on its next turn, and a script run already under way keeps the script version it started with.

Activation is refused when the version can't run as recorded: something it uses was deleted or switched off, or its model isn't served in your org's region. The go-live gate below can refuse it too.

Schedules are versioned. Creating, deleting, enabling or retiming a schedule, or changing its brief, takes effect when the version holding the change is activated, so a removed schedule keeps firing until then.

Tested status#

Every operation is Tested when a successful call to it is on record since its last lapse, and Untested otherwise. Any successful call counts, from a test or from real use, including one that returns nothing. The status shows on the connection's Operations and Tools tabs, and Monitor → Resources lists "Enabled operations not yet tested".

Tested status lapses only on evidence of change, never on a timer:

• The operation is registered again with a different method, path or parameters.
• Its connection gets a different base URL or credential. A routine token refresh doesn't count.
• A successful call breaks the output shape it had established.

A lapse stops nothing that's already live. The next successful call makes the operation tested again.

Contract breaks

A field an operation returns is established when the connection declares it required, or when it came back on every one of at least 20 successful calls. A contract break is a successful call that returns without an established field, or with it as a different type. A new field or an empty list is never a break.

A break marks unusable every live script, function and agent that reads that field, lapses the operation, and re-runs the stored test parameters of everything whose live version calls it. If the finance system stops returning due_date from get_invoice, the invoice comparison function turns unusable. For the repair, see Change something that's live.

The go-live gate#

Saving is never gated, and neither is an activation that changes only the model, the prompt wording or a schedule. Tools given straight to the agent's model, and calls whose connection is chosen at run time, aren't gated. A script that calls a function isn't gated for the function's operations: the function met the gate when it was published.

The refusal, titled "1 operation has never succeeded" (or "N operations"), lists each untested operation and its connection. A successful test run clears it.

An org admin, or their own agent acting on their instruction, can override with Go live untested. It covers exactly the listed operations and goes into the audit log with who, through which surface, which operations and the optional reason. The operations stay Untested until a real call succeeds. Org API keys and members who aren't admins can't override.

Test parameters and behavior tests#

Test parameters are named sets of inputs kept beside a script or function, each with a Run button. A run that writes needs an org admin's go-ahead for its list of writes, and so does Chat on a saved version that isn't active.

Roll back#

Rolling back is going live with an older version, and it meets the same checks.

An older agent version never rolls back a function or widget, and never brings back an operation switched off since. Unpublish takes a function or widget offline until you publish again.

To test, see Test behavior. To change and roll back a live agent, see Change something that's live.