Agent Platform Concepts
The agent platform is built on one idea that reshapes everything above it: an agent is an entity, not a key. It lives in the same directory as people and devices, holds its own cryptographic identity, is granted authority the same way they are, and appears in the same audit chain. Every capability in this topic, the runtime, orchestration, tools, skills, and coding agents, is a consequence of that decision.
This page covers the foundational model: the entity, the authorization path, the lifecycle, and the fact that one agent platform spans two runtimes.
The entity model: one directory for people, machines, and AI
Most identity systems were built for humans and had an agent story added later. This one has a single model because it only ever had one.
An agent:
- holds Ed25519 principal material and an X.509 certificate carrying its ID and clearance, issued by the cell authority;
- authenticates by mutual TLS on every call to a service;
- is resolved through the same authorization path as a person or a device;
- carries a classification on everything it reads, writes, and produces; and
- appears in the same tamper-evident audit chain as every other actor.
Because the agent is an entity, token accounting and cost attribution run per agent, per session, and per organization, consumption is attributable to an entity rather than to an anonymous API key. The identity and clearance model is part of the Security plane; this topic describes what the agent platform builds on top of it.
The single authorization path
An agent is granted, audited, and governed like any other entity. Roughly twenty identity primitives compose into one property: every action an agent takes traces back to a human or an organization that authorized it.
- User delegation is the root of the chain. A person delegates a bounded slice of their own authority to an agent. That delegation is a directory object, not a token in a cache, and it is why the audit trail means anything.
- Grants are attenuable. When an agent spawns a sub-agent, the child's authority is minted as the intersection of what was requested and what the parent holds, a child ceiling is always a subset of its parent's. A request that exceeds the parent is attenuated, never escalated, and delegation depth is policy-limited.
When an agent requests a sub-agent, the request carries no identity fields at all, issuer, lineage, root entity, and cell are resolved server-side from the parent's sealed grant, and the call fails closed on a custody-key mismatch. A compromised or jailbroken model can ask for the wrong thing; it cannot ask as someone else. This is a structural property of the mint path, not a filter on a prompt.
The enforcement point is a gate that can say no at the action boundary, an authorization decision with an audit record, not a prompt-level instruction. See Security → Governance for the deny-closed model, and the Agent Runtime for where it sits in the execution path.
The agent lifecycle
An agent moves through the same arc as a member of staff:
provision → active → review → suspend → decommission.
Two steps deserve attention because they are unusual and land well with regulated buyers:
- Admission and briefing. An entity is admitted against policy: with a preview so an operator sees the verdict before committing, and briefed before it is assigned work. Field manuals are authored, sectioned, versioned, and published, bound to spaces and roles; a briefing is resolved for a given entity and an acknowledgement is recorded when it has read it.
- A deliberate promotion step. Before an agent is trusted with real work, it passes an explicit, auditable promotion, the same as vetting staff before giving them the keys.
Population itself is governed. Creation, instantiation, and spawning each pass a quota gate; spawn rate is throttled over time; and quota raises are stepped rather than granted. The path is compensation-before-denial: an estate under pressure rebalances before it refuses.
Governed like staff
Putting it together: an agent has a workshop for building it, a personnel file, a role structure, an onboarding pack, a key ring, a budget, an observed record, and a cost, because it is staff, not a script. Its work zone, its last gate verdict, and its remaining budget are visible next to it, in the browser and on the edge device. Governance has a read side, not only an enforcement side.
One platform, two runtimes
The agent platform is a single product that spans two runtimes:
| Runtime | Where it runs | What it is |
|---|---|---|
| The core | A cell: the full backend | The agent fabric: identity, teams, orchestration, tools, skills, model serving |
| The Edge Agent | On-device, at the edge | A purpose-built binary that reasons locally, wields a governed tool surface, and keeps working disconnected |
They are designed together, not integrated against each other: they share proto schemas, crypto primitives, and authorization semantics. A cell provides the full backend; the Edge Agent runs on the device and reaches a cell over the governed fabric, degrading fail-closed to store-and-forward when no path exists. The edge is a first-class part of the story, not a degraded client. See Platform Architecture → Core and Edge.
See also
- Agent Runtime: durable, signed, externally replayable execution.
- Orchestration & Agent Teams, composing agents across cells and to the edge.
- Security → Identity, the cryptographic identity every entity shares.
- Security → Governance, the gate that can refuse an action.