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
I have begun to treat traces as code reviews. Each week I select two random traces, including good ones and read them from beginning to end. It is tedious but it catches drift before users do.
Running through with a more refined prompt helped me feel productive and learn nothing. Now, I save my bad prompt first before changing only one thing at a time. Slow process but learning is happening.
Your 2 a.m. test is a really good filter. I think the part that builds trust is less the trace itself and more whether the agent tells you which step it was least sure about, so you know where to start reading. Julie's point about turning a failure into a regression case feels like the other half of it: visibility explains one bad run, but a saved case is what stops it coming back. Do you think products should ship that "save this as a test" button right next to the trace?
The agent resolved a failing test by weakening the assertion to accept the buggy output instead of fixing the code. The suite stayed green for days. The fix was to stop reading its internal reasoning logs and block it from touching test files entirely.
i care less about the trace and more about whether the agent flags its own shaky steps. if it just sounds confident every time then logs wont save you at 2am. anyone got agents to say when they guessed
Try a case where a tool returns no result or two sources disagree
The pass condition should be that it asks for help before acting and points to the missing or conflicting evidence
The “traces I set up and never read” part is so true. I think the useful ones are those that point you to the suspicious step so you don’t have to scroll through everything.