Build An AI Agent That Works

AI agents that look extraordinary in testing fail in production every week — and almost never for the reasons people assume. In this lesson, you'll learn why the technology is rarely the problem, and why the decisions made before the build starts determine whether a project succeeds or quietly gets shelved.

You'll walk through the three root causes behind the majority of failed agent projects: choosing a process that relies on implicit knowledge an agent can't access, setting expectations that no agent could meet, and launching without a defined success metric. Each cause is preventable — if you know what to look for.

By the end of this lesson, you'll have a sharp new filter for evaluating any agent idea before a single line of logic is written. You'll be able to spot the warning signs early, frame expectations correctly, and define what success actually looks like — in writing, before the work begins.

Every AI agent that delivers real value does one of five things. In this lesson, you'll learn exactly what those five things are — and how to use them as a rapid test for any agent idea you're considering.

The Five Business Cases framework (delay reduction, cost reduction, quality improvement, response speed, and human effort reduction) keeps you anchored to the problem rather than the technology. You'll explore each case with concrete examples, understand the signals that indicate which case applies, and learn the common mistakes that cause people to misidentify or overstate a business case.

By the end of this lesson, you'll be able to take any proposed agent use case, map it to a specific business case in under two minutes, and immediately identify whether it has a legitimate reason to be built — or whether it's interesting without being useful.

The best source of high-value agent opportunities isn't a consultant or a process audit — it's already inside your organisation. In this lesson, you'll learn how to surface your strongest use cases in under a day by listening to the people who do the work.

You'll discover why the tasks employees groan about are almost always exactly the right profile for a first agent build: high-volume, low-variability, and deeply frustrating. You'll learn the four questions to ask, the three signals to listen for, and a simple scoring method that turns a room full of complaints into a ranked shortlist of genuine opportunities.

By the end of this lesson, you'll know how to run the Employee Complaint Test with any team, filter the results for real agent suitability, and walk away with three strong candidates ready for the final evaluation in the next lesson. You'll also know how to handle the resistance that sometimes comes up — and how to turn sceptics into collaborators.

The most common mistake in a first agent build is trying to make it impressive. In this lesson, you'll learn why your first build should be deliberately boring — and exactly what profile to look for when choosing it.

You'll explore the three criteria that define a strong first build (volume, clarity, and reversibility), and work through seven proven archetypes that consistently make excellent starting points: from high-volume customer interactions and document-heavy workflows to data classification and internal operations support. Each archetype is broken down with examples and a clear explanation of why it works as a first build.

By the end of this lesson, you'll have a scoring worksheet to evaluate your top candidates against all three criteria, a clear framework for matching your use case to a proven archetype, and a single first build identified, with a specific success definition written down. You'll also leave with the right mindset: your first agent isn't a product launch, it's an experiment with teeth.

Most agent projects go wrong before a single line of logic is written — not because the technology fails, but because nobody wrote down precisely what the agent was supposed to do. In this lesson, you'll learn how to create the Agent Brief: a one-page document that takes ninety minutes to produce and saves months of rework.

You'll walk through all six elements of the brief — purpose statement, stakeholders, constraints, success criteria, failure conditions, and review cadence — and learn what separates a weak, generic version from one that every team member and stakeholder can build from with confidence. You'll also see exactly how to structure a purpose statement that contains a trigger, a task, a standard, and a boundary.

By the end of this lesson, you'll have a completed Agent Brief template ready to fill in for your own build — and you'll know how to run the sign-off meeting that gets every stakeholder aligned before work begins.

Every agent workflow — regardless of complexity, industry, or technology — contains the same four elements. In this lesson, you'll learn what those four elements are, why missing any one of them creates a gap that only shows up in production, and how to use them as a design checklist before any build begins.

You'll explore each element in depth: the Trigger (what starts the agent), the Task (what the agent does between trigger and output), the Output (what the agent produces — including how to specify a graceful failure), and the Handoff (what happens when the agent reaches its limit and a human needs to take over). For each one, you'll see the most common design failure and how to avoid it.

