Enable javascript in your browser for better experience. Need to know to enable it? Go here.

Understanding agents,

their five controllers

and one graph

An agent is a delegation of human judgment. You authorize it to decide something in a real-world case, what you hand over is not a task but the judgment the task requires.

 

The moment you delegate any judgment, one need follows immediately: the agent must act faithfully. What holds it faithful is a set of mechanisms placed around it.

 

These mechanisms are controllers, terms that have circulated since early 2023 but emerged separately with no shared definitions, leaving loose, overlapping boundaries. This article, from a practitioner's perspective, tries to define and compare them clearly.

 

 

The five controllers

 

A controller encodes human judgment into structural pre-made knowledge, so the agent can replay it whenever the situation recurs. There are five of them working together to form the control system that carries the human's judgment into the agent's behavior.

 

Prompts set the boundary

 

A Prompt declares an agent’s boundaries, defining what it is and isn’t: its role, its permissions, its hard limits. But a prompt the model can read is a prompt the model can ignore, so it declares without ever enforcing. As the most basic control, prompt is always the first step you take to ground an agent’s behavior.

 

Instructions direct the aim

 

An Instruction defines where to point and what good looks like: style, priorities, standing preferences. It is open-ended, because many valid paths reach the same aim. Use it for strategic intent, not fast-moving change: it is the slowest layer, and static guidance cannot react in real time without lagging.

 

Like a prompt, an instruction is text the model can both read and ignore. Both only declare, not enforce. That is the shared limit of the agent-level controllers: a prompt declares a boundary and an instruction declares a direction, but neither can guarantee the model honors it.

 

Skills replay experience

 

When an agentic use case goes beyond being generic, the human judgment it needs becomes a playbook: the specific sequence that resolves a specific, recurring situation.

 

A Skill is that packaged expertise for a single action, applied before anything goes wrong. Tool-calling is one form of skill, but the tool is not what makes it a skill, the pre-committed procedure is. 

 

For example, a repo-hygiene remediation skill encodes the exact sequence for a flagged dependency: read the report (this may or may not include  tool-calling to browse an internal Confluence page), find the affected package, bump it to the nearest patched version, regenerate the lockfile, update the changelog, open a PR with a standard description. Every step is decided in advance; the skill replays a fix a human already worked out.

 

Skill is fast and cheap because it does not deliberate. And for the same reason it is blind: it acts on a fixed assumption and cannot notice when the situation no longer fits. The less reversible or more consequential the action, the less comfortable we should be letting a fixed skill execute without validation.

 

Recipes orchestrate and gate skills

 

A Recipe is the orchestrator of skills, gating them for the branching scenarios of a more complex task. At each branch it selects which skill runs next based on the situation.

 

For example, a repo-hygiene recipe runs the full remediation pass: scan the repo, then triage each finding. The gating mechanism is:

 

  1. If it's a flagged dependency, run the dependency-remediation skill;

     

  2. If it's a failing lint rule, run the lint-fix skill;

     

  3. If it's a secret in the git history, stop and escalate to a human rather than auto-remediate.

     

Each box is a skill; the recipe is the triage logic deciding which skill each finding gets and which findings shouldn't be touched at all.

 

A recipe is still a feedforward controller, as its branches are decided in advance. So it shares the skill's blindness: it handles only the situations its gates anticipated. And it adds one failure a skill can't have: mis-routing, when a gate aims the right skill at the wrong problem. 

 

Validating whether a recipe ran properly is still internal and hypothesis-driven, not signal-based. So for higher-risk cases we need something that can be validated by the real world: the Loop.

 

Loops correct against an external signal

 

A loop is the only controller that corrects against an external signal, as the rest either don't validate at all (prompts and instructions) or validate against an internal hypothesis (skills and recipes). That makes it the strongest control mechanism, and also the one to reserve for your riskiest use cases, because it costs extra runs and a real signal to close on: you spend it where being confidently wrong is most costly.

 

A loop compares the output to the target and runs again when there is a gap. It rests on one property: it must close on an external authority, a test suite, a compiler, a human, not on the agent's own opinion of its work. A check the agent grades itself is not a loop, because the agent can be wrong and satisfied at once.

 

But a loop is only as strong as the authority it closes on. Point it at a weak or wrong signal and it will converge just as confidently, and that is among the most dangerous agent failures, because the output now carries the false authority of having been validated. The discipline of a loop is not the cycle itself but the quality of the signal that ends the cycle.

 

The graph grounds the controllers

 

Control determines how an agent behaves. Grounding determines what it knows while behaving.

 

As you add general-purpose or specialized agents  and run them across many cases over time, the controllers begin to need something none of them holds: shared, durable knowledge to draw on. 

 

A prompt can define a security auditor, a skill can specify a playbook, a recipe can route its review, a loop can verify its output, but none of them can define the same language, remember what was found last week or connect this case to a hundred prior ones. That memory has to live somewhere outside any single controller.

 

So far, every controller answers a question about behavior. None answers a different question: what does the system know, and where does that knowledge persist?

 

That substrate is a graph. The pattern has drawn recent attention through Andrew Ng's endorsement of the DeepLearning.AI course Agentic Knowledge Graph Construction, in which a multi-agent system turns structured and unstructured data into a shared knowledge graph. Instead of passing transcripts between themselves, agents read from and write to a common, persistent structure.

 

The individual agent and its controllers forget between runs; the graph does not. The course positions the knowledge graph as a foundational component for information persistence and relationship modeling and, notably, the agents build that graph through a loop that proposes a schema and fact-checks it against evidence. The loop operates over the graph, not the other way around.

 

That places the graph on a different axis. It is not a sixth controller. The five controllers govern agents’ judgment, what it may do, where it aims, how it acts, in what order and how it corrects. The graph governs something orthogonal: where shared knowledge lives when a control system grows beyond one agent. It grounds the controllers rather than joining them. The controllers still carry the human's judgment; the graph is the institutional memory they draw on to carry it well. Five control; one grounds.

 

 

Summary

 

An agent is delegated human judgment, and it stays faithful to that judgment only through the structure placed around it. Five controllers provide that structure, and each answers a different question about the agent's behavior:

Controller

Definition

Prompt

What the agent is and isn't. Declares the boundary, but cannot enforce it.

Instruction

Where the agent aims. Declares the direction, and like the prompt, can be read and ignored.

Skill

One pre-decided action. Feedforward, fast and blind past its assumption.

Recipe

The routing among skills. Feedforward too, and blind past the branches it anticipated.

Loop

Unlike the other four, a loop is defined by feedback from outside the agent's proposed plan.

The graph is not a sixth controller. The five govern an agent's judgment; the graph grounds them in shared, persistent knowledge: the institutional memory that outlives any run and connects one case to a hundred others. The controllers carry the human's judgment into the agent's behavior; the graph is what they draw on to carry it well as the system grows beyond a single agent (Figure 1.).

So while the agent decides what to do, the prompt bounds, the instruction aims, the skill acts, the recipe sequences, the loop corrects and the graph remembers, and the agent stays faithful to the judgment.

Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.

Explore a snapshot of today's tech landscape