Agent anatomy

In one line. What an agent is made of — the model, the instructions, the knowledge it may read, the tools it may use, the rules it must obey — so every tab in the agent editor stops being a form and starts being a decision. You’ll be able to. Reason about agent behavior from first principles: why an agent answers well, drifts, refuses, or burns tokens — and which part of its anatomy to adjust. Where this lives. Studio > Agents > Agent Toolkit > Agents — open an agent to see the tabs described here.

The parts

An agent is not a model. A model is a mind for rent; an agent is that mind hired into a job, with a role, materials, equipment and rules. Five parts:

Part	What it is	Where you shape it
Model	The model that does the thinking. Swappable — the same agent can run on any model registered in the project. Agent Mode beside it sets how hard it thinks: Fast answers directly, Thinking plans first, Auto decides per question.	Agent Model tab, A2
Persona	The plain-language job description: role, task, tone, output contract, refusal rules. This is the highest-leverage text you will write on this platform.	Agent Persona tab
Knowledge	The collections the agent may read. Grounding and access boundary in one — attach nothing, and the agent knows nothing about your business.	Agent Knowledge tab, D1
Capabilities	Tools, skills and MCP servers — what the agent can do beyond reading and writing text.	Agent Capabilities tab, A5, A6, A7
Guard rails	The rules layered onto every run, plus the steps that need a human’s approval before they happen.	Agent Governance tab, A8

Around those parts, the platform does the running — which is what turns a one-shot text model into a worker you can trust with a queue: for each run it assembles what the agent sees, carries out its tool calls, records the trace, scores confidence, and hands the result to the collection’s lifecycle.

What happens on a run

Every run — playground chat or production document — is the same loop:

Assemble. The platform builds the context: persona, the relevant slices of attached knowledge, the document or question at hand, and the schema it must fill.
Think. The model reasons over that context. If it decides it needs a capability — a lookup, a calculation, a search — it calls a tool, gets the result, and continues.
Answer. The output lands where the run came from: an answer with citations in chat, or schema fields with per-field confidence on a document.
Record. The full trace — inputs, tool calls, output, confidence, cost — is kept, which is why you can inspect any run after the fact.

The playground shows you this loop live; production runs it silently at volume. Same anatomy, same behavior — which is exactly why playground testing predicts production behavior.

Context is the scarce resource

A model reads a finite window of text per run. The platform spends that budget for you — persona first, then the knowledge slices most relevant to the task, then the work itself. Two practical consequences:

Relevance beats volume. Attaching ten collections “just in case” doesn’t make an agent smarter; it makes retrieval noisier. Attach what the job needs.
The persona is always in the room. It is read on every single run, which is why one precise sentence there outperforms a paragraph of vibes.

Why agents misbehave — a diagnosis table

Symptom	Usually means	Fix at
Confident nonsense	Answering beyond its grounding	Persona: require citations, demand refusal when unsupported; check Knowledge attachments
Right answer, wrong format	Output contract underspecified	Persona: state the format explicitly; Output tab: define the structure the answer must fill
Ignores its documents	Question outruns retrieval, or wrong collection attached	Knowledge tab; D6 · Search & indexes
Slow or expensive	Over-tooled, or a heavier model than the job needs	Capabilities: remove unused tools; Model: try a lighter model — measure in the playground
Inconsistent across runs	Task too big for one worker	Split it: teams & mesh or a pipeline

One worker, then many

Everything above describes one agent. The platform’s larger patterns are this same anatomy repeated: a team or mesh is agents with a coordination layer; an XFlow is agents with an orchestration layer; an Agentic System is a fleet of them over one domain model. Master the single worker first — the rest is arrangement.

Where to go next

Build one: A3 · Your first agent.
The varieties of worker: A4 · Agent varieties.
What the thinking runs on: A2 · LLMs & services.