The fastest way to improve an agentic feature is to make its reasoning easy to copy: one blob, grabbed from the UI, in a form you can paste straight back into Claude and ask why it went wrong.
We added debug output like that to our automatic work and the loop tightened immediately. Something produces a bad result, you grab the blob, hand it back to the model that produced it, and ask what it read and what it decided. It usually tells you, and it often suggests what to change about the prompt or the inputs.
Design it for a model
Logs are for you. A debug blob is for a model. That leads to different choices.
It should be self-contained, so the model isn't guessing at context it can't see. It should include what the agent read, not just what it did, because most bad outputs come from bad inputs rather than bad reasoning. And it should be one copy action, because anything needing assembly won't get used when you're annoyed and in a hurry.
The version we shipped for our test-ideas runs shows what the run read and the moves it made. You need both halves. A decision on its own tells you nothing about why it was made.
The second-order effect
Once the blob exists it stops being only a debugging tool.
It becomes the thing you paste into a conversation about accuracy. It becomes the attachment on a bug report. It becomes the input to "is this prompt actually working," which is otherwise close to unanswerable.
We also made agent runs private by default, with a button to share one with the org. Debug output is most useful when people generate a lot of it, and that only happens when a messy exploratory run isn't automatically visible to everyone.
The rule
If you ship an agentic feature, ship the blob with it. Not after the first support escalation. With it.
The cost is an afternoon. The alternative is diagnosing a probabilistic system by staring at its output and guessing.
Written by
Chris Fong
CTO & Co-founder