The morning review queue is now an org-chart question, not a tooling question

I spent the last few days reading what showed up in the harness world between Saturday and Monday, and the same shape keeps appearing. Engineering leaders are no longer asking which coding agent to standardize on. They are asking who, by name, opens the laptop at 8am and decides what to do with the thirty pull requests that landed while everyone was asleep.

That is a different problem. And it does not get solved by buying a better harness.

What changed in the last week

Three things landed inside the May 9 to May 12 window that, taken together, force the question.

Ekta Chopra, writing on the AI-First Board Substack on May 9, laid out a clean framing of what enterprise Claude Code rollouts actually look like under the hood. Her argument was that the binding constraint is not deployment speed. It is the operating model around the deployment. She wrote that “the enterprises that win in the agent era won’t be the ones who deployed Claude or ChatGPT or Gemini fastest. They’ll be the ones who built the operating model that lets agents accelerate the business safely.” Her proposed primitive: a tiger team of five to fifteen forward-deployed engineers who translate domain knowledge into governed agent skills, sitting behind what she calls an agent firewall.

Two days later, the AI Agent Conference coverage on SiliconANGLE on May 11 surfaced a sentence from Barr Moses of Monte Carlo that should be sitting in every CTO’s inbox: courts have already ruled that the company behind an agent, not the user who triggered it, bears full accountability. That is the legal weight under the org-chart conversation. The person who owns the morning queue is the person whose company eats the incident.

And on the same day, a VoIP Review piece pulled the Gartner projection that AI agents will be embedded in 40 percent of enterprise applications by end of 2026. Whatever the precise number turns out to be, the direction is clear. The agents are not confined to the engineering team anymore. The review queue is going to keep growing.

What engineering leaders actually tried

I have been on three calls this past week with engineering leaders running between two hundred and twelve hundred developers. Each of them had switched on background or remote agent capabilities in the last sixty days. None of them had updated their org chart.

The first pattern was the implicit assignment. The team had quietly decided that whoever was first to standup owned the queue that day. This works for about a week. Then a senior engineer realizes she has spent eleven of the last fourteen mornings rubber-stamping agent PRs while her own architecture work slides, and she goes silent in standup.

The second pattern was assigning it to the on-call rotation. This sounds tidy. It is not. On-call is paid for incident response. Agent PR triage is not an incident. It is sustained product work, with architectural implications, that happens to arrive in a queue. Folding it into on-call burns out the rotation and quietly tells the team that overnight agent output is unimportant enough to handle in fragments between pages.

The third pattern, the one that is starting to work, is the named role. One CTO I spoke with last week put it cleanly: she carved out one staff engineer per service area as the morning queue owner for that area, with explicit time budgeted and explicit ladder credit. Same job title. New responsibility. Visible on the org chart.

Where it broke, and where it worked

The implicit-assignment pattern broke quietly. No one quit. No PR got dropped. But velocity on the architectural backlog stalled, and when I asked the engineering manager why, she could not point to a meeting that had been moved or a decision that had been deferred. The cost was distributed across forty mornings of small attention thefts. That is the most expensive way for a tax to arrive, because nobody can name what they paid.

The on-call pattern broke loudly. The team had two production incidents land in the same week that an agent had merged a refactor touching the auth service. Nobody could untangle whether the incidents were related to the agent change, because the reviewer was the on-call engineer who was three pages deep into Datadog when the PR went green. The post-mortem ended with a sentence that should make any CTO uncomfortable: “we are not sure who reviewed this change.”

That is the Moses problem made concrete. If the company is accountable for what its agents shipped, the post-mortem needs a name.

The named-role pattern worked because it put two things on the org chart that were previously floating. First, a per-service queue owner. Second, time budgeted for queue work in the ladder rubric, so the senior engineer was not silently sacrificing her staff promotion case to review agent PRs. The CTO told me her queue-owner role looks a lot like the Chopra tiger team, just smaller and embedded in the existing eng org rather than centralized. Same shape. Different blast radius.

The pattern under all three

The harness vendors solved the writing problem. The org chart has not solved the reviewing-and-owning problem.

That mismatch is not new. Background agents just make it impossible to ignore. When code took eight hours to write, the reviewing task was paced by the writing task, and the org chart could be left alone. When code takes forty minutes to write and shows up in a queue at 7am, the reviewer is the throughput-limiting station on the line, and the throughput-limiting station has to have a named owner with a budget.

The pattern I am seeing in the orgs that handle this well has three pieces.

First, there is a named owner per service area. Not a rotation. Not a volunteer. A role with a person on it, written down where everyone can see it. The Chopra framing of a tiger team is the centralized version. The per-service queue-owner is the federated version. Both work. The version that does not work is no version.

Second, the queue work appears on the ladder rubric. If a staff engineer is going to spend ninety minutes a day on agent PR triage, that work needs to count toward staff-level expectations the same way design docs do. Otherwise the role gets quietly resented and slowly abandoned, and the team is back to the implicit-assignment failure mode.

Third, the queue has a visible work-in-progress limit. If the queue is allowed to grow without a cap, the agents will fill it. Anthropic doubled Claude Code rate limits last week. Cursor reported that 35 percent of its own internal merged PRs are written by autonomous cloud agents. The supply side is not the constraint. The queue cap forces the conversation about which agent work to run and which not to, which is the conversation an engineering leader actually wants to be having.

What I would tell you over coffee

The most useful thing I can say after this past week is that the question on the table is no longer “which harness.” It is “which named human.”

If background agents are committing code while the team is asleep, the answer is not a better tool. The answer is three things on the org chart by next quarter. A queue owner per service area, with the role title written down. A line in the ladder rubric that says queue work counts. And a work-in-progress cap on the queue itself, so the agents do not outrun the only humans who can absorb the legal weight of what they shipped.

The good news is that this is figure-out-able with the eng org already in place. Most of the engineering leaders I spoke with this week solved it by repointing existing staff engineers, not hiring new ones. The bad news is that if the role does not get written down, it gets written for you, badly, by Wednesday morning.