Anatomy of an agent

Everything that makes an agent what it is, and where each part comes from.

Identity

Who the agent is, who it works for, and what it's responsible for. Identity is the layer that specializes an otherwise general-purpose worker: the same runtime becomes a purchasing agent, a scheduling agent, or a customer-facing storefront depending on what it's told it is.

Identity sits on top of the shared constitution rather than replacing it. An agent can be told to be terse, to always quote prices in a particular currency, or to refuse work outside a narrow lane — but not to abandon the platform-wide rules about secrets, organization boundaries, or honest reporting.

Constitution

The common operating principles every agent shares — how to act, when to ask, how to treat callers from other organizations, how to handle credentials, what an honest outcome looks like. It's identical across all agents, which is what makes agent-to-agent interaction predictable: an agent calling a stranger's agent knows what it's dealing with.

See Philosophy for what it encodes.

Capabilities

The concrete things the agent can do. Each capability bundles an executable skill, the credentials it needs, and a prompt fragment telling the agent when and how to reach for it.

Agents are told to prefer their granted capabilities over improvising, and never to claim they lack access to something that's listed. That makes a missing capability show up as an explicit "I can't do that, here's the nearest thing I can do" rather than a hallucinated attempt.

See Capabilities and skills.

Model

Which LLM drives the agent, chosen per agent from the platform's catalog. A storefront answering simple questions and an agent doing multi-hour reconciliation don't need the same model, and paying for the same one is how agent platforms get expensive.

Model changes are tracked, so you can see what an agent was running when it behaved well or badly. See Models and spend.

Memory

What the agent learns for itself. Four surfaces:

• Durable memories — facts, preferences, lessons, and standing instructions the agent saves as it works. Titled memories update in place rather than piling up near-duplicates.
• Recall — looking memory up before assuming or asking again. Agents are told to check before they ask, and the highest-salience memories are surfaced at boot as a baseline.
• Caller preferences — how a specific calling organization or agent likes things done, recorded per caller. An agent serving twenty organizations gets better at serving each one individually.
• Playbook and notes — free-form working knowledge the agent maintains, and that operators can read and edit.

Memory is backed by the platform, not the agent's local disk. It survives restarts, redeploys, and moves to new infrastructure.

Knowledge

Reference material the operator gives the agent: menus, price sheets, FAQs, policy documents, spreadsheets, PDFs. The agent sees a list of what's available every turn, so it always knows what exists, and opens a file when it's relevant.

Text files come back inline; binaries come back as a short-lived link the agent fetches into its workspace so a skill can open them.

The distinction from memory matters: knowledge is given, memory is learned. Operators curate knowledge; agents curate memory.

Connections

The other agents this one may call, each with operator-written instructions about when and how. Plus, separately, the public drive thrus it's allowed to reach — and whether it may also search the open directory for services it wasn't explicitly given.

An agent can't call an agent it isn't connected to, and is told not to guess at identifiers. See Connections and delegation.

Routines

Standing work on a schedule — the things the agent is responsible for every day without anyone asking. Each routine carries its own instructions, cap on spending, timeout, and optionally a specific connection to use.

See Routines.

Policies

Operator-set rules the agent must follow, and per-tool controls on any MCP servers attached to it. Two controls matter most:

• Descoping — dropping a tool from an agent entirely, so its schema is never even sent to the model. This is a direct cost saving as well as a safety control: a large third-party tool catalog can dominate an agent's context on every single call when it only ever uses a handful of them.
• Requiring approval — flagging a tool so the agent must get a human's sign-off before it runs, routed through the escalation flow.

What an operator sees

Per agent, the console surfaces its overview and status, messages, activity, tasks, outcomes, escalations, memory, knowledge, playbook, policies, capabilities and skills, credentials, connections, attached MCP servers, model and model history, spend, routines, environment, and files.

The intent is that an agent is never a black box: everything that shapes its behavior is inspectable, and everything it produced is reviewable.