The question I find most useful at work is simple: what problem are we actually trying to solve?
It sounds almost childish. Of course everyone knows the problem. That is why the meeting exists, the project was opened, or the incident was escalated. Then the conversation starts and the problem gets buried under explanations, reputations, old decisions, and arguments about who should have known what.
A customer is waiting, but the room is discussing ownership. A number is wrong, but everyone is explaining where their part of the process ended. A launch is late, but the conversation is already turning into a trial about which team created the delay. The work stops being about the work.
This is the part of working with AI that I genuinely enjoy. If an agent gives me the wrong answer, I do not have to protect its feelings before I inspect the failure. I can ask what it was told, what evidence it used, which action it took, and where it should have stopped. The answer may still be bad. At least the investigation can stay attached to the system that produced it.
That does not mean AI removes blame or politics by itself. A badly designed agent can hide responsibility just as easily as a badly designed organization. “The AI did it” can become the newest version of “that came from another department.” If nobody can explain the objective, the evidence, the permission, or the approval, automation has only made the accountability gap faster.
This is why traceability matters more to me than the performance of the model in a demo. The National Institute of Standards and Technology recommends defining and documenting human oversight, monitoring AI systems after deployment, and recording cases where humans override an AI decision. Those practices are not paperwork around the real system. They are part of the system.
Stay inside the failure
When something goes wrong, I want to be able to reconstruct the path. What outcome was the agent pursuing? What information did it have at the time? What rule or model produced the action? Which check was supposed to catch the mistake? Who had authority to intervene?
Those questions are useful because each answer points to something that can change. If the evidence was missing, fix the evidence. If the instruction was vague, fix the instruction. If the permission was too broad, narrow it. If the review step approved weak work, redesign the review. If a person had authority but no warning, change how the system escalates.
Traceability also protects against a different failure: false neutrality. A log does not make a decision fair just because it is detailed. The objective may still be harmful, the evidence may reflect an old bias, or the human approval may be a rubber stamp. The record gives reviewers something concrete to challenge. It does not replace judgment.
Blame rarely gives me that much. It may identify someone to punish, but it does not necessarily explain why the same failure will not happen again.
I learned this while building the Zero Meeting Labs content workflow. Early versions could produce writing that looked finished and passed a basic style check while still feeling empty. The sentences were clean. The formatting worked. The argument had not moved. Telling the agent to “write better” did nothing useful because the failure was not specific enough.
So the workflow changed. Drafts now have to add new ideas, explain a mechanism, show evidence, describe something that was actually built, give the reader a practical entry point, and create a reason to care about the next experiment. Separate reviewers score the substance and the human voice. The words come to me before the system is allowed to touch the visual layer. A polished article can still fail if it has nothing to say.
That is what staying solution-focused looks like to me. It is not being cheerful or avoiding conflict. It is refusing to let the investigation drift away from the conditions that produced the result.
The review should also be independent from the system that produced the work. An agent grading its own answer can repeat the same bad assumption with more confidence. A separate model, a deterministic rule, or a human reviewer should inspect the highest-risk claim from a different angle.
You can use the same approach on a small workflow. The next time something fails, do not begin with the person. Begin with the intended outcome and the evidence available at the moment of action. Find the permission that allowed the result and the check that should have stopped it. Then decide whether the problem belongs to the instruction, the tool, the review, or the person who held the authority.
People still matter in this model. Judgment still matters. Intent still matters when someone knowingly works around a safeguard. The point is not to excuse every decision as a system problem. The point is to make responsibility follow actual control instead of title, proximity, or whoever is least able to defend themselves in the meeting.
The next experiment is to apply this logic to incident review. An agent should be able to reconstruct the timeline, separate evidence from interpretation, identify the missed stop condition, and route the unresolved decision without inventing a villain.
The most useful question in the room is not “Who did this?” It is “What would have had to be true for the system to stop it?”
Yours in useful questions,
Z