What DevOps taught me twice about bottlenecks, work in progress, and engineering the human gatekeeper out of the routine path.

I thought I had already lived The Phoenix Project.

Gene Kim, Kevin Behr, and George Spafford wrote the novel around a familiar operational failure: too much work, too little visibility, fragile dependencies, and an organization that keeps routing critical flow through the same indispensable person.

I recognized that world from traditional IT.

At Amrock, I worked across application delivery and IT operations while our deployment system moved from monthly releases to more than three deployments a day. We automated build-and-release pipelines, introduced testing gates, improved change control, and reduced the percentage of changes that failed from 26% to 14.7%.

The improvement did not come from asking smart people to work faster. It came from redesigning the system around them.

This year, while building LifeOS—a governed multi-agent operating system—I discovered that AI agents recreate the same failure modes with remarkable efficiency. They just give them new names.

The central lesson is not that agents make DevOps obsolete. It is almost the opposite:

When generation becomes cheap, flow discipline matters more.

Brent is now the human in the loop

In The Phoenix Project, Brent is the person every important path eventually reaches. He has the context. He can fix the hard problems. Work waits for him because the organization has made his attention part of the infrastructure.

That pattern reappeared while I was building an agent system for myself.

At first, every agent workflow came back through me. I supplied missing context. I approved routine transitions. I noticed when an artifact did not match the original request. I decided whether a review was real. I restored the process when something failed.

I had built a team of fast agents—and quietly made myself their Brent.

That is not meaningful orchestration. It is a person acting as an integration layer.

The fix was not to remove human judgment. It was to stop using human attention for controls the pipeline could enforce.

LifeOS now binds reviews to an immutable commit and the original brief. Review results are signed and checked against the exact work they evaluated. A blocking finding requires a new commit and a new review; an old approval cannot drift forward. Fail-closed validators reject missing or mismatched evidence. Low-risk Green work has a governed path toward exact-head auto-merge only after the required controls agree.

I still own consequential decisions. I no longer need to carry every routine safety check in working memory.

That is the First Way rebuilt for agents: protect the flow of work by moving repeatable safety into the system instead of leaving it inside one person's attention.

Agent output is work-in-progress inventory

AI systems make output look like throughput.

A model can draft ten documents, open several implementation paths, propose visual concepts, and produce code faster than a person can inspect any of it. The activity is impressive. The queue it creates is less impressive.

An unreviewed draft is inventory.

An unmerged branch is inventory.

An unapproved content package is inventory.

A change that cannot pass verification is inventory, no matter how quickly it was generated.

This is where many agent systems fool their operators. They measure the speed of generation while ignoring the age and size of the verification queue. They celebrate tokens produced, tasks attempted, or agents running in parallel. But value appears only when the work survives review and reaches its intended destination.

A CI-budget stall made that visible for me this week. The agents could keep generating, but one blocked validation work center held the flow. Work accumulated upstream. Nothing downstream cared how quickly the drafts had been produced.

Throughput without verification creates inventory, not value.

The constraint moves; it does not disappear

Before agents, generation was often the constraint. Someone had to write the first draft, build the first implementation, or assemble the first package.

Agents changed that economics. Generation became abundant.

The constraint moved to:

  • deciding what deserves to exist;
  • restoring enough context for trustworthy work;
  • reviewing claims and implementation;
  • resolving exceptions;
  • approving consequential actions;
  • proving that the finished artifact matches the original intent.

That shift is easy to miss because the new bottleneck is quieter. A blank page is obvious. A growing review queue can hide behind a dashboard full of completed agent tasks.

The Theory of Constraints still gives the right question: where is work waiting now?

If every path waits for one person's approval, context, or recovery decision, adding another agent increases pressure on the constraint. It does not increase throughput.

CEO attention needs WIP limits too

I eventually applied the same logic to my own decision load.

LifeOS uses a three-decision ceiling for normal CEO-facing work. It also separates signals into Red, Yellow, and Green:

  • Red interrupts.
  • Yellow waits for the brief.
  • Green stays quiet.

Those rules are not productivity theater. They are work-in-progress limits on the scarcest part of the system: executive attention.

Without them, ten agents can each behave reasonably and still create an unreasonable system. Every agent may produce one useful question, but the combined queue turns the CEO into the universal approval service.

A governed executive system has to suppress low-consequence work, bundle what can wait, and preserve interruption for what genuinely cannot.

The point is not to make the human disappear. It is to reserve human judgment for the decisions that actually require it.

I found the same lesson in the content studio

The most recent example came from my own publishing workflow.

I kept manually prompting research, editorial selection, writing, art direction, and visual correction. The output improved, but the process depended on me remembering how to reconstruct it every time.

That was another Brent pattern.

So we converted it into a governed loop. Feeny runs the research desk at 7:05. Simon takes the verified evidence at 7:20, makes the editorial decision, develops multiple visual concepts, invokes the dedicated image-generation path, checks the work at full and mobile sizes, and leaves a complete package for review. Nothing publishes automatically.

The important improvement was not “more content.” It was moving source verification, visual variation, execution receipts, and fail-closed checks into a repeatable flow.

Repeated prompting became a system.

Where the DevOps analogy stops

The analogy is useful, but it has limits.

Agents do not fail like servers. A failed service is usually unavailable or visibly degraded. An agent can return a fluent, structurally valid answer that is wrong, overconfident, or based on lost context. The output may travel farther before anyone recognizes the failure.

Human judgment is also not a work center that can always be scaled horizontally. Some decisions remain bound to accountability, reputation, family, money, credentials, production access, or the intent only one person can supply. Adding reviewers does not automatically make those decisions transferable.

That means the goal cannot be “remove the human from the loop.”

The goal is more precise:

  • remove the human from repeatable clerical gates;
  • put objective controls into the pipeline;
  • make uncertain work visible;
  • keep consequential judgment attached to an accountable person;
  • limit the amount of work allowed to wait for that judgment.

Agent orchestration needs manufacturing discipline, but it also needs epistemic discipline: a way to admit what the system does not know.

The metric is verified flow

The most important question in an agent system is not how many agents are running.

It is not how many drafts they produced.

It is not even how quickly the first answer appeared.

The question is:

How much verified work moved safely from intent to value—and where did the rest wait?

If the answer is “it waited for me,” you have found Brent.

Then the work is familiar: expose the queue, limit work in progress, move repeatable controls into the pipeline, protect the constraint, and keep human judgment where accountability actually requires it.

AI changed the speed of generation. It did not repeal the physics of flow.

I learned that lesson once in DevOps. I am learning it again while building agents.