The Broken Rope

This is the ninth article in "The Shape of the Next Decade," a series on how AI reshapes work, institutions, and ordinary life. It follows The Four Floors. The people in this piece are representative scenarios, not reported cases.

At first, the dashboard looked like proof that the rollout had worked.

For three years the vendor-risk team had begged the rest of the company to submit complete packets. Contracts arrived without data-flow diagrams, security questionnaires came back half-filled, and a SOC 2 report could sit in someone's inbox for a week under a filename nobody could find. Then the new system started assembling the packets on its own, pulling the contract, the questionnaire, the audit report, and the list of policy exceptions into one clean file before a human ever opened it.

By Friday the intake queue had tripled, and the team hadn't hired anyone.

The packets were good, more complete than the ones people used to assemble by hand, and they arrived faster than anyone could look at them. The reviewers who used to wait around for a business unit to send over a missing certificate were now staring at a backlog that grew a little more every hour. The risk committee still met on Tuesdays and Thursdays. It still approved vendors at roughly the pace it always had, because someone on that committee still had to sign the approval and answer for it later if the vendor they cleared turned out to be a hole in the network.

Every workflow like this used to have a rope in it, even if nobody called it that. The slow part at the front, the chasing and assembling and reformatting, quietly set the pace for the slow part at the back. Pull the friction out of the front and the rope goes with it. The work doesn't move through the system faster. It just arrives faster, and then it piles up somewhere new.

The rope was an accident

Manufacturing has a name for the constraint that sets the pace of a system. In Eliyahu Goldratt’s Theory of Constraints, the bottleneck is the drum: the part of the process whose rhythm determines how much actually gets done. The rope is the release mechanism that keeps new work from entering the system faster than the drum can absorb it. If the drum can handle ten jobs a day, the rope keeps the rest of the factory from dumping fifty jobs in front of it.

Most office work was never designed around that idea, but it obeyed it anyway, for an accidental reason. The front end of almost every knowledge-work process was slow, and its slowness happened to act like a rope. Design took long enough that the factory could keep up. Analysis took long enough that the certification office was never buried. The permitting packet took a week to assemble, which was roughly how long the board needed between meetings. That pacing was a side effect of thinking being slow, and it worked well enough that we mistook it for how office work naturally moves.

AI removes the side effect. When assembling the packet drops from a week to an afternoon, the front end can now produce far more finished, reviewable work than the downstream process can absorb. Some of those downstream steps can stretch to keep up: you can hire another reviewer, add a committee session, extend the lab's hours. But that elasticity has a ceiling, and it disappears entirely when the front end goes to nearly zero. If the real constraint was always the reviewer, or the committee, or the lab, or the court, then making the paperwork instant doesn't raise output at all. It converts a shortage of paperwork into a surplus of it, and the surplus stacks up in front of whatever was actually setting the pace.

On the dashboard, the broken rope looks like progress. Completed packets climb and generation metrics improve. But the number that matters, how many vendors actually got cleared, or drugs approved, or cases decided, sits about where it was.

The flood

The vendor-risk queue is a small version of a pattern now showing up across institutions. AI is very good at producing plausible, review-ready work. It is weaker at the step that comes after production, which is somebody being willing and able to stand behind it.

Security runs the same play from the other direction. AI is unusually strong at finding software vulnerabilities, because a bug is real if the exploit works and a patch is real if the exploit stops working. Anthropic's Project Glasswing work, described in The Four Floors, had an unreleased model turn up thousands of zero-day vulnerabilities across major systems. But a candidate vulnerability is not a fixed one. Each finding still has to be verified, disclosed to the right maintainer, turned into a patch, tested against everything it might break, and shipped into systems that can't just be taken offline. The model can lengthen the vulnerability queue faster than any team can work through it. The discovery got cheap. The remediation stayed expensive, and now it has a longer line in front of it.

The same pattern appears in law firms, hiring loops, and public agencies. Law firms can draft more contracts than partners can responsibly review. Hiring tools can produce polished candidate summaries faster than a manager can compare them. AI can summarize a public comment record faster than a board can legitimately decide what to do about it. In every case the model didn't make more bad work. It made more work that looks ready, which is a subtler problem, because work that looks ready is exactly the kind that gets waved through when the line gets long.

Two piles that look the same

Go back to the vendor-risk queue. The problem is not just the size of the pile; it is that the pile contains two kinds of delay wearing the same label.

Two packets are stuck. On the dashboard they look identical: same "awaiting review" status, same age, same little red bar creeping toward the deadline.

The first packet is stuck because the submission was a mess. The wrong version of the security addendum, a missing penetration-test result, three documents that contradicted each other about where the data would actually live. This is the kind of delay AI was built to end. The model can reconcile the documents, flag what's missing, and assemble a clean record, and the queue behind it genuinely clears. Pushing more automation here is the right move. The constraint was coordination, and coordination is exactly what AI dissolves.