By the end of this lesson, you'll be able to apply the four-element framework to any agent design, answer all four qualifying questions with precision, and identify exactly where a design has gaps before a developer writes a single line of code.

Every agent design has two parts: what the agent does, and what it must never do under any circumstances. Most teams focus intensely on the first part. In this lesson, you'll learn why the second part matters just as much — and how to define it before the build, rather than in response to a mistake.

You'll learn the difference between hard boundaries (absolute, non-negotiable, encoded into the design) and soft boundaries (defaults that can be adjusted by an authorised person). You'll work through a set of stress-test scenarios designed to surface the boundaries you haven't thought of yet, and you'll learn the single most important quality check: could a developer implement this boundary without asking a single clarifying question?

By the end of this lesson, you'll have a complete set of boundaries for your agent — written in precise, unambiguous language — and you'll understand why well-defined boundaries don't constrain your agent's capability. They're what make it safe enough to actually deploy.

Every build decision — what tools to connect, how to write the system prompt, how to define the handoff — should be answerable by a single sentence. In this lesson, you'll learn how to write that sentence: the goal statement, a precise and testable description of what your agent must achieve.

You'll learn the four-component formula (actor, action, standard, condition), see the three most common mistakes that make goal statements useless as design anchors, and work through a structured writing process that takes you from a rough idea to a final, agreed statement. You'll also learn how to use your goal statement as the acceptance test for your completed build.

By the end of this lesson, you'll have a finished goal statement for your first agent — specific enough to be measured, clear enough to recite from memory, and precise enough that every team member is building toward the same outcome.

An agent can meet its goal statement, stay within its scope boundaries, and still fail — because it doesn't actually serve the user, or because the experience doesn't match what users were promised. In this lesson, you'll learn how to run the Alignment Test: a structured three-part check that confirms your agent goal, business need, and user experience are all pointing the same direction before the build starts.

You'll work through all three checks in detail — verifying that the goal is directly traceable to a real business need, that the user (not just the commissioning stakeholder) genuinely benefits from the design, and that what you'll tell users about the agent matches what it actually does. You'll also learn how to score each check and what to do when a check comes back as a blocker.

By the end of this lesson, you'll have completed the Alignment Test for your own design and you'll know exactly what "ready to build" looks like. You'll finish Section 2 with an Agent Brief, a workflow design, defined scope boundaries, a testable goal statement, and confirmed alignment — more preparation than most agent projects ever do.

An autonomous agent works while you're in another meeting, while you're asleep, while nobody is watching. That's the point — and it's also the risk. When an agent makes a mistake at scale, the mistake scales with it. In this lesson, you'll learn what damage limitation actually means: not making agents slow or overly cautious, but designing them so that mistakes are detectable before they cause harm, reversible before they become permanent, and contained so they don't cascade.

You'll work through the mistake spectrum — mapping agent actions from low-severity misclassifications to high-severity financial commitments — and learn how to match the right control to the right level of risk. You'll also learn the three practical controls used in production agent design: human-in-the-loop checkpoints, dry-run mode, and rate and scope limits.

By the end of this lesson, you'll have a framework for assessing the severity of every action your agent can take, a clear understanding of which controls apply at each severity level, and the right mindset for earning greater agent autonomy over time.

Can a human undo this action in under five minutes, with no external dependency, and no lasting consequence? That's the Reversibility Test — one question, applied to every action your agent can take. In this lesson, you'll learn why reversibility is a more useful frame than probability when designing for agent safety, and how to use it to build a tiered control structure that matches your agent's actual risk profile.

You'll work through the reversibility spectrum — from fully reversible actions that can run freely, to partially reversible actions that need a confirmation window, to irreversible actions that require human approval without exception. You'll also learn where to document the classifications so that every developer and stakeholder is working from the same picture.

By the end of this lesson, you'll have classified every action your agent can take, designed the appropriate control for each category, and documented the full reversibility picture in your Agent Brief — giving you a clear path to safe, confident deployment.

