We build a free learning lab on agentic AI, and the section we've spent the most time on is the one about things going wrong. It has a topic on failure modes, a topic on debugging agents, and a small Failure Lab with four scenarios: an agent that loops forever, the wrong tool selected, stale memory used, and sensitive data exposed.
Writing it changed how we think about agents. Most agent failures we wrote up aren't the model being "not smart enough". They're missing controls around the model. Here are the five patterns we keep coming back to, and what we teach as the fix for each.
An agent is a loop: plan, act, observe, decide. The decide step is where things break. In one of our simulations, an agent doing incident triage keeps retrying the same log query. Reading the trace shows why: there is no maximum-iteration rule and no check for repeated actions.
That's a loop-control failure, not a model-intelligence failure. A better prompt won't fix it. The fix is a set of stop rules: a cap on retries, a threshold for "is this still improving?", and escalation to a human when the budget runs out. Then add the scenario as a regression test so it's caught next time.
Tools are where a harmless assistant becomes an operational risk. An agent that only needed to read something calls something that writes. Our cheat sheet for this topic is three lines: separate read tools from write tools, put approval in front of high-impact tools, and validate tool outputs before using them.
One practice lab makes this concrete. A DevOps agent can read CI logs, create tickets, change config and trigger deployments. Letting it do everything "because it's smart" scores worst. Disabling every tool is safe but low-value. The best answer matches controls to risk: read logs automatically, create tickets with an audit trail, and require approval for config changes and deploys. Intelligence does not replace policy.
Agent memory isn't one thing. It's short-term context, working state, traces of past runs, durable facts and domain knowledge. When durable memory isn't refreshed, the agent confidently uses something that used to be true.
What we teach: give durable facts provenance (where did this come from, and when?), check freshness and permissions before relying on context, and be selective about what you write back. Our memory lab asks what should be stored after a workflow finishes. Storing every intermediate thought is poor hygiene and a privacy risk; storing nothing throws away useful knowledge. The answer is validated decisions, final artefacts, provenance, the risk outcome and reusable patterns.
In multi-agent systems, one agent hands work to another, and it's tempting to hand over everything "so it has full context". Our debugging scenario is exactly this: a support agent passes too much customer context to a specialist agent.
The fix is a context slice, the minimum relevant information for that step, plus least privilege and redaction for anything sensitive. It also makes the specialist's job easier: less noise in, better answers out.
This is the one that worries us most. Some steps fail, and the final answer hides it. The user sees a fluent, complete-looking response, and nobody knows that two of five tool calls errored out.
You can't catch this by reading the final answer. You need tracing: a record of which model, prompt, tool, memory and policy decision produced each result. Without traces, an agent system can't be debugged, audited or trusted.
Across all five, the workflow we teach is the same:
Two rules from our cheat sheet sum it up: don't fix every failure with prompt changes, and turn every serious incident into an evaluation case. One simulation shows the whole loop. An agent decides to change code before reading the logs. A policy gate blocks the write because there's no evidence. The runtime routes it to log analysis first, the fix recommendation has to cite the error signature, and the scenario goes into the replay suite.
The Agentic AI Systems Lab is free and needs no sign-up: 24 topics across beginner, engineer, architect, product and safety paths, four practice labs, four case studies and the Failure Lab. Each topic has an analogy, a step-by-step simulation, a quiz and flashcards, and there's a Teacher Mode if you're running a session.
https://annapurnaagenticsolutions.com/ We're moving it onto our website now. See what we're building and tell us what you think.
If you've shipped agents, I'd love to hear which failure pattern we're missing. That's the next thing we'll add. Annapurna Sarangi, Annapurna Agentic Solutions, Bengaluru