The Agent
Design Canvas
Eight principles and one working canvas for designing an AI agent — from a single job to a system that scales. Built to be read in one sweep, before anyone opens a platform.
One agent, at a glance
Everything in this guide, arranged so the layout itself shows the relationships. The core sits at the centre; each ring outward is a layer that contains and governs the one inside it, and the work runs as a loop around the middle. Read outward along a spoke to see how a capability is powered, bounded and supported. Read around to follow the cycle. The step-by-step version of the same design lives in Section 02.
Identity + Job. Who is acting and the result it owns — everything attaches here.
The components that power the loop: model, prompt, tools, memory, orchestration.
The boundary that contains the agent: permissions, gates, fallback, kill switch.
The world it runs in: shared support, audit, live checks, the model service.
Sets the rules, approvals and change rights the whole circle runs under.
Every agent its own verified identity · least privilege · zero-trust. The dashed spokes show it threading from the core to permissions and audit.
The core climbs outward over time: read → draft → supervised → extended.
result · cost · speed · risk · demand. Change only through recorded evidence.
Hover a quadrant to trace one spoke — the loop phase, the capability it uses, the control that bounds it, and the system service that feeds it all line up radially. Green arrows show the loop turning clockwise; the trigger enters at the top gate, the action exits at the bottom, signed with the agent’s identity.
The circle shows structure — what contains what. The five moves in Section 02 show sequence — what you decide first, next and last. Same design, two readings.
Eight design principles
These hold whether you are a solo operator or an enterprise. Roughly three-quarters of multi-agent failures trace back to design and specification, not to the model — so the discipline lives here, before the build.
Define the job first
Name one business result, one trigger, one output, one handoff. If the agent’s title sounds like a real job, the scope is clear enough to build. Precision in the brief is precision in behaviour.
ScopeBound autonomy on purpose
Freedom to act, inside clear limits. Permissions, approval gates, fallbacks and a kill switch turn a capable agent into a safe one. Separate what it may recommend from what it may change.
ControlEarn autonomy, don’t assume it
Start read-only. Move to draft-only, then supervised action, then wider authority — each step unlocked by a track record, not a good demo. Trust is a rate you measure, not a launch setting.
TrustSize the blast radius
Before granting a permission, ask what the worst mistake costs and whether it reverses in ten minutes. Irreversible, high-impact actions need a human in the loop — often permanently.
RiskPrefer the simplest architecture
One disciplined agent beats a fragile crowd. Add a second agent only when one job genuinely splits into two. More agents add coordination failure, not automatic capability.
StructureStore only what earns its place
For every memory, name the next task it improves. If you can’t, don’t store it. Memory is an operational tool with governance — what’s kept, who updates it, how long it lasts.
MemoryClose every loop to a real system
An output that sits in a chat window creates work; an output that updates a record removes it. When the agent finishes, something must change in a system people already use.
InterfaceProve it, then improve it
Set a baseline before building. Log every action, measure result, cost, speed and risk, and change behaviour only through recorded evidence and approved release. Feedback alone changes nothing.
Assurance“If this agent takes the wrong action here, what happens and who fixes it?” — the one scoping question that prevents most incidents.
The canvas: five moves to design one agent
Read left to right. Each column is one decision with a clear verb and the components it settles. The last column is where a single agent grows into a system — cross it only after the first four are working.
One decision per box · action titles · plain business words · every step ties to a record, a measure or a check.
Set the job & limits
- Business result & the case it handles
- Start (trigger) and finish (done)
- Success metric — one primary
- The Never List: what it must not do
Give it an identity & limits
- Own identity — credentials never shared with a human
- Four permission levels, least first
- Approval gates on irreversible steps
- Fallback & kill switch — who can throw it
Give what it needs, do the work
- Data, rules, tools, people, other agents
- Source recorded for each dependency
- Reasoning pattern for the task
- Memory: only what the next case needs
Check the result
- Verify output against defined criteria
- Log action + evidence (audit trail)
- Trust rate: approved without edits
- Faults & ideas → system authority
Group into a system
- Group agents around one result
- Route & sort incoming work by risk
- Shared support: identity, data, audit
- Check the whole: result, cost, demand
What’s inside: the seven components
Every agent is built from the same parts, like a car — the engine matters, but bad tires or an empty tank stop you just the same. When an agent underperforms, find the broken component before reaching for a more expensive model. Binding all of them to the wider system is one shared layer, and its first pillar is identity.
Model
Reads input, reasons, generates output. Use the right model per step, not the best model everywhere.
System prompt
Role, context, rules, format, examples, stop condition. Two to five examples lift accuracy 15–40%.
Tools
Read from and act on real systems via APIs. Start with 3–5, read-only first, add write tools one at a time.
Memory
Carries context across steps and sessions. Four kinds: task context, stable preferences, history, corrections.
Decision loop
Drives multi-step work forward and knows when to stop. The difference between a prompt and an agent.
Orchestration
Coordinates the parts into a reliable workflow: what runs first, next, last, and what makes it pause or retry.
Interfaces
Connect inputs and outputs to real work. The exit point must change something in a system people use.
Shared support
Identity & access first — a verified identity per agent, then approved data, safe connections, records & audit, live checks, a versioned model service.
Identity is the thread that ties it together
Humans log in with a username and password; an agent doesn’t fit that model, yet it may read email, update the CRM and act across systems on someone’s behalf. So the first question a system must answer is simple: which agent is acting, and what is it allowed to do? Give every agent its own verified identity — never a human’s shared credentials — and that one decision makes the rest of the canvas work.
The earned-autonomy ladder
Autonomy is a dial, not a switch. Every agent starts at the bottom and climbs only by demonstrated performance. The gate on the right is what must be true before the next rung.
Pick behaviour from named patterns
Inside Move 3, choose proven patterns rather than inventing behaviour. Reach for the reasoning pattern the task shape calls for, add orchestration only when work truly splits, and wrap the whole in safety patterns.
- Plan-then-actStrict sequences, compliance, contract review
- Chain-of-thoughtMulti-step logic and root-cause work
- ReActLook things up instead of guessing
- ReflectionCritique and refine its own output
- Tree-of-thoughtsExplore options when search pays off
- RouterSort mixed requests to specialists
- Supervisor–workerManager breaks a goal into subtasks
- Parallel fan-outMany views at once, then merge
- Prompt chainOutput of one step feeds the next
- A2A meshIndependent agents negotiate directly
- Human-in-the-loop gatePause for sign-off on high-consequence acts
- Act-then-verifyA checker pass before continuing
- Self-check / LLM-as-judgeInspect output for errors and drift
- Input sanitisationStrict schemas; block injection
- Programmable railsTopic, dialogue and execution limits
Four mechanisms of bounded autonomy
Instructions are not enough — a strong prompt is only part of the answer. The real controls live in the architecture: what the agent can access, what it can do, and where a human must approve.
Permissions
What the agent can access and change. Grant the minimum; expand only after it proves reliable.
Approval gates
Points where a human must authorise before the agent continues — for anything irreversible, sensitive or first-time.
Fallbacks
What happens when it can’t continue: route to a human, return a flagged partial, or stop and log. Never push forward broken.
Kill switch
Stop it immediately — kill the trigger or pull write access. Every production agent has one, and the team knows how to use it.
The blast radius of an ungoverned agent is not bounded by its intelligence. It is bounded by what it has been permitted to access and act on.
The order of work
Design the agent fully before choosing how to build it. Finish the thinking, then pick the simplest tool — no-code, low-code, or full code — that fits.
Classify the task
What triggers it, what “done” means, what it must never do.
Set the limits
Permissions, approval gates, fallbacks, kill switch.
Choose the structure
One agent by default; a group only if the job splits.
Select patterns
Reasoning, orchestration and safety primitives.
Place the human
Decide which functions to automate and how far.
Add guardrails & prove
Baseline, audit trail, failure-mode review, then release.