Every new agent starts with low autonomy — and that's exactly right. Autonomy is the product of trust, trust is the product of evidence, and evidence comes from supervised operation over time. In this lesson, you'll learn the Earned Autonomy framework: a structured system for moving your agent from supervised to monitored to trusted, with data and formal sign-off at every step.

You'll explore the three stages of agent autonomy in detail, the specific promotion criteria required to move between each stage, and the three metrics — agreement rate, exception rate, and recovery time — that drive every promotion decision. You'll also learn why earned autonomy is not a one-way door: an agent that regresses can and should return to a more supervised stage until the evidence supports moving forward again.

By the end of this lesson, you'll know how to set up the measurement infrastructure your agent needs, define the promotion criteria before launch, and build the kind of compounding trust that makes internal resistance to AI agents drop — not through arguments, but through a track record people can see.

The Scoping Principle comes from computer security: give any system only the access it needs to do its job, and nothing more. In this lesson, you'll learn how to apply this principle to AI agents — defining minimum permissions, explicit capability lists, and three-dimensional scope across data access, action authority, and tool access — so that your agent does exactly what you designed, and nothing you didn't.

You'll learn why scope creep is a safety problem rather than a project management one, how small "while we're at it" additions collectively create an agent whose capabilities nobody has fully mapped, and how to prevent that from happening through forced confirmation steps and automatic escalation triggers. Every rule is practical and specific — each one is a line in your design document before it's a line in your code.

By the end of this lesson, you'll have a complete scope definition for your agent, a set of confirmation steps for boundary actions, a defined escalation trigger system, and a summary card ready to paste into your Agent Brief. Section 3 is complete — you'll have everything you need before going inside the agent itself in Section 4.

Which AI model should you use? It's one of the most debated questions in any agent project — and almost never the most important decision. But it still has to be made well, because choosing the wrong model class costs you money, time, or quality. In this lesson, you'll learn the clear, practical distinction between standard models and reasoning models, and exactly when each one earns its place in your build.

You'll learn what makes these two classes fundamentally different — not just in cost and speed, but in the type of task each is built to handle — and you'll get a step-by-step testing protocol for choosing between them without guessing. You'll also learn the most expensive mistake builders make when selecting models, and why reviewing your model choice quarterly matters at production scale.

By the end of this lesson, you'll have a clear decision framework for model selection, understand the test protocol that eliminates guesswork, and know why the model is one of nine components — and why the next lesson matters more.

The system prompt is the most influential document in your entire agent build. It's read before every user message, before every tool call, before every response. And most teams spend less time on it than they spend naming the project. In this lesson, you'll learn the anatomy of a system prompt that actually works — and the one technique that unlocks consistent agent behaviour above everything else.

You'll work through all six sections of an effective system prompt: role definition, core task description, rules, constraints, tone and voice, and output format. You'll learn the difference between instructions that tell the agent what to do and examples that show it — and why a well-chosen example does more to shape behaviour than three paragraphs of instructions ever will.

By the end of this lesson, you'll have a complete, fillable system prompt template for your own agent, a clear understanding of how to write few-shot examples that actually change behaviour, and a version-control approach that lets you test, refine, and improve your prompt with confidence.

When an agent fails in production, the instinct is to blame the model. In almost every case, the problem is in the system prompt — and it falls into one of four patterns. In this lesson, you'll learn to recognise all four, diagnose them quickly, and run a pre-launch audit that catches them before they cost you weeks of rework.

You'll work through each failure pattern in detail: vague rule definitions that produce inconsistent behaviour, missing examples that leave the agent guessing about quality standards, the absence of a stop condition that causes agents to run too long or stop too early, and conflicting rules that produce outputs satisfying neither rule. For each pattern, you'll see the diagnostic test and the fix.

By the end of this lesson, you'll have a repeatable 40-minute pre-launch prompt audit that you can apply to every agent before it goes to production — a process that prevents failures that would otherwise take four weeks to diagnose and fix.

Every large language model has a context window — a fixed amount of information it can hold at once. What goes in determines what the agent knows. What it knows determines what it does. In this lesson, you'll learn the discipline of context engineering: the practice of deliberately deciding what fills that window, and why it shapes agent performance more than most builders expect.

