Skip to main content

Agents and versions

Configure the agent, save a version, publish it. A version never changes once saved, and each run freezes its grants and skills when it starts.

The configuration​

An agent carries five groups of settings.

  • Instructions: the system prompt, and optionally a JSON Schema the answer must satisfy. An answer that does not validate goes back to the model, up to 3 times, and the run fails if it still does not.
  • Models: the main model, the fallback models, the sampling parameters (temperature, top-p, maximum tokens) and the reasoning effort. A parameter the registry says the chosen model does not accept is refused when you save, and only the reasoning efforts the model publishes are offered.
  • Guardrails: the input, output and scope rules the worker applies around the model, and the spending ceilings of a run: a cost ceiling, 1 USD by default, and an optional token ceiling, both covering the sub-agents. See Guardrails and Budgets and quotas.
  • Capabilities: delegation to sub-agents, with their model, depth and blocked tools, and the attachment types the agent accepts, within what the instance allows.
  • Grants: the collections it may search, the tools and MCP servers it may call, the secrets its tools use, and the skills it may load.

The first four groups make up a version. Grants belong to the agent itself: a change applies to the runs created afterwards, whichever version they run.

Versions and publishing​

Save a version writes the configuration into a new version, with its author, its date and a change note. Versions are immutable, and the database refuses any edit to them. Saving a configuration identical to the current one creates nothing. Restore creates a new version whose content is a copy of an older one, so the history stays a straight line.

Publish… opens the list of versions: choose one and deploy it to the Test or Production environment, on every active surface of that environment at once (widget, API, Slack). Publishing an older version is how you roll back, and it creates no new version. With the publication gates, an Enterprise module, deploying to Production can first require the agent's test suites to pass. Saving, restoring and publishing are all recorded in the audit log.

Running​

A run pins its version and freezes its grants when it is created. The engine records every step as an append-only event with an idempotency key, so a crash followed by a replay produces the same outcome, without a duplicate side effect.

Skills are frozen per run, not per version

A skill is not copied into the agent version. When a run is created, each skill granted to the agent is resolved to its current version, and its instructions and capabilities are frozen into the run's grants. Publishing a new version of a skill therefore changes the next runs of every agent it is granted to, even when their version has not changed. A run in flight keeps what it started with.

A run that has to wait goes dormant and holds no worker while it waits: for its sub-agents, for a provider's rate limit window, for the visitor's answer to a question, or for a person's decision when the human approval Enterprise module is in use. It resumes when what it waits for arrives.