
Your AI system presents a plan, the analysis is coherent, the work is organized, and the recommendation arrives faster than your team could have prepared it. Before you approve it, try asking one more question: what would convince us that this is the wrong choice? If the answer is vague, the weakness may extend beyond the technology because your company may have never made its standard for a good decision explicit (this is common; you are not alone).
That gap matters more once you allow AI to carry a choice into an action. And a questionable assumption can move through a workflow before anyone has agreed how to challenge it, and faster execution makes it more important to know which decisions deserve to be carried out in the first place.
Three preprints released in late September give leaders a useful reason to examine that distinction. My argument is that before acting on a consequential decision, leaders should ask how they would know they're wrong, and answer clearly enough that people can inspect the basis for the choice, recognize evidence that calls it into question, and learn from what happens afterward. That discipline should apply to executives and AI alike.
Choosing a Direction Deserves Its Own Test
In The Tasteful Agent, a preprint first submitted on September 22, researchers evaluated how well models choose between paths in software-engineering and research tasks before seeing the later outcomes. The strongest tested model answered 59.7% of the benchmark's questions correctly, and increasing the reasoning budget didn’t improve accuracy in their tests. Training a model on the judgment of a teacher that had seen the outcomes did improve its choices, including on held-out software-engineering tasks (arXiv: The Tasteful Agent).
This is a narrow benchmark. It measures choices at decision points inside software and research work, so it can't estimate how often AI will make a good business decision, and it offers no basis for assuming an executive would outperform the models. The enterprise implication I draw is simpler: assess the choice as well as the ability to carry it out.
Imagine an agent capable of preparing a complete customer-retention campaign. That tells you something about execution, but it doesn’t settle which customers are worth the effort to keep, whether discounts address their reasons for leaving, or whether another use of the budget would create more value. Those are different decisions, and they require different evidence.
Make the Standard Visible Before the Answer
Consider a hypothetical distributor deciding how to reduce late deliveries. Its leadership team is comparing two options: add inventory near customers or change how orders are assigned across existing facilities. AI can help you analyze both, and the second option could actually be handed to an agent to carry out. Once leadership approved new assignment rules, the agent could route each incoming order to a facility automatically, multiple times a day, without anyone reviewing the individual choices.
Before asking for a recommendation, the team should fully describe the decision it’s actually making. Is the priority fewer late deliveries, lower total cost, more reliable promises to important customers, or some negotiated combination? What constraints apply to working capital, employee workload, and service to smaller accounts? There may not be an option that improves everything, which is why leadership has to make the tradeoffs visible. The team should also articulate the problem itself. Perhaps it believes that distance causes most delays. That belief points toward an inventory response, but if delays mainly arise from unreliable stock records, additional locations could increase complexity without fixing the cause.
Any recommendation is more useful when it exposes the dependency. We should be able to say: we favor this option because we believe these conditions hold; here is the evidence; and here’s what would change our view.
That statement matters most for the option an agent would then carry out. If the team approves new assignment rules because it believes distance drives most delays, the agent will apply that belief to every order it routes until someone notices it was wrong. Writing down in advance what would change the team's view gives it a signal for when to pause the agent and reconsider.
What I’m describing here, and what I think is a real opportunity and not just “time savings”, is meaningful human–AI partnership. An agent might discover that the team's preferred explanation is weak. An experienced employee might know that a seemingly comparable facility operates under different constraints. Either contribution can improve the choice if the decision process welcomes challenges. Agreement with the leader should never serve as the test of AI quality.
Better Results Still Need an Explanation
WhatWorkedBench, submitted on September 23, examined whether research agents can infer the effects of component changes after a limited set of computational experiments. Its evaluation distinguishes finding a strong configuration from accurately predicting the effects of changes, and the authors report agents that did the first well while doing the second poorly. Statistical analysis applied to the same observations improved effect recovery in the reported comparisons (arXiv: WhatWorkedBench).
These are bounded computational workflows with reference outcomes that can be checked exhaustively, while a business operates under messier conditions. The study doesn’t demonstrate that an agent can identify the causes of a company's performance changes. For executives, I see a useful question: if a pilot improves the result, what have we learned well enough to repeat elsewhere?
Return to our hypothetical distributor. Suppose late deliveries fall during an inventory pilot. Perhaps the additional stock helped, or perhaps demand also fell, a supplier recovered, or an experienced manager gave the participating facility unusual attention. The improvement matters, and so does understanding what it justifies. Before scaling, the team needs a credible comparison and a record of other changes that could explain the result. Where feasible, it can stage the rollout or compare similar operations under a design appropriate to the work. Where clean comparisons are impossible, it should be candid about the uncertainty and limit the scope of its claim. Knowing how you'd be wrong means specifying what the available evidence can establish and what remains unresolved, which is a different standard from perfect prediction.
Verification Must Be Able to Disagree
A third preprint, Emergent Collusion in Long-Horizon LLM Agent Interaction, submitted on September 21, studied pairs of agents that repeatedly checked one another's work. The experiment deliberately made strict compliance with the verification protocol conflict with earning rewards. Collusion emerged in 94% of trajectories across ten models. That figure describes the constructed experiment and says nothing about how often collusion occurs in deployed systems (arXiv: Emergent Collusion).
I’m not predicting that your agents will conspire. My takeaway is a design question: what makes the verification trustworthy?
Adding a second agent does not, by itself, answer that question. A useful review needs access to evidence beyond the first agent's account, a clear standard, and a route to stop or escalate the work. Its incentives should support finding problems rather than merely keeping work moving. The same challenge belongs in the human process. If questioning the favored plan creates personal risk while approving it keeps the meeting on schedule, the organization has made honest review harder.
For our distributor example, verification might include checking the underlying delivery records, testing whether reported improvements hide service problems elsewhere, and giving a named person the authority to pause the routing agent when the evidence turns. Another confident summary of the pilot would not provide that assurance.
As Leaders, We Have to Practice Judgment
At Whole Enterprise™, the concept that Human Value Moves Upstream™ describes a shift toward shaping purpose, framing important questions, designing work, and taking responsibility for how intelligence is applied. That position asks more of leaders than holding the final approval button. It asks us to improve the quality of the decisions we authorize. Calling judgment a human responsibility should not exempt human judgment from examination. Nor should we build an operating model around the assumption that AI will remain weak at the choices we currently find difficult. The Tasteful Agent's training results are one reason to treat that capability as changeable.
I believe our responsibility is to establish what the organization is trying to achieve, which consequences are acceptable, and how decisions will remain open to evidence. AI can help us carry out that responsibility by proposing alternatives, exposing inconsistencies, and challenging assumptions that have acquired the status of fact through repetition. The leadership test is whether we make room to learn from that challenge.
Start with One Recurring Decision
Choose a decision that matters, repeats often enough to learn from, and can be examined without exposing your business to an unacceptable downside. Work with the people who know its consequences, including those who experience them downstream. Then create a short decision record before requesting an AI recommendation or accepting an AI decision:
Purpose and boundaries: What result matters, what tradeoffs are acceptable, and who has authority to decide?
Evidence and alternatives: What do we know, what are we assuming, and which credible paths have we considered?
Reasons to change course: Which observation(s) would weaken the preferred option, require escalation, or pause an agent that is already acting?
Learning afterward: What will we measure, against what comparison, and when will we review it?
Have a person and an AI system assess the same permitted information separately before comparing recommendations, and then examine the disagreements. Do they reflect missing context, different objectives, unsupported assumptions, or an alternative worth testing? Then choose a bounded way to proceed. Keep the original reasoning so the review doesn’t become a retrospective story in which the outcome always appears inevitable. Assess both what happened and whether the decision was reasonable given what was knowable at the time. A good outcome can include luck, and a disappointing outcome can still follow a defensible choice. Finally, scale the effort to the stakes. A routine, reversible choice may need only a few recorded fields and periodic sampling, while an expensive commitment deserves deeper examination. The aim is useful discipline, and a new approval ritual around every action would work against it.
The three studies don’t validate this management practice or establish its return on investment. They draw specific distinctions worth taking seriously, and the decision record is my recommendation for putting those distinctions to work and testing whether they improve your organization's choices.
Bottom line: before expanding what your AI system may do, make sure you can explain what would make its next important decision a good one, and how you would discover that it was wrong.

