Testing & Reliability

Start with the hardest truth, because it reframes everything else: an unreliable agent is not a weak version of a good one - it is a distinct and greater hazard, and understanding why sets the stakes for the whole lesson. The reasoning is about human attention. When you do a task yourself, or when you know a tool is unreliable, you stay engaged - you check, you notice, you catch the error. The entire point of an agent is to let you stop doing the task and redirect your attention elsewhere. That is the benefit and the trap in one: the more you come to rely on an agent, the less you watch it, so an agent that is right most of the time trains you into trust, and then its occasional failure arrives precisely when your guard is down and lands unchecked in real work.

This is why consistency matters more than peak performance for anything you intend to rely on. An agent that is brilliant eight times and disastrously, silently wrong twice is far more dangerous than one that is merely good but dependable every time, because the brilliance earns the trust that the failures then exploit. In a professional context the asymmetry is stark: the cost of the silent failure - a wrong dimension carried into a drawing, an invented code clause in a spec, a miscalculated quantity in a tender - can dwarf the accumulated savings of all the times it worked. A tool you cannot trust to fail loudly is a tool you cannot safely stop watching, which means it never delivers the delegation benefit it promised anyway.

The professional consequence follows directly, and it is the through-line of the course made concrete. Because you remain the author and the architect of record, the reliability of the agents you use is your responsibility, not the tool's - 'the agent was usually right' is no more a defence than 'the AI did it.' So before you rely on an agent for anything that matters, you must earn that reliance through the discipline of the rest of this lesson: test it, evaluate its output, make it fail safely, and monitor it. Reliability is not the agent's job to have; it is your job to establish. The reward for doing so is real - a dependable agent genuinely lets you delegate and stop watching a slice of work - but that reward is only safe once you have done the work to deserve the trust.

You would not rely on a new employee's work without checking it, or trust a formula in a spreadsheet without testing it on cases you know the answer to - and an agent deserves exactly that scrutiny before you depend on it. Testing an agent means running it against known cases and seeing whether it produces the right result. Assemble a set of representative inputs where you already know what good output looks like - including the normal cases, the tricky edge cases, and the deliberately awkward ones - and run the agent across them. Does it get the straightforward ones right? Does it handle the odd ones sensibly, or fall apart? Does it do something dangerous when given a malformed or unexpected input? This is the software-testing instinct applied to agents, and it is the difference between hoping an agent works and knowing where it does and does not.

Evaluation is the ongoing companion: judging whether the agent's outputs are actually good, not just whether it produced something. This matters more for agents than for ordinary software because agents are non-deterministic - the same input can yield different outputs - and fluently plausible even when wrong, so 'it returned an answer' tells you nothing about quality. A practical evaluation layer has two levels. First, automatic checks a machine can perform: is the output in the right format, are the numbers within a sane range, are sources cited, is anything obviously missing, does it contradict itself. These catch the gross failures cheaply and can run on every output. Second, and irreplaceable, human evaluation for the judgement a machine cannot make: is this actually correct, appropriate, well-reasoned, right for this project. The pattern is to let automatic checks screen everything and route anything that fails a check - or anything high-stakes - to a human, so attention lands where it is needed.

A quiet but powerful idea here is using AI to help evaluate AI - having a model check another agent's output against criteria - which can scale the first-pass screening usefully. But treat it with clear eyes: an AI evaluator has the same fallibility as the agent it checks, so it is a helpful filter, never the final word, and it never removes the human from the high-stakes judgement. The honest summary is that testing tells you whether an agent is fit to rely on before you do, and evaluation keeps telling you whether its output is good each time you use it - and for anything that matters, a human makes the final call. Build both in, and you replace blind hope with earned confidence; skip them, and you are trusting a fluent stranger with your professional name.

No agent is perfect, so a dependable one is not defined by never failing but by failing safely and visibly - and by being watched closely enough that you notice when it starts to. The first discipline is graceful failure. When an agent hits something it cannot handle - a tool that is down, an input it does not understand, a step that errors, an answer it is unsure of - the worst outcome is that it plough on and produces confident garbage, or fails silently and leaves a gap you do not see. The design goal is the opposite: an agent should fail loudly and safely - stop, flag that it could not complete the task, hand off to a human, and above all not pass a broken or fabricated result downstream as if it were sound. This is why instructing an agent to say 'I could not do this' or 'I am not sure' rather than to guess (Module 2.1) is a reliability feature, not just good manners: a known failure you can catch is vastly safer than a hidden one you cannot.

The complement to safe failure is fallback: what happens when the agent cannot do the job. For consequential work the fallback is almost always a human - the task routes to a person rather than being dropped or faked - and for a pipeline it may mean pausing the whole flow rather than letting a bad output propagate. Designing the failure path deliberately, rather than discovering it in a live project, is a hallmark of an agent built to be relied upon.

The final discipline is monitoring, because reliability is not a property you establish once but a state you maintain. An agent that passed your tests in March can degrade for reasons that have nothing to do with you: the underlying model is updated and behaves differently, an API it depends on changes, the kind of inputs it receives drifts away from what you tested, a connected tool breaks. Without monitoring, that degradation is invisible until it causes a problem - the silent failure again. So an agent you rely on needs watching in use: keep a log of what it does, spot-check its output on a schedule even once you trust it, notice when its behaviour or your correction rate shifts, and be ready to pause, fix or retire it. This closes the reliability loop - test, evaluate, handle failure, monitor, and feed what you learn back into better tests - and it is why reliability is a practice, not a setup. The agents worth relying on are the ones someone is quietly, continuously making sure still deserve it.

Pulling the module together, the question that should govern whether you deploy any agent you have built is simple: have I earned the right to rely on this for what I am about to use it for? The answer is proportionate to the stakes - a no-code flow that drafts internal notes needs far less than a custom agent that writes figures into a tender - but the shape of the standard is the same, and it is worth holding as a checklist for anything you intend to depend on.

Have you tested it against known cases, including the awkward ones, and do you know where it works and where it does not? Have you built an evaluation step - automatic checks for what a machine can catch, and a human check for the judgement it cannot - with high-stakes output always reaching a person? Does it fail safely - stopping and flagging rather than fabricating or failing silently - with a deliberate fallback, usually to a human, for what it cannot handle? Are you monitoring it in use, so drift and breakage surface before they cost you? And is the level of all this proportionate - lighter for low-stakes, rigorous for anything touching safety, code, cost or a client commitment? An agent that clears this bar for its intended use is one you can responsibly rely on; one that does not is a demo, however impressive, and should stay supervised until it earns more.

Hold this without either fear or naivety, because that balance is the whole spirit of the course. The fearful response - never trust an agent, do everything by hand - throws away the genuine benefit; the naive one - deploy the impressive demo and assume it will keep working - invites the silent failure that lands under your name. The professional path is the middle: build agents boldly, earn the right to rely on them through testing, evaluation, safe failure and monitoring, and keep that reliance proportionate to the stakes and always under your responsibility as the author and architect of record. A flaky agent is worse than none; a well-tested, well-monitored, gracefully-failing agent is a genuine multiplier of a practice. The difference between them is not luck or the tool's quality - it is this discipline, and it is yours to apply.