You'll learn what elements compete for space in the context window, how to apply an include/compress/remove framework to every piece of information in your design, and how retrieval-augmented generation (RAG) works in plain language — giving knowledge-based agents access to relevant content without trying to fit an entire knowledge base into a single interaction.

By the end of this lesson, you'll understand why context engineering is a design decision rather than a technical one, know how to make deliberate trade-offs between context elements, and have a clear process for reviewing and improving your context design as your agent matures.

An agent that forgets who users are destroys its own value instantly. Memory is what separates a useful agent from a frustrating one — and what makes it start to feel like a colleague rather than a tool. In this lesson, you'll learn a practical framework for building agent memory that works, covering three distinct memory layers and the four categories of content that belong in persistent storage.

You'll explore the trade-offs between in-context, external, and model-weight memory; learn the four categories of what gets stored (including the most commonly omitted one — correction history); and get a simple, practical memory architecture that most production agents can start with. You'll also learn how memory goes wrong in both directions — too little and too much — and how to build expiry logic that keeps memory accurate over time.

By the end of this lesson, you'll know how to design a memory system that makes your agent feel intelligent and consistent, avoid the stale-memory failures that quietly undermine agent trust, and understand why good memory compounds — driving adoption, data, and continuous improvement.

An agent without tools can only generate text. Tools are what give an agent reach — transforming it from a sophisticated text generator into an autonomous actor that can look things up, take actions, and interact with external systems. In this lesson, you'll learn how tool use actually works at the architecture level, the three categories of tools and the risks each carries, and what makes the difference between a well-integrated tool and one that quietly causes your agent to behave inconsistently.

You'll work through the four properties every API connection must have before it's connected to an agent — specificity, schema, error handling, and rate limits — and learn why investing in tool quality is just as important as investing in prompt quality. You'll also learn the start-small principle and why a well-integrated set of three tools consistently outperforms a loosely connected set of ten.

By the end of this lesson, you'll have a tool quality checklist for every connection you build, a clear framework for categorising tools by risk level, and the right approach to adding tools incrementally — so your agent stays reliable as its capabilities grow.

An agent with tools, memory, and a system prompt can do a lot. The orchestration layer decides when to do each of them — and, more importantly, when to stop. In this lesson, you'll learn the two concepts that define good orchestration design: bounded authority and stopping rules. Together, they give you an agent that behaves predictably, can be debugged systematically, and can be trusted with increasing autonomy over time.

You'll learn the difference between hard-coded controls that live in the orchestration layer and cannot be overridden, and soft-coded defaults that give you operational flexibility while keeping safe behaviour as the baseline. You'll also design stopping rules tied to output state rather than time — for both successful completion and failure cases — and map your agent's sequence in plain language.

By the end of this lesson, you'll have a complete orchestration design for your agent: a step-by-step sequence, hard and soft controls defined, stopping rules for every outcome, and a plain-language test that confirms the design is modular, predictable, and debuggable before a line of code is written.

Between every trigger and every output, your agent runs a five-step loop: observe, reason, decide, act, evaluate. It runs this loop on every task, whether it takes two seconds or twenty minutes. Understanding this loop doesn't make you a developer — it makes you a better designer, because you can anticipate where the loop breaks before it does, and trace failures back to their origin when they occur.

You'll work through each of the five steps in detail — what the agent does, what can go wrong, and what design decision prevents that failure. You'll see why loop failures propagate across steps rather than appearing at a single point, and how to trace unexpected outputs back to the exact step where the error originated. You'll also get a five-question pre-build checklist that validates the loop design before the build starts.

By the end of this lesson, you'll be able to apply the decision loop framework to your own agent design, validate all five steps against a clear checklist, and use the loop as a diagnostic tool when agent behaviour in production doesn't match your expectations.

Eight of the nine agent components are completely invisible to the people using your agent. They see the interface: how they start an interaction, how the agent responds, and how the interaction ends. In this lesson, you'll learn how to design entry and exit points deliberately — for every user journey, including the ones that don't go as planned.

