What the Human Was Actually Doing

Forbes reports MIT Sloan’s Paul Cheek 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. Approving the output is the visible part of that. Everything else is maintaining context, catching drift, interpreting failure, and choosing what happens 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, provenance, and dependencies. Recall operates on an index. Code construction uses program structure, repositories, compilers, 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 genuinely 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. The customer provides the mission, Tapestry executes it without supervision, and evidence guides the work. For the first persona, the Python Developer, requirements and requests go in and pull requests come back for review.

Five core elements carry that as one system. The Knowledge Engine grounds the claims, evidence, and proofs the work depends on, and stays authoritative for what is currently known. The Actor performs the work, produces evidence, and submits proposed releases. The Motivator organizes eligible work over durable task records, maintains scheduling invariants, and dispatches what has been approved. Engram proposes a previously accepted conclusion when one applies, and that proposal remains subject to current Knowledge Engine evidence. The Regulator judges what may enter the system and what may leave it. None of them is Tapestry on its own, and the behavior the customer sees belongs to the whole.

Spyder is the code-building component deployed with the Python Developer instance. The Motivator drives Spyder from work the Actor populated, and the Actor is the backstop for the CPU-bound generation path. What Spyder builds is compiled and tested in isolation, so what returns is evidence about the artifact rather than confidence about the code.

The practical consequence is that a later Actor invocation starts from durable system state instead of reconstructing the project from an expanding conversational history. An early misreading is a recorded task with recorded evidence against it, not a premise silently carried through the next six hours of work.

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 authority, the policy, and the priorities, 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 authorized work continues.

When Tapestry reaches something it cannot settle inside its authority or its available information, it raises a decision-ready exception: the bounded question, the evidence behind it, and what it needs in order to proceed. An exception hands back a decision rather than the work.

Supervision is a standing obligation. An exception is a single question with an answer.

What each design makes expensive

That last pair of rows is the commercial argument. An architecture that routes every cognitive operation through a model scales its inference bill with its workload and its supervision bill alongside it. Distributing the work means added autonomous capacity does not demand a proportional increase in either, which is what makes running ten of these different from running one.

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. Autonomous work asks a different question, because something still has to maintain understanding, order the work, implement it, test it, retain the state, and decide what is ready next.

Cheek asks whether it is time to take humans out of the AI loop. The more useful version is what happens to their work once they go. Some of it wants a model. Most of it wants a schedule, an index, a compiler, and a test run.

If you are evaluating an autonomous system this year, ask what runs on a GPU and what 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.