Agents
This page is the taxonomy behind the Agents surface - why agents are built the way they are, not just what the UI shows you.
An agent is a scoped, budgeted tool loop: it has a defined goal, a budget on how much reasoning and tool-calling it can spend, and it reads Civil Memory the same way any other reader does. What separates one agent from another is what it’s allowed to do with what it finds.
Probe agents propose, never write
A probe agent owns one axis of your organisation’s configuration - who a worker’s identity resolves to across systems, or what a document’s geography implies about which project it belongs to. When a probe reaches a conclusion, that conclusion becomes a pending change in your approvals queue. It is never written directly.
This matters because a probe’s job is inference over incomplete or ambiguous signals - exactly the kind of reasoning that benefits from a human’s final say before it becomes the organisation’s stated configuration. A probe can also re-run itself when the underlying data drifts, proposing an update rather than silently going stale.
Producer agents consume approved config and write reviewable output
A producer agent runs against configuration that’s already been approved - it doesn’t re-litigate your organisation’s setup, it uses it. Its output is a reviewable artifact: a drawing-quantity measurement checked against a schedule of rates, or a cited launch brief for a tender response. The output sits in a reviewable state until someone looks at it - it’s a proposal to be checked, not a fact silently added to the record.
Next steps
- Agents (surface) - where to find and run agents in the app
- Shelves and Conduits - what agents read from and, for producers, write back through