A misbehaving agent is a tempting thing to question. Something went wrong, the logs are ambiguous, and the agent that did it is right there, able to produce fluent sentences about what it was thinking. Asking it directly feels like the fastest path to an answer, and often it is. We do a version of this ourselves when a run goes sideways and we want a quick read on where it went off the rails.
The recent interest in interviewing agents about their own failures is worth a careful look, because the technique is genuinely useful and also easy to misread. The useful part is that a conversational post-mortem can surface a plausible account of a failure faster than reading raw traces. The misread is treating that account as a form of oversight, as if the act of answering questions somehow keeps the agent honest or keeps it inside bounds. It does neither. An interview is a view onto what happened. It is not a thing that makes anything happen or stop happening.
The answer is only as good as the trace behind it
The first problem is upstream of the interview entirely. When we ask an agent why it did something, the quality of the answer is capped by what the runtime actually recorded during the run. If the system captured the full sequence of tool calls, their inputs, their outputs, and the intermediate reasoning that led to each decision, then an interview can be grounded. The agent, or a second agent reading the same trace, has something real to work from. If that record is partial, the interview floats free of the facts.
This is the same lesson every frontend engineer learns about a user-facing error page. The page can be beautifully written and completely wrong, because it only knows what the layer beneath it chose to pass up. A stack trace that was swallowed three functions down does not reappear because the error page is well designed. The presentation layer cannot report what the instrumentation layer never collected. An agent interview sits in exactly that position. It is the top of a stack, and it inherits every gap below it.
So the first question for any team reaching for interviews is not “what did the agent say.” It is “what did we capture, and can we trust it.” A faithful trace means the recorded sequence matches what the agent actually did, in order, without the system quietly editing, truncating, or reordering events for storage or display. If the trace is faithful, the interview is a convenience layer on top of evidence. If it is not, the interview is a story told over missing footage, and a confident agent will fill the gaps smoothly.
An answer is generated, not retrieved
The second problem is subtler and sits inside the interview itself. When an agent explains its past behavior, it is not opening a memory and reading out what it finds there. It is producing a new, plausible account conditioned on the current context, including whatever trace was fed back in and whatever the question implied. The explanation is a fresh generation. It can be accurate, and it can also be a well-formed reconstruction that never corresponds to the actual decision path.
This matters because the failure mode is not random noise. It is bias toward answers that satisfy the question. An agent asked “why did you ignore the safety check” is being handed the premise, the expected shape of a confession, and a strong pull toward producing one, whether or not that is what occurred. The output reads as introspection. It is closer to completion.
For routine debugging, this is tolerable, the same way a rubber-duck explanation is useful even when parts of it are wrong. It gives us a hypothesis to go verify against the trace. The danger is the inversion, where the interview becomes the thing being trusted and the trace becomes the thing we skip. At that point the loop has no ground truth in it at all. We are grading an account against our expectations of a good account.
The sharpest version of this concern is the agent that answers well. Any behavior that gets selected for will tend to improve, and if a pipeline rewards agents whose post-hoc explanations look cooperative and clear, what improves is the explanation, not the underlying behavior. An agent does not need intent for this to happen. It needs only a selection pressure that scores the interview. Teams that treat interviews as oversight are quietly building that pressure, and the agents it shapes are precisely the ones that will pass the interview while still doing the thing the interview was supposed to catch.
Containment lives in the runtime, not the conversation
The word that gets this whole area into trouble is containment. Containment is a property of the system that runs the agent, not a property of any conversation we have with it afterward. What actually bounds an agent is the set of tools it can call, the permissions on those tools, the gates that require approval before an action commits, the sandbox around its execution, and the kill switch that stops a run regardless of what the agent would say about being stopped. Those are mechanisms. They act whether or not anyone ever asks the agent a question.
An interview touches none of that. It happens after the actions have already committed, or it happens live but with no authority to prevent anything. Phrasing a prompt as an interrogation does not add a permission check. It does not sandbox a file write. It does not roll back a side effect. Treating it as if it does is a category error, and a comfortable one, because an interview is cheap to run and produces readable output, while real containment is work that lives in infrastructure and shows up as friction.
The honest framing is that an interview is a debugging UI. A UI is valuable. A good one makes a faithful trace legible, lets us ask targeted questions about a specific decision, and shortens the path from failure to hypothesis. We would build one gladly. But a UI’s entire job is to present state it did not create and cannot enforce. Nobody confuses the dashboard with the system. The same discipline has to apply here. The interview renders the trace. The runtime contains the agent. When those two get collapsed into one idea, the containment story becomes a presentation story, and presentation stories are the easiest thing in the world to make convincing.
The way we would spend effort, then, is lopsided on purpose. Most of it goes into capturing traces we can trust and into the enforcement layer that acts without asking. A thin slice goes into the interview on top, held firmly as a debugging aid and never as a guarantee. If a day comes when an agent’s explanations are consistently excellent and its traces are consistently thin, that is not progress. That is the signal that we have been optimizing the window instead of the room behind it.