The ideas behind governed agents.
A short, plain-English tour of the vocabulary you will meet across the CLI, the dashboard, and the benchmarks: the authority question every action answers, what a governance state score means, the two ways to run the agent, who can do what, and the pipeline every action passes through.
Authority: the question every action answers
Every governed action answers one question: may this agent, acting for this principal under this delegation, take this action against this resource, for this purpose, right now, given its current behavior, its trust trajectory, its accumulated activity, its remaining budget and the risk involved? The answer is not a permission looked up once. It is an authority state assembled from identity, tier, policy, behavioral signals and resource constraints, and evaluated again on every action.
The axiom underneath is simple: an autonomous actor possesses bounded authority over consequential resources. The closest familiar analogy is a machine-native power of attorney. A principal grants a bounded authority, the grant is recorded, every act under it is checked against the bound and leaves evidence, and the grant can be narrowed or revoked while the agent is running. Agentomy owns that authority. It does not own execution and it does not govern intelligence: models reason, agents act, and Agentomy governs authority and consequence.
Governance state: 3/6 vs 6/6
When you run agentomy-agent status, it reports a governance state as a score out of six. The six refers to the six GovernanceBench dimensions: the categories Agentomy's open benchmark scores a deployment against. How many of those six are active depends on whether the agent is running by itself or connected to the Agentomy infrastructure.
Two dimensions active
The agent runs on its own with no backend. Two dimensions are live: Authorization (is the agent operating within its assigned scope?) and Behavioral Integrity (is the agent's behavior consistent with its stated purpose?). This is real governance you can ship today, with no infrastructure to install.
All six dimensions active
The agent is connected to Agentomy infrastructure. It adds three more dimensions: Auditability (a cryptographic, tamper-evident audit trail), Override Capability (a verified kill switch), and OWASP Coverage (adversarial agentic threats), the fifth dimension that needs a backend to exist. The status command reports fleet health, quarantined-agent count, audit integrity, and anomaly-detector state.
GovernanceBench is that open benchmark; you can read the dimensions and run it yourself on the Benchmarks page.
Standalone vs. infrastructure-connected mode
These are the two ways to run the agent, and they map onto the two scores above.
Standalone mode (Architecture B)
The agent is embedded in your session as a governance peer: a system prompt plus local checks. It observes, assesses, flags, and summarizes. It does not block or halt; enforcement stays with the human operator. No Docker container, no API calls, no backend. This is what you get from agentomy-agent init and agentomy-agent session with no --infra URL. It scores 3/6.
Infrastructure-connected mode (Architecture A)
You point the agent at a running Agentomy instance with --infra URL (for example --infra http://localhost:3000). If the instance is reachable, the agent upgrades to connected mode and unlocks the cryptographic audit trail, the fleet-wide kill switch, and scored adversarial testing. It scores 6/6. If the URL is unreachable, the agent falls back to standalone mode rather than failing, so connecting is always safe to try. See the exact behavior in the CLI reference.
The operator tier model
Every human operator and every agent holds one of five operator tiers. A tier is an access level: it decides which actions are permitted, and it is enforced server-side, so it cannot be escalated through a request body or a prompt. Each tier inherits everything the tier below it can do.
- Evaluator: read-only with enhanced monitoring. For auditors and regulators: verify claims, run benchmarks, read the audit trail, change nothing.
- Analyst: read-only standard access. Research, review, and report. The tier a developer starts at when adding governance to an existing agent.
- Builder: read and write. The day-to-day working tier for development and integration.
- Operator: execute, deploy, configure. Elevated trust for running a fleet in production. Can halt, resume, and quarantine agents, but cannot override governance itself.
- Strategist: full access. The kill-switch tier: halt the entire fleet, resume it, and assign or revoke tiers. Every Strategist action is logged.
Pick the lowest tier that covers what you need today and upgrade when the next capability is required. The full per-tier capability matrix lives on the Operator Tiers page.
The 10-stage governance pipeline
In connected mode, every governed action runs through the same 10-stage pipeline in the same order: identity, trust, authorization, behavioral check, content input, action execution, output scanning, evidence recording, drift update, and halt evaluation. Each stage produces a forensic evidence record, and the records are hash-linked into a tamper-evident chain. Change a single byte and the chain breaks. There is no governance-off mode. The full stage-by-stage breakdown and its mapping to the EU AI Act is on the Agent Governance Protocol page.