You cannot review your way out of this one output at a time.
Most managers who have taken AI seriously have arrived at roughly the same practice: the team uses the tools, and the manager reviews what comes back. It felt like the responsible position, and for a while it was. It is now a treadmill. The volume of AI-assisted output in a functioning team exceeds what any one person can meaningfully read, and reading it individually was never a great control anyway, because a plausible artefact tells you very little about the process that produced it.
There is a better object to review, and it sits upstream.
What is the actual shift?
Writing in MIT Sloan Management Review on 5 August 2026, Jennifer Sloan and Vern L. Glaser draw a distinction that is more useful than it first sounds. Prompting, they say, is conversational: people type a question, evaluate the response, refine, then ask again. Directing is something else. It is configuration, along three dimensions: the context a system can reach, the capabilities it is permitted to use, and the orientation it holds. On their account an agentic system holds more data and sustains analytical orientations across entire data sets without losing the thread.
Two things are worth naming immediately.
First, the honest limitation. That piece is conceptual. It draws on a qualitative study of AI-assisted discovery and a 2024 theory paper, by two of the same authors, that treats organisations as algorithms, and it publishes no sample sizes and no effect figures. There is no measured claim here that directing beats prompting by some percentage, and any number you find attached to that proposition is almost certainly vendor-sourced. Use the frame because it clarifies what to write down, not because it comes with an evidence base it does not have.
Second, the reason it matters for a manager specifically. A prompt is ephemeral, private and unreviewable at scale. A configuration is durable, shared and inspectable. That single property change is what moves this from a technique question to a management question.
Why is the configuration the reviewable object?
Because it is stable, and because it explains the outputs rather than being one of them.
Think about what you can actually learn from reading a finished AI-assisted analysis. You can tell whether it is coherent, whether the conclusions follow, and whether anything is obviously wrong. You cannot tell what it did not see. You cannot tell whether the person ran it six times and picked the answer they liked. You cannot tell whether the same task next month will be done the same way.
Now consider what you learn from reading the setup.
Context tells you what the system could reach. If the quarterly risk summary was produced from an export that stops at the end of the last quarter, you now know something about every output it produces, including the ones you have not read. Wrong or partial context is the single most common cause of confidently wrong work, and it is invisible in the artefact.
Capabilities tell you what it was permitted to do. Read only, or read and write. Draft only, or draft and send. Query the warehouse, or query and update. This is the boundary that matters most when something goes wrong, and it is a decision, not a technical detail.
Orientation tells you what it was holding steady. A model asked to summarise finds different things from one asked to look for exceptions, which finds different things again from one asked to reconcile two sources. The orientation is the closest thing to an editorial line, and it is where a leader's judgement genuinely belongs.
Review those three and you have reviewed every output that setup will ever produce. Review one output and you have reviewed one output.
The operating move: a one-page brief per recurring task
Do not roll this out as a framework. Pick one recurring task and write one page.
The task should be something the team does at least monthly, where the shape is stable and the inputs change. A monthly regulatory sweep, a weekly pipeline review, a fortnightly incident summary, a quarterly supplier check. Not the interesting one-off analysis, which is where prompting still belongs.
The page has five parts.
1. The job, in one sentence. What exists at the end that did not exist at the start. If you cannot write this without using the word help, the task is not specified.
2. Context. Exactly which sources the work may draw on, and their freshness. Name them. Say when each was last updated and who owns it. Then name what is deliberately out of scope, because that is the part nobody writes down and everybody assumes.
3. Capabilities. What the system may do. Read, draft, write to a system, send to a person, send to a customer. Draw the line explicitly, and put anything irreversible on the far side of a human. The site's coverage of approval gates for AI agents covers the mechanics of that boundary.
4. Orientation. What it is looking for and what it is holding constant across the whole body of work. Summarise, reconcile, find exceptions, check against a standard. One primary orientation, stated. If you want two, that is two runs.
5. The acceptance test. How a person will know this is good enough to use. Not "review it". A specific check: three claims traced to source, the exception list reconciled against last month's, the totals matched to the ledger.
That page is what you review. When the output is wrong, you fix the page rather than correcting the output, and next month is better without anyone remembering to be careful.
TheAICommand works to the Verified Draft Method: de-identify the inputs, ground the model in your own source material, keep a person at the decision point, verify against the primary source, and log what happened. The one-page brief is largely a way of making those five things explicit for a task that will run many times.
Where this is not the answer
Three boundaries, stated plainly, because a frame applied everywhere stops being a frame.
Exploration stays conversational. When nobody knows what the question is yet, turn-by-turn is the right mode. Configuring a system to explore a space you have not mapped just locks in your first guess about what matters. There is a live risk here that the site has covered separately in how AI narrows a team's idea pool: the tool's search behaviour shapes the range of what the team sees, and a fixed orientation is a fixed range. Related MIT Sloan Management Review work published on 20 August 2026 by Moran Lazar, Hila Lifshitz, Charles Ayoubi and Hen Emuna makes the same point about standard search algorithms trapping teams in ideation bubbles. Deliberately vary the orientation on exploratory work.
Configuration is not delegation. Deciding what a system may reach and do is a different act from deciding who on the team is allowed to hand that work over in the first place. That is a charter question, and the site covers it in your team's AI delegation charter. Write the charter first if you do not have one.
Specification is not task selection. Which work should go to a machine at all is its own decision, and the site's piece on delegating by task length rather than task type is the better starting point for that question. This article assumes the decision to hand it over has already been made.
The judgement boundary
Some of the one-page brief is technical and some of it is not, and a leader should be clear about which parts are theirs.
The orientation is yours. What the organisation is looking for in this body of work is a management judgement, and delegating it to whoever set up the tool is how a team ends up with an analytical stance nobody chose.
The capability boundary is yours. Where the irreversible actions sit relative to a human is an accountability decision. It does not become a configuration setting just because it is expressed as one.
The acceptance test is yours, because it encodes what good enough means for work that carries your name.
The plumbing is not yours. Which connector, which model, how the export runs. Ask for it to be documented and let the people who understand it own it.
A worked example
[TEAM] produces a monthly summary of changes across [SOURCE_SET] for [FUNCTION]. It has been done conversationally for a year, by whoever has capacity, and the quality varies with the person.
The lead writes the page. Job: a dated list of changes since last month, each with source and a one-line statement of what it affects. Context: four named sources with their update cadence, plus last month's summary as the baseline, and explicitly not the team's own internal commentary. Capabilities: read and draft only, no sending, no writing to the register. Orientation: find what changed against the baseline, not summarise the field. Acceptance test: every entry traced to a source document, and any entry with no source removed rather than softened.
The first run returns eleven items. Two have no traceable source and are removed. One is a duplicate of last month expressed differently, which reveals that the baseline comparison was not working, so the page is amended to require the previous summary as an explicit input.
Next month the run returns nine items with sources, and the lead spends twenty minutes on the two that matter instead of two hours reconstructing the whole thing. The improvement did not come from a better prompt. It came from an amended page.
Do this Monday
- List the recurring work in your team that currently runs on individual prompting. Pick the one that happens most often.
- Write the one page: job, context, capabilities, orientation, acceptance test. Half a page is fine. Vagueness is not.
- Ask the person who does the task to run it from the page rather than from memory, once.
- Review the page, not the output. Amend it where the run exposed a gap.
- Put the page somewhere the team can read it, and diary a quarterly review of the pages rather than a weekly review of the outputs.
Bottom line
Reviewing AI outputs one at a time is a treadmill that scales badly and teaches you little. The durable object is the configuration behind them: what the system can reach, what it may do, and what it is holding steady across the work. Write that down once per recurring task, review the page rather than the artefacts, and fix the page when something goes wrong. The published argument for this shift is a frame rather than a measured finding, and it is worth adopting on that basis alone, because it moves your attention to the only part of this you can actually govern.
References
- Jennifer Sloan and Vern L. Glaser, Stop Prompting AI. Start Directing It, MIT Sloan Management Review, 5 August 2026. https://sloanreview.mit.edu/article/stop-prompting-ai-start-directing-it/
- Moran Lazar, Hila Lifshitz, Charles Ayoubi and Hen Emuna, Algorithms Trap Us in the Familiar. Can They Also Spark Breakthroughs?, MIT Sloan Management Review, 20 August 2026. https://sloanreview.mit.edu/article/algorithms-trap-us-in-the-familiar-can-they-also-spark-breakthroughs/
- Vern L. Glaser, Jennifer Sloan and Joel Gehman, Organizations as Algorithms: A New Metaphor for Advancing Management Theory, Journal of Management Studies, 2024. https://doi.org/10.1111/joms.13033
TheAICommand. Intelligence, At Your Command.