The second packet is stuck at the risk committee, and it is stuck on purpose. Somebody has to decide whether the company is willing to hand this vendor access to customer data, and to be answerable for that decision when a breach lands in front of a regulator two years later. That slowness is the whole point of the step. The delay is where the accountability lives, and if you speed it up by letting the model wave the vendor through, you haven't made a faster good decision. You've made a faster decision with the accountable part removed. Push automation into that step and you don't relieve the constraint, you erode the accountability the constraint exists to produce.

The dashboard shows the same backlog for both. Work-in-progress is piling up in front of a bottleneck, and the tool that measures the pile cannot tell you which kind of bottleneck it is. A queue in front of a coordination floor and a queue in front of an accountability floor look numerically identical. Telling them apart is a judgment, and it's the judgment the dashboard can't make.

As AI makes coordination cheap to fix, the cost of misreading which floor you're on goes up. The remaining constraint is usually something that does not yield to more speed, and some of those constraints get worse when you apply it. The person who can tell a coordination bottleneck from an accountability floor is worth more than they used to be, not less.

Putting the rope back on purpose

If AI broke the accidental rope, the discipline of the next few years will be learning to tie it back together deliberately.

The idea is not to slow the model down for its own sake. It's to release finished work into the system at roughly the rate the binding step can actually absorb, so that what comes through is work the constraint can use, and the rest waits as unstarted potential instead of a pile of aging inventory. A generated contract nobody has reviewed isn't an asset. It's a liability with good formatting, and it decays while it waits.

The reason this is hard has less to do with technology than with how good the broken version feels. A flooded front end produces visible, countable, satisfying progress. Look how many packets we generated. Look how many findings the scanner produced. It feels like the system is working harder than ever, which is precisely why organizations keep pouring effort into the part that was never the problem. Goldratt warned that once a constraint breaks, inertia can become the next constraint. AI makes that failure feel like a win.

There's a rough gauge you can keep in your head, as long as you don't dress it up as a real metric. Watch the rate at which the front end produces finished work against the rate at which the binding step absorbs it. When the first number climbs and the second one doesn't, the rope is breaking in real time, before the backlog becomes a crisis anyone notices. The catch is that this gauge only tells you the rope is breaking. It does not tell you whether the pile is waiting on coordination or accountability, whether the fix is more automation or more restraint. The number is a smoke alarm, not a diagnosis.

Sometimes the rope should break

Plenty of slow steps aren't protecting anything. They're guild turf, rituals nobody remembers the reason for, or approvals whose only real function is to bless work that was already fine. History is not kind to the claim that a task must stay human. Scribes, switchboard operators, and film projectionists were all defended on principle and automated anyway, and in hindsight most of those defenses were protecting a toll booth.

So the test can't be whether a human used to do the work. That protects far too much. The better question is whether the slow step actually validates the work, or just blesses it. If it validates, meaning the result is only trustworthy because that step happened, scale it carefully and treat it as precious. If it merely blesses work that was already valid, automate it or delete it, and don't mourn it.

The vocabulary in this piece will probably spread faster than the judgment behind it. "That's an accountability floor, don't rush it" is a useful sentence. It will also become a convenient defense for processes that deserve to die. Agile went through exactly this: "sprint" and "standup" spread across the corporate world years before real agility did, and a decade of hollow ritual got performed in their name. Constraint language will do the same. People will slap "accountability floor" on a toll booth to protect it, and "just coordination, ship it" on a decision that badly needed a human to answer for it. The words help only when the judgment is real.

The bigger rope

There's a version of this mistake being made at the scale of the whole industry.

The frontier labs are spending hundreds of billions on the belief that the most capable model captures the value the technology creates. In strict Theory-of-Constraints terms, that's a bet on relieving a constraint that, for most real deployments, stopped being the binding one a while ago. As the economist Luis Garicano argues in an analysis of AI value capture, intelligence is rarely what stops an organization from doing what it wants to do. The scarce inputs are workflow redesign, organizational authority, proprietary data, and the political capital to overcome resistance. Next to those constraints, the difference between a six-month-old model and today’s frontier looks small. The evidence points the same way: enterprise AI spend has exploded, but production agent deployments still lag the demos and pilots. The capability is sitting there underused, waiting on the constraint nobody can buy their way past.

The labs are also building platforms, distribution, developer ecosystems, and the switching costs that come with them, and some of that is durable. But the durable money keeps flowing to whoever owns a floor that can't be automated away: the power and cooling and silicon at the bottom of the stack, the proprietary data and switching costs at the top. The model layer in the middle is the one that commoditizes fastest, which is why the firms with the strongest positions tend to own the layers that don't. The industry-scale version of the broken rope is pouring resources into the layer that is easiest to accelerate while the value pools around constraints somewhere else.

Faster up to what

The last piece in this series asked, faster up to what? AI can compress the work leading up to a decision, but eventually it hits a floor. The important question is which one.

The broken rope is what happens before the floor becomes obvious. When the work in front of that floor becomes nearly free to produce, the queue stops being clerical backlog and starts becoming evidence. A growing pile tells you the system is waiting on something AI has not actually accelerated. The job is figuring out what that something is.

The model did not fail the vendor-risk team. It did exactly what it was asked to do.

Once the rope breaks, the work does not disappear. It arrives at the decision point faster than the decision can absorb it.