Why logs don't help when an agent fails
The log shows the action happened, which parameters it used, what came back. The one thing it doesn't show is why those parameters were chosen.
- Agentic AI
- Production
Articles
What I learned building agent systems on a platform that manages tens of thousands of devices. Every piece comes out of a system that runs - not a general summary.
The log shows the action happened, which parameters it used, what came back. The one thing it doesn't show is why those parameters were chosen.
Comparison tables open with query latency. On our deployment those numbers decided nothing at all.
The complaint arrives as "the model is making things up". Look closely and it isn't. It is summarising the document it was handed, accurately. The document is wrong.
MCP genuinely lowers integration cost. But what you are standing up is, by definition, a service with programmatic access to internal systems.
The hard part of building an eval set isn't choosing metrics. It's having nothing to measure yet.
Scaling the model when quality drops is the most expensive button on a self-hosted setup. It is usually not the button that needs pressing.
Every step in the chain does its own job correctly and the result is still wrong. Finding where it started takes longer than fixing it.
A tool signature is the definition of what an agent can do in your system. One broad tool erases the guarantees thirty narrow ones give you.
Deciding how far the agent goes looks like a question about model quality. It isn't. It is a question about what breaks when it gets things wrong.
The model is doing exactly what it was built to do - treat the text in front of it as instruction. Where that text came from is invisible to it.
The choice usually gets argued along a "which one is faster" axis. The right axis is the concurrency profile.
The most expensive failure in an agent chain isn't producing a wrong output. It's a wrong output being taken for a right one and passed along.
No articles published yet.