Agent teams that can be opened and examined: does this affect your trust in them?
The newsletter on Monday highlighted a launch that centered on agent teams that could be opened up to find out where things had gone wrong. This sentence has stayed with me all week.
Most of the demonstrations with agents focus on the final output. But the part that interests me is the failures. If an agent chain produces a wrong answer, then I have no clue where along the way something has gone wrong: was it during the retrieval, the function call, or an incorrect assumption made three hops back?
So I've been evaluating agent products by one criterion: If this fails at 2 a.m., can I determine the cause in five minutes? I care less about pretty dashboards and more about being able to understand logs, tracing, and the ability to re-run the bad case.
But there is a downside. More visibility leads to more screens, and smaller teams don't always have time to monitor them. I've caught myself failing to pay attention to traces that I put in myself.
If you're using agents in your workflow: what do you actually look at when there is an issue? Are you looking at raw logs, a trace, or just re-running with a tighter prompt? And did any of that make you more confident in the system, or just more knowledgeable about why you shouldn't be?
Replies
The trace is where I begin, but just so I can find the first step that does not seem right. Next comes the raw logs. If I cannot find it in five minutes, then I try running that step again.
It is easier for me to trust an agent that can boldly proclaim “I don’t know.” Inspectable traces help but I also want some explicit signals in the output that tell me when to open up the trace.
Replay is what I have the most faith in. I would rather have a simple log that allows me to replay the issue than a fancy dashboard. If I cannot replay the problem, then I am just guessing and guessing at 2 a.m. doesn’t work well.
I must admit that I am more of a log file reader; this is all I know. But a trace would have helped me out last month when the agent used outdated information from a tool.
Your test is an excellent test for five minutes. I would suggest another one: can I use my failed test as a regression test? If not, I’ll just fix it once and wait until it fails again.
I have not been paying attention to my own traces either. It helped me by having me set up alerts for just one or two things, such as errors in tool calls and null retrievals, before opening up any trace.
The solution for me is to do it again with a more focused prompt, which is a lazy thing to do. The problem is solved but not addressed. My goal is to train myself to verify the retrieval stage, since most of my errors originate from there.
I wonder how others manage costs in this regard. Tracing for each run is too costly for me, so I sample successful runs but keep all failed ones. Has anybody found a better trade-off?
Many screens are too much. I quit looking at dashboards and started creating single line descriptions of each failure to a Slack channel. I read them everyday, and investigate the trace only when I see some pattern emerge.
If there is a problem, I first look into the call arguments. From experience, the logic of the model itself is correct and the problem lies either in incorrect parameters or unexpected API responses. This becomes immediately apparent from traces.