Learning objectives. Describe all twenty elements of the Holistic Agent Canvas; complete a canvas for a real process; explain the agent loop and its terminators; and identify which element is missing when a given agent misbehaves.

Core lesson

Module 3 is where the framework introduced earlier becomes a working tool. Reread the Holistic Agent Canvas and the Holistic Agent Loop before continuing; this module teaches you to use them diagnostically.

The diagnostic principle

Almost every agent failure maps cleanly to a missing or under-specified canvas element. Once you internalise the mapping, debugging agents stops being guesswork.

Symptom	Missing element	Fix
Agent invents facts	5 Knowledge / 4 Context	Ground in retrieved sources; require citations; verify
Agent does the wrong task well	2 Mission	Rewrite the mission as one measurable outcome
Agent forgets what it established	6 Memory	Externalise state into notes, files or a store
Agent loops or stalls	8 Planning / 12 Observation	Add step budgets, re-planning triggers and explicit result checks
Agent succeeds sometimes	17 Evaluation / 20 Reliability	Measure across repeated runs; find the variance source
Agent takes an alarming action	13 Permissions / 15 Human Oversight	Reduce scope; add approval gate on irreversible actions
Agent is unaffordable	19 Economics	Route to smaller models; cache; prune context; reduce steps
Agent worked, then degraded	20 Evolution	Version everything; regression-test on every change
Nobody trusts it	3 Boundaries / 16 Audit	Publish what it does and does not do; log and show its work

START HERE — an agent explained by analogy

Think of hiring a capable new team member for a specific job.

You give them a role and a goal (Purpose). You brief them and give them access to the handbook and the shared drive (Context, Knowledge). They keep notes between days (Memory). They think about how to approach the work and break it into steps (Reasoning, Planning). They have logins to the systems they need — and only those (Tools, Environment, Permissions). They do things and check the results (Action, Observation). Certain decisions must go to their manager (Human Oversight). You review their work against a standard (Evaluation), give feedback (Feedback), and their salary must be justified by the value they produce (Economics).

The analogy is useful and has one hard limit: a human employee brings judgement, accountability and common sense that no current agent has. The analogy tells you what to design; it does not tell you what to trust.

PRACTITIONER — writing each element well

Mission. One sentence, one outcome, one measure, one owner.

Context. List exactly what must be in view at each step. Then delete a third of it and test.

Tools. Each tool needs an unambiguous name, a clear description of when to use it and when not to, a strict input schema, and a defined behaviour on error. Overlapping tools are a leading cause of agent confusion: if two engineers would argue about which tool to use, the agent will choose badly.

Human oversight. Specify the trigger, the reviewer role and the service level. “A human checks it” is not a control; “the account manager approves any external client communication within four working hours, else it does not send” is.

Terminators. Every agent needs a maximum step count, a maximum spend, a maximum wall-clock time, and a defined behaviour when any of these is hit — usually: stop, preserve state, escalate with a summary.

ARCHITECT — the canvas as specification

Treat each element as a contract with a test:

Mission — acceptance criteria and a golden test set
Knowledge — retrieval quality metrics (is the right document actually retrieved?)
Tools — contract tests and error-injection tests
Permissions — periodic access review; scope diffing on every release
Human oversight — measured approval latency and override rate (a very high override rate means the agent is not ready; a zero override rate often means the human is rubber-stamping)
Economics — cost per successful task, tracked as a first-class metric
Reliability — pass^k across repeated runs of a fixed suite

Business example — a client onboarding agent

Mission: every signed client reaches “ready to start” within one working day with a complete, verified record. Knowledge: the onboarding SOP, service catalogue, contract templates. Memory: per-client onboarding state. Tools: CRM read/write, document generation, calendar, email draft (never send), file storage. Action: creates records, drafts documents, schedules a kickoff. Irreversible actions: none — every external communication is drafted for approval. Human oversight: the account manager approves the welcome pack and the scope summary. Evaluation: completeness of record, rework rate, time to ready. Economics: measured against roughly ninety minutes of coordinator time per client. This is a strong first agent precisely because the irreversible actions were designed out of it.

Common mistakes

Starting with the prompt instead of the canvas.
Giving an agent broad credentials “for now”.
Confusing activity with progress — an agent that made twenty tool calls and no verified change has done nothing.
Omitting terminators.
Designing the happy path only. Real agents live in the failure paths.

Expert insight

The elements are not independent. Weak knowledge forces heavier reasoning, which raises cost and latency; loose permissions force heavier oversight, which erases the time saved; absent evaluation makes every other improvement guesswork. Agent design is trade-off management, not feature accumulation.

Knowledge check

Name the five planes and one element from each.
Which element is missing when an agent repeatedly retries a failing tool?
Why is the reversibility of an action the key input to how much autonomy you grant?
What makes a mission statement well-formed?
Why is a zero human-override rate a warning sign as well as a good sign?
Give three terminators every agent loop needs.

Challenge

Complete a full twenty-element canvas for one real process in your organisation. Then have a colleague attack it: for each element, they must name a way it could fail. Revise. This exercise routinely finds three to five design flaws that would have surfaced only in production.

The Anatomy of an AI Agent