Most failed agent projects did not fail in code. They failed in the gap between “the business wants an agent that handles supplier onboarding” and the first architectural decision someone made on a Tuesday afternoon without writing anything down.
The 17 agentic primitives give you a vocabulary for that architecture. Tasks, skills, and tools give you a compositional model. But vocabulary and models are not a process. Teams still need a repeatable way to get from a business request to a design that a security reviewer, a platform team, and a product owner can all argue with productively.
The AI Agent Canvas is that process. It is a single-page structure with nine blocks, deliberately modelled on the tradition of the Business Model Canvas and the Event Storming board: not because canvases are fashionable, but because forcing a design onto one page makes omissions visible. An empty block is a conversation you have not had yet.
Why a canvas rather than a document
Enterprise architecture practice already has design documents, and they are not working for agents. Three reasons.
Agent designs couple concerns that documents separate. In a traditional service design, you can specify the API contract, then the data model, then the operational requirements, largely independently. In an agent design, the choice of autonomy level determines the observability requirements, which determine the cost model, which constrains the tool granularity, which changes the autonomy level you can defend. These decisions are mutually constraining. A linear document hides that; a single page exposes it.
The interesting failures are omissions, not errors. Teams rarely specify the wrong escalation path. They specify no escalation path. They rarely choose the wrong success metric. They never define one. Reviewing a document for what is missing is hard. Reviewing a canvas for empty boxes is trivial.
Agent design is cross-functional in an unusual way. A security architect, a compliance officer, a product manager, and an ML engineer all hold veto-relevant information about the same agent. They will not read each other’s twelve-page documents. They will all look at one page.
The nine blocks
The canvas divides into three bands: purpose (why this agent exists), capability (what it can do), and constraint (what stops it doing harm). Work left to right, top to bottom, but expect to revise upward constantly.
Band 1: Purpose
1. Job to be done. One sentence, in business language, naming the outcome and the current owner of that outcome. “Reduce the time between supplier invoice receipt and payment approval, currently owned by three FTEs in accounts payable.” Not “automate invoice processing” — that names an activity, not an outcome, and activities are where scope creep lives.
The discipline here is naming the current owner. If no human currently owns the outcome, you are not automating a process; you are inventing one, and the project is substantially riskier than the sponsor believes.
2. Trigger and boundary. What starts this agent, and what is explicitly out of scope. Triggers are usually easy — an event, a schedule, a user request. Boundaries are where the value is. “In scope: invoices under €50,000 from suppliers already in the master data. Out of scope: new supplier creation, disputed invoices, anything requiring a purchase order match failure investigation.”
Out-of-scope statements are load-bearing. They are what you point at in month four when someone asks why the agent cannot also handle credit notes.
3. Success and failure definition. How you will know this works, and what counts as a failure. Both need to be measurable before build, because retrofitting evaluation onto a deployed agent is how teams end up with agents nobody can defend or decommission.
Specify at least: a task success rate you would accept, a false-positive cost, and a detection method. “94% of in-scope invoices approved without human touch; incorrect approval is a €-value error requiring reversal; measured against a 200-invoice labelled holdout set refreshed quarterly.” This block is where agent evaluation gets designed rather than improvised.
Band 2: Capability
4. Tasks and skills. Decompose the job into the discrete tasks the agent performs, and the skills each requires. This is the block where the tasks-skills-tools model does its work.
The test of a good decomposition: each task should have a recognisable failure mode. “Extract line items from the invoice document” fails visibly. “Understand the invoice” does not.
5. Tools and data. Every external system the agent reads from or writes to, classified as knowledge tools (read-only) or action tools (state-changing). Note the protocol for each — MCP, a direct API, an event stream — and whether it exists today.
Two columns matter more than teams expect. First, mark which action tools are irreversible. Sending a payment, emailing a customer, and deleting a record belong in a different governance tier than updating an internal status field. Second, mark which tools do not exist yet. Agent projects routinely discover mid-build that the “simple API” they assumed is a batch job on a mainframe, which is a very different integration problem.
6. Orchestration and collaboration. How the work is coordinated: a single agent, a sequential or parallel pattern, a multi-agent split, or workflow orchestration with agentic steps embedded. Name the other agents and humans this agent interacts with, and whether the coordination is orchestrated or choreographed.
Default to the simplest pattern that works. Multi-agent architectures are the most over-specified block on most canvases, and coordination cost is consistently underestimated.
Band 3: Constraint
7. Autonomy profile. Where this agent sits on each of the four dimensions of autonomy — task, tool, plan, and collaboration — expressed as a designed level, not an aspiration.
Then the harder question, from the Applied Autonomy Framework: what level can your organisation actually operate? Governance maturity, the agent’s track record, and task consequence all cap the defensible level. Record both the designed and the operable profile. If they differ, the operable one is what you are building, and the gap is your roadmap.
8. Borders and escalation. The specific conditions under which the agent stops and hands off, and to whom. Not “escalate when uncertain” — that is not implementable. Confidence thresholds, value thresholds, exception classes, and named recipients.
Autonomy borders covers the design of these in depth. On the canvas, the requirement is that every border names a destination. An escalation path that ends in an unmonitored queue is a failure mode, not a control.
9. Governance and observability. Identity, authorization, audit, and monitoring. Which identity does the agent act under, and whose authority does it carry? What authorization decisions are enforced, and where? What is logged, retained how long, and reviewed by whom? What are the security boundaries?
This block also carries the operational commitments: cost ceiling, latency budget, and the lifecycle decision of who owns this agent after launch and under what conditions it gets retired.
Using it in practice
Run it as a workshop, not a form. Ninety minutes, the four functions named above in the room, and a facilitator who is allowed to say “that block is still empty.” The canvas is a forcing function for conversation; filling it in alone at a desk produces a document, which is the thing that was not working.
Fill Band 3 before you commit to Band 2. Teams naturally want to design capability first — it is the fun part. But constraint determines feasible capability. An agent whose operable autonomy profile is low does not need sophisticated plan autonomy, and designing it anyway wastes a sprint. Sketch capability, then constrain it, then revise capability down.
Treat empty blocks as findings. The most common empties, in rough order: measurable success definition (block 3), named escalation recipients (block 8), and cost ceiling (block 9). Each is a predictable production problem discovered early rather than late.
Version it with the agent. The canvas is not a pre-build artefact you archive. When the autonomy profile changes because the agent has earned trust, that is a canvas revision and a governance event. The canvas becomes the document a reviewer reads to understand what this agent is supposed to do — which is exactly what you need when debugging what it actually did.
What the canvas does not do
It is not an architecture. It captures the decisions that constrain the architecture, and it deliberately stops short of component design, prompt strategy, model selection, and deployment topology. A completed canvas should let an engineer start designing; it does not replace that design.
It does not validate feasibility. A canvas can be internally coherent and still describe an agent that current models cannot reliably build, because canvases do not know about reasoning limits. Feasibility comes from prototyping against the success definition in block 3.
And it does not substitute for governance process. The canvas surfaces governance requirements; something else has to enforce them. That is the subject of governance patterns and the practical guide to agentic governance.
Key takeaways
The AI Agent Canvas structures agent design across nine blocks in three bands — purpose (job to be done, trigger and boundary, success and failure definition), capability (tasks and skills, tools and data, orchestration and collaboration), and constraint (autonomy profile, borders and escalation, governance and observability). Its value is not the taxonomy but the forcing function: agent design decisions are mutually constraining rather than sequential, the costly failures are omissions rather than errors, and the people holding veto-relevant information sit in four different functions who will only ever read one page together. Fill constraint before finalising capability, treat every empty block as a finding, require every escalation path to name a destination, and version the canvas alongside the agent so it remains the reference for what the agent was supposed to do. It is a design tool, not an architecture, a feasibility study, or a governance process — but it reliably surfaces the decisions that sink agent projects when they stay implicit.