How agents and variations work

An agent is a stable entry point for a job. Its variations are candidate implementations of that job. Each objective selects one variation when it is created and stores a point-in-time configuration snapshot.

​

The configuration boundary

The snapshot is the important boundary. Editing a prompt, switching a model, or changing an assignment does not rewrite an objective that already exists. The objective continues with the selected variation as it looked when creation succeeded.

​

Draft, published, and archived

Agents move through explicit lifecycle states: An agent needs at least one variation before it can be published. Publishing does not select a default variation permanently. Selection happens separately for every objective.

​

How a variation is selected

When variationId is omitted from objective creation, the agent’s Variation Selection mode chooses a variation:

• Random gives every current variation equal probability.
• Feedback Driven uses Thompson Sampling. Each variation starts with the same uniform prior. Feedback on completed runs updates its Beta posterior, and each future objective samples once from every variation and chooses the highest draw.

Passing variationId pins a specific variation and overrides the agent’s selection mode for that objective.

​

Assignments are variation-specific

A variation can receive four kinds of capability:

• An individual tool.
• A complete tool set.
• Another published agent, exposed as a sub-agent tool.
• One or more memory layers in a precedence-ordered cascade.

This makes variations useful for more than prompt tests. You can compare models, different tool access, discovery settings, compaction strategies, or specialist delegation while the agent ID remains stable.