Agent configuration
How rule files govern an agent, and how a version is approved
An agent's behaviour lives in its rule file, and a rule file is never edited in place. Every change writes a new version row, which is what makes a rollback a selection rather than a reconstruction.
Open Agent fleet in the consoleVersions accumulate; they never overwrite
An agent's rule file is the text that governs how it behaves. It is never edited in place: a change writes a new version row and the previous one stays exactly as it was. That is the whole mechanism behind a rollback being a selection rather than a reconstruction.
What creates a new version
Two things write a new version: a person editing the rule file directly, and a person approving a Rule Optimizer proposal. Both end in the same place — a new row — and neither happens without someone deciding it should.
What a rule file holds
A rule file is the text that governs how one agent behaves — what it should do, what it must not do, and how it should format what it produces. It is content, not configuration: there is no schema to satisfy, which is why reviewing a change means reading it.
Rolling back
Because a change writes a new row rather than editing one, rolling back is selecting an earlier version — not reconstructing it from a diff or a backup. Every version that ever applied is still there, with the time it applied from.
- The question “what was this agent running when that run executed?” has a direct answer.
- A rollback is itself a new version, so the history stays append-only rather than rewinding.
- Nothing is deleted on rollback, so rolling forward again is the same operation in the other direction.
Put it into practice
Run a fleet with these guardrails on from day one.
Hard cost caps, one audited gateway in front of every tool call, and versioned rule files — the defaults, not an enterprise add-on.