You'll explore the four entry point types (chat interface, form, API trigger, and event trigger), how to match each to the right use case, and the hidden risks each one carries. You'll also learn how to design exit points for the full range of user journeys: the happy path, the escalation, the graceful failure, and the abandoned interaction — because an exit point you haven't designed is an experience you haven't controlled.

By the end of this lesson, you'll have a complete interface design for your agent, a graceful failure message ready for the situations where the agent meets its limits, and a counterintuitive but essential piece of advice about when to test the interface — before the backend is fully connected. Section 4 is complete. Nine components. One coherent system.

When you choose a build tool, the real decision isn't which platform is best — it's which layers of your agent you need to own. In this lesson, you'll learn a mental model that makes every build decision clearer: the three-layer stack that every agent is built on, regardless of how it was constructed or which platform it runs on.

You'll explore each layer in detail — the model layer (the AI reasoning engine), the orchestration layer (the coordination logic), and the interface layer (what users actually interact with) — and learn how different build approaches give you different levels of control at each one. You'll also work through three practical questions that map directly to a build recommendation: no-code, hybrid, or code-first.

By the end of this lesson, you'll have a vocabulary for making and challenging agent architecture decisions, a clear framework for evaluating any platform or vendor against your actual requirements, and the confidence to ask the right questions — even if you'll never write a line of code yourself.

No-code agent platforms are genuinely excellent for a specific set of use cases — and genuinely limited for others. In this lesson, you'll get an honest picture of both. The goal isn't to recommend a specific tool — platforms change faster than any course can keep up. The goal is to give you the framework to evaluate any no-code platform confidently, before you're committed to it.

You'll learn exactly which use cases no-code platforms are built to handle and where they hit their ceiling, work through five essential evaluation questions that reveal what a platform can and can't do for your specific requirements, and learn what the vendor lock-in conversation looks like before you're locked in. You'll also get a requirements-matching test that gives you a clear answer about platform fit.

By the end of this lesson, you'll have a complete evaluation worksheet for any no-code platform you're considering, a clear threshold for when a platform is the wrong fit, and a data governance checklist that surfaces the compliance questions that need to be answered before any platform decision is made.

Code-first frameworks give you full control over all three layers of the agent stack. Nothing is abstracted. Everything is customisable. That power comes with real trade-offs — in time, expertise, and ongoing maintenance responsibility — and for many use cases, it's exactly the right choice. In this lesson, you'll learn what code-first frameworks actually provide, what they demand in return, and when they're clearly the better option over a no-code platform.

You'll work through what code-first frameworks handle for you (so you understand why they're not starting from scratch), the full set of demands they place on your team and infrastructure, and the five specific situations where code-first is the right call — any one of which is sufficient justification. You'll also learn the minimum team structure for a first code-first build and the hybrid path that most mature agent deployments eventually follow.

By the end of this lesson, you'll know whether code-first belongs in your current or future plans, what team structure makes it viable, and why you don't need to choose your final architecture on day one — just the right starting point.

No agent build is without failures. The question is how quickly you find them — and at which layer. Most teams waste hours debugging the wrong thing: changing the prompt when the problem is in the tools, or rewiring the orchestration when the problem is in the model. In this lesson, you'll learn a structured diagnostic map that matches symptoms to their most likely layer of origin — so you can find and fix failures in minutes, not weeks.

You'll work through the failure signatures for each of the three layers — model, orchestration, and interface — including the specific symptoms to look for, the most likely causes, and the diagnostic action that confirms or rules out each layer. You'll also learn how to recognise cross-layer failures, where a problem appears in one layer but originates in another, and how to trace any failure backwards from its output to its root cause.

By the end of this lesson, you'll have a ready-to-use diagnostic reference card for your agent, a pre-launch preparation plan that identifies who to call and what to test before the first production failure occurs, and the diagnostic mindset that separates calm, systematic debugging from expensive guesswork. Section 5 is complete — you have a build pathway and a failure plan.

Voice agents and text agents share the same underlying models — the same reasoning engine, often the same knowledge base. But they are not the same design problem. Designing for one and deploying to the other is how voice agent projects fail. In this lesson, you'll learn the fundamental principle that drives every voice design decision and why the shift from text to voice requires you to rethink response structure, latency tolerance, error recovery, and how you test.

You'll explore the core difference between how users experience text and voice interfaces, learn the specific ways voice changes response design (length, structure, and confirmation frequency), and understand why latency that's perfectly acceptable in text becomes alarming in voice. You'll also learn how to design voice error recovery as a script — and why testing it with your ears rather than your eyes is non-negotiable.

By the end of this lesson, you'll understand why voice is a genuinely different design discipline, have a clear framework for the changes it requires across every element of agent design, and know the testing protocol that separates voice agents that work from those that merely function.

Build a voice agent using text agent design principles and it will be technically functional and experientially poor. Users will find it frustrating without being able to explain why — and they'll stop using it. In this lesson, you'll learn the seven design differences that separate voice agents that work from those that merely operate, and the specific rules that apply to each one.

You'll work through all seven differences in detail: turn structure and why pause detection must be tuned for your user population; interruption handling and why an agent that ploughs through its script after being interrupted sounds deaf; confirmations as the user's protection against irreversible voice actions; seamless escalation that passes context rather than making users repeat themselves; the two-sentence response rule; the shift from formatting to narrative; and designing a voice persona at the word level, not the document level.

By the end of this lesson, you'll have a response checklist for every piece of voice content you write, a clear understanding of why all seven differences are design requirements rather than preferences, and the guiding principle that the design is the product — and the technology is just the delivery mechanism.

Voice agents are not a premium version of text agents. They are a different tool, suited to specific contexts where voice is the natural or only mode of interaction. Deploying voice where text would serve better doesn't create a better experience — it creates an expensive one. In this lesson, you'll learn which use cases genuinely call for voice, which ones don't, and a three-question test for making the right call every time.

You'll explore the three highest-value contexts for voice agents — inbound customer calls at scale, field worker support where hands-free is a functional requirement, and accessibility-first products where voice is the primary interface for users for whom text creates a significant barrier. You'll also learn the four use case types where voice consistently fails to deliver value, and why high-stakes commitments should never be confirmed by voice alone.

By the end of this lesson, you'll have a clear use-case map for voice versus text, a three-question decision framework you can apply to any proposed voice deployment, and the core principle that the best voice agents exist not because voice is modern or impressive, but because voice was the right answer to a specific problem.

Choosing an AI vendor isn't a procurement decision — it's a strategic one.

The model you rely on shapes what your agent can do, and the wrong choice is expensive to undo. In this lesson, you'll work through a structured vendor scorecard covering six critical dimensions: capability against your actual use case, reliability and uptime history, security and data practices, pricing economics at scale, lock-in risk, and the vendor's support and roadmap.

By the end, you'll have a repeatable framework for making vendor decisions based on evidence rather than demos or enthusiasm.

Every vendor conversation is loaded with technical terminology — context windows, RAG, fine-tuning, token costs, rate limits, SLAs.

Knowing what these terms actually mean is what separates someone who gets vague answers from someone who gets specific, accountable ones.

This lesson decodes the vocabulary you'll encounter most often, not to make you a technical expert, but to make you an informed commissioner. You'll finish the lesson knowing how to ask sharper questions — and how to recognise when an answer doesn't hold up.

A vendor demo can make the technology look impressive. It proves nothing about whether it works for your use case.

In this lesson, you'll design and run a structured two-week proof of concept that tests core capability, edge case performance, and operational fit against your actual requirements.

You'll learn how to build a test suite of 30 cases, score outputs objectively, and produce a PoC report with a clear go/no-go recommendation. If you're evaluating multiple vendors, you'll also learn how to run a controlled comparison that makes trade-offs explicit rather than leaving them to gut feel.

Most agent builds don't fail because of what gets built — they fail because of the order in which it gets built. Start with the interface, and you're putting a facade on a building that hasn't been structurally completed.

In this lesson, you'll learn the five-step build sequence that every successful agent follows: system prompt, tools, memory, orchestration, and interface — in that order, for a reason.

You'll understand why each step depends on the one before it, how skipping steps creates hidden technical debt, and how to build this sequence into a realistic project timeline. Following the right build order isn't perfectionism — it's risk management.

Traditional software testing is built on a simple principle: given input A, the system always produces output B. Agents don't work that way.

They're probabilistic, and that changes everything about how you test them. In this lesson, you'll learn the principles that govern agent testing — why quality evaluation can't be fully automated, why adversarial testing is non-negotiable, how to handle regression testing when a model update can silently change your agent's behaviour, and why testing is an ongoing operational practice, not a pre-launch phase.

Get this right and your test results will be meaningful. Get it wrong and you'll be measuring the wrong things entirely.

This lesson builds your agent's test suite from the ground up — not in theory, but as a practical structure you can apply before your agent goes live.

You'll work through all four test layers: golden path tests that confirm core behaviour, edge case tests that probe the boundaries, adversarial tests that check whether the agent can be pushed outside its defined scope, and failure mode tests that confirm the agent degrades safely rather than silently.

You'll also set scoring criteria and launch thresholds before testing begins — because what you measure, and what you accept, determines whether the results actually tell you anything useful.

Every production failure looks unique on the surface. Underneath, almost all of them are one of four patterns: hallucination, loop stall, scope escape, or tool misuse.

This lesson teaches you to recognise each one on sight — what causes it, what it looks like in the decision loop, and how to fix the root cause rather than the symptom.

You'll also learn how to build a failure log that turns production incidents into design intelligence, so that every failure your agent generates makes the system more capable rather than just more patched.

When your agent behaves incorrectly, you're standing at a fork: is this a prompt problem or an architecture problem? The distinction matters enormously.

A prompt problem takes hours to fix. An architecture problem can take weeks, and misdiagnosing one as the other sends your team in entirely the wrong direction. This lesson gives you a four-question decision tree for making the call accurately, the key signals that distinguish a prompt failure from an architectural one, and what to do when it turns out to be both.

Apply this framework before committing to any fix, and you'll save time that compounds across every agent you build.

You can't prove your agent worked if you didn't record what you were starting from. This lesson makes the case for measuring before you build — and gives you five specific baselines to capture: processing time, error rate, cost per transaction, customer satisfaction, and throughput capacity.

You'll learn how to measure each one properly (not estimate), how to document your method so post-launch comparisons are valid, and how to identify the single primary success metric that answers the question your build was designed to answer.

The organisations that get the most from AI agents aren't the most enthusiastic ones — they're the ones with the best data.

The API bill is not your run cost.

The true cost of operating an agent in production includes model fees, infrastructure, human review time during supervised operation, and ongoing maintenance, and the human review component alone is often larger than the API bill.

In this lesson, you'll model all four cost components, calculate your total monthly cost of operation, and derive a cost per transaction you can compare directly against your pre-deployment baseline. You'll also work through the break-even calculation and the payback period — the number the finance function will ask for, so you should calculate it before they do.

Cost savings are real — but they're only part of what a well-deployed agent is worth. This lesson gives you four ROI formulas that together capture the full financial picture: time saved, error cost avoided, revenue influenced, and capacity unlocked.

You'll work through each formula with examples, learn how to build a twelve-month ROI summary that turns your results into a defensible business case, and understand why the hardest value to quantify — organisational confidence in AI — is also one of the most important outcomes of a successful first build.

At ninety days, the data is in. Now comes the decision. This lesson gives you the framework for making the three-way call — expand the agent's scope, iterate to close the performance gap, or stop and redirect the investment — based on evidence rather than momentum or sunk cost.

You'll learn the specific signals that indicate each path, how to structure a ninety-day review that brings the right people and the right data into the room, and why the discipline to stop a well-intentioned agent that isn't delivering is exactly what makes an AI programme credible over time. Drifting — continuing without deciding — is the only wrong answer.