Intelligence
L5. The agent is the primitive. A skill is how it works, a tool is how it reaches the world, and the two are never the same thing.
Intelligence
L5. The layer that decides.
An agent decides what to do. It does not execute, and it does not persist. The layer below it does both.
Components
| Component | Job |
|---|---|
| Agent | One versioned specification of a decision-maker. |
| Skill | One reusable procedure an agent loads to perform a capability. |
| Planner | Turn an instruction into an ordered plan, or select an existing workflow. |
| Reasoner | The model loop. Read the brief, choose a tool, read the result, decide again. |
| Delegation | Hand a plan to the orchestration layer as one run. |
The agent
An agent is a row, not a class. Eight fields define it.
agent
identity name, role, owner
instructions the system prompt
model provider and model id
skills the procedures it may load
tools the capability list it may call
context policy what the context builder retrieves for it
memory policy what it may read and what it may propose
budget cost, tokens and tool calls per run
A change to any field is a new version. A run pins the version it started with, so a spec edit never changes a run in flight.
Skill is not tool
This is the distinction the layer exists to hold.
| Skill | Tool | |
|---|---|---|
| Answers | How does the agent perform a capability? | How does the agent reach the world? |
| Lives in | L5, this layer | L2 |
| Shape | A procedure: instructions, examples, checks | A contract: name, input schema, output schema |
| Side effect | None on its own | Usually yes |
A skill uses tools. A tool never uses a skill.
Research skill
├── web search tool
├── browser tool
└── company database tool
Collapsing the two is the common failure. It produces a "research tool" that hides a prompt, cannot be governed by a policy on its action, and cannot be reused by a second skill.
Rules
- One agentic hop. An agent calls a workflow. A workflow calls steps. An agent does not call another agent. Routing errors multiply through nested reasoning chains.
- An agent holds no credential. It names a tool. The tool layer resolves the credential.
- An agent writes no SQL, and calls no raw route. Both are tool calls.
- An agent does not choose its own context. A context policy on the row drives a deterministic builder. A retrieval decision by the agent is a second hop.
- An agent does not decide its own authorization. It asks for an action. The policy plane answers.
- Fan out to runs, never to agents. An agent that must do ten things starts ten runs. It does not start ten agents.
- The spec is provider-neutral. One adapter maps it to a model provider. Lock-in stays a one-file problem.
Agent collaboration
Two agents cooperate through the run tree, and never through a direct call.
Agent A → run (workflow)
├── step 1 → run (agent B)
├── step 2 → run (agent C)
└── step 3 → agent A reads both results
The workflow is the coordinator, and it is deterministic. That keeps the hop count at one, and it makes the whole collaboration visible in the run tree.
Data model
| Table | Holds |
|---|---|
agents | The versioned agent spec: instructions, model, skills, tools, context policy, memory policy, budget. |
skills | One reusable procedure, its instructions, and the tools it needs. |
Both are definitions. Neither holds execution state. Execution state is a run.
Risks
| Risk | Mitigation |
|---|---|
| The tool list grows until it does not fit in a context window | The registry serves a subset per agent, selected by the spec. A large surface is a selection problem, not a transport problem |
| A skill quietly becomes a prompt nobody reviews | A skill is a versioned row with an owner, and a change is a diff |
| An agent is given a plan it cannot execute, and it improvises | A plan names workflows and tools that exist. An unknown name fails at admission, not at step 7 |
| Two agents grow two copies of the same rule | A rule is a policy row bound to an action. The agent spec carries budget defaults, never conditions |
| Model drift changes behaviour with no code change | The model id is pinned on the spec, and a change is a new version |
Open questions
- Who authors an agent? Engineers only, or any admin?
- Does a planner produce a new workflow, or only select one that exists? Generated workflows are powerful, and they are hard to review.
- Is a skill shared across agents by reference, or copied at version time?
- Can an agent propose a change to its own spec, for a person to approve? That is a useful loop, and it needs a hard policy boundary.
Diagram source. ac-docs/diagrams/mission-control-layers.drawio, page mission-control-intelligence.
Edit that page, then run ./scripts/export-diagrams.sh mission-control-layers.
Update this page and the diagram together.