Practical, framework-specific guides for debugging AI agents in production. CrewAI, LangGraph, AutoGen, OpenClaw, and custom Python agent fleets, written from the failures our support fleet actually sees. Not a substitute for the $99/month on-call subscription, a preview of the kind of problem it solves.
CrewAI
The failures that only appear once a crew runs for real: tools that return without working, context that does not survive a handoff, and loops that are specification bugs rather than reasoning bugs.
Observability
The four signals that actually explain an agent failure, and why latency, error rate and token spend miss the failures that return HTTP 200.
Tooling
Criteria rather than a feature table: the four questions that separate a tool built for agent behaviour from one built for prompt logging, and how to test a candidate against an incident you have already had.
Almost every agent failure that reaches us returns HTTP 200. The run completes, the response is well-formed, the latency is normal, and the answer is wrong. That is the whole problem in one sentence, and it is why ordinary application monitoring reports a healthy system through the exact incidents it exists to catch.
The reason is structural. A tool that fails usually hands the agent a string describing the failure, and a string is precisely what a language model is built to reason over. It reads "error: timeout" as an observation and writes around it. Nothing raises. Nothing is logged as an error. The failure enters the output as confident prose.
So the useful question is never "did it error". It is what did the agent see, what did it believe, and how many times did it try. Both guides below are versions of that question: one for instrumenting it before you need it, one for the specific shapes it takes in a CrewAI crew.
Latency, error rate and token spend are the three things most teams already collect, and all three miss the failures above. These four do not.
Read the full observability guide →
A crew that behaves in development and misbehaves under real load usually fails in one of five ways, and only one of them is what teams initially suspect.
Read the full CrewAI debugging guide →
Because the failure reached it as text. Tools that catch an exception and return a string are handing the model an observation, and the model reasons over observations. Make failures structurally distinguishable from results, rather than describing them in prose the agent will read as data.
Because it watches the transport, not the reasoning. A failed agent run and a successful one produce the same status code, similar latency and comparable token spend. Everything a dashboard measures stays inside its normal band while the answer is wrong.
A repetition counter: how many times one run calls the same tool with the same arguments. It is a few lines of code, it needs no new infrastructure, and it catches stuck agents that are invisible to every latency-based alert.
No, and treating it as one wastes time. What should be stable is the shape of the result and the boundaries between agents, not the wording. Assert that the handoff carried the required fields and that the tool was called at all.
No. It tells you which of these happened, which is the part teams usually spend longest on. The fix is still a change to a tool contract, a task specification or a handoff payload.