Article
What the Human Was Actually Doing
Taking a person out of the AI loop moves their work into the system, and most of that work does not need a model.
Forbes reports that MIT Sloan’s Paul Cheek is making the case that it may be time to take humans out of some AI loops, on the grounds that mandatory human review preserves the bottleneck the technology was supposed to remove. The argument is worth taking seriously. A person who checks every intermediate decision, implementation step, and test run becomes the limit on how fast anything moves, and that limit tightens as systems get faster, cheaper, and more concurrent.
Removing the person is harder than it looks, because approval was never the whole job.
Watch what a reviewer actually does across a long AI-assisted task. They hold the original requirement steady while the model works on something three steps removed from it. They notice when an early assumption has quietly become a premise. They recognize a plausible result that does not answer the question that was asked. They read a failed test, decide whether it matters, and decide what to try next.
Take the person out and none of that work disappears. It moves into the system.
Approval was the visible part of the job. Context, drift, failure, and sequence were the rest.
Most of it is not inference
The reflex is to hand all of it to the model: a longer context, more tokens, more turns, and one agent holding the requirement, planning the work, writing the code, judging the result, and deciding what comes next. That produces output. It is also the most expensive available way to do most of it, and the least predictable.
Consider what the reviewer’s work is made of. Holding a requirement steady across weeks is a storage problem. Knowing which task is eligible to run is a dependency problem. Deciding whether code works is an execution problem, answered by building it and running the tests. Finding whether a question has already been settled is a lookup. None of these become more correct when a language model performs them. All of them become slower, costlier, and harder to audit, because a probabilistic process has been substituted for a deterministic one that was already exact.
So Tapestry runs them as what they are. Scheduling operates on recorded priorities and dependencies. Recall operates on an index. Code construction uses program structure, repositories, interpreters, static analysis, and tests. Grounded knowledge is maintained through graph operations, retrieval, and proof checking rather than held in a context window. Inference is reserved for the work that benefits from it: reading an ambiguous requirement, choosing an approach to an unfamiliar problem, and writing the parts that call for judgment.
A language model is one class of computation in the system, used where inference earns its cost.
What the system carries
Tapestry is a remote worker. For the first persona, the Python Developer, requirements and requests go in and pull requests come back for review. Five core elements carry that work as one system: the Knowledge Engine, the Actor, the Motivator, Engram, and the Regulator. Code is built and tested in isolation, so what returns is evidence about the artifact rather than confidence about the code.
An early misreading surfaces as a failed task with the evidence against it on record, and it is fixed there instead of being carried silently into the work that follows. Each later model invocation picks up from the recorded state of the work rather than reconstructing the project from an expanding conversation.
Where the human still belongs
Leaving the execution loop is not the same as leaving. Tapestry is human on the loop. The customer sets the mission, the policy, the priorities, and what Tapestry may reach, changes them when the work should change, and answers the questions that need their judgment. What they give up is the obligation to be present while ordinary work continues.
When Tapestry meets a question it cannot settle with the systems it may reach and the evidence it has, it raises a decision-ready exception: the bounded question, the evidence behind it, and what it needs in order to proceed. Other permitted work continues while the question is open. An exception hands back a decision rather than the work.
Supervision is a standing obligation. An exception is a single question with an answer.
Where each design puts the work
| Customer question | Model-centric agent | Tapestry |
|---|---|---|
| What does it take to start? | A prompt | A mission and an engagement |
| What carries the work? | One model-driven agent | Five core elements as one system |
| Where is project state kept? | Model context and accumulated agent state | Recorded outside the model |
| What selects the next task? | The model decides what to do next | Recorded readiness, dependencies, and evidence |
| How is software judged? | Model review, sometimes with external tools | The built artifact is executed and tested, then reviewed before release |
| What grows with the workload? | Inference on every step, and the supervision to watch it | Inference on the steps that need judgment, and review of delivered pull requests |
| What does the customer provide, and receive? | Continuous interaction, and agent output | Requirements and requests, and pull requests for review |
A design that routes every step through a model grows its inference bill with the workload and its supervision bill alongside it. Tapestry sends only the steps that need judgment through a model, and the customer’s attention goes to review at delivery. More work means more pull requests to review, and nobody has to watch the work in between.
Beyond the loop
Human review has been a good operating model for generative AI, and it remains the right one for a tool a person drives directly. Cheek argues that it may be time to take humans out of some AI loops. The more useful question is what happens to their work once they go. Some of it wants a model. Most of it wants a schedule, an index, and a test run.
Before you adopt a system that works without supervision, ask which of its work runs through a model and which does not. The answer tells you what it will cost you at ten times the volume, and whether anyone will still be able to check its work.