TLDR, for executives
Why it matters. Software teams are moving from one coding assistant to crews of agents that carry work for hours or days, semi-autonomously. Much of that work happens in parallel, and sometimes, in some branches, work sits waiting: on a review, on a version to review, on a person's decision. The usage dashboards, seats and tokens, show the agents busy; they do not show what is stuck.
What we found, in a case study of our own crew, a sample of 53 days, two projects, seven sprints and 367 waits:
- Most waits are short, and expected. Our agents review each other's code across vendors (xLLM review: different models have different blind spots, and the cross review catches bugs one model lets through). A wait for such a review is the process working, and the reviewer is producing. Half the waits ended within about half an hour.
- The cost sits in the few long, unproductive ones. The 13 waits past a day, fewer than one in twenty-five, hold 61 percent of the waiting hours, and in 11 of the 12 that an agent owed, that agent had stopped: output in under 6 percent of the wait while the crew kept working. An agent held by a usage limit, by a vendor's cyber classifier or by its own harness, and one waiting for a person's input, look the same from outside, and our own alarm for an agent idle while it owes work fired for none of them.
- One human guides many agents, so where my attention goes is the question. Waits on me were 3 percent of the waits and 6 percent of the hours; half ended within about two hours of the work reaching me, against half an hour for a wait on an agent, and the longest came while I was travelling. A sprint master, a project manager and a Sentinel watchdog exist so that one person can run a crew; my ownership and guidance stay vital, and the balance to find is where that attention keeps the crew both sound and moving.
- This is easy to count wrong. Our first reconstruction made me the crew's biggest debtor, with 26 percent of the waiting hours; once we ended two waits on a branch we had set aside, my share was 6 percent.
How it helps you. If agents do work for your teams, ask whoever runs them (a vendor, a platform team or your own engineers) for the open waits, oldest first: who owes each one, what waits behind it, whether the agent that owes it is producing anything right now, and if not, what holds it: a limit, a hold, or a question for a person. Give the people in the loop a turnaround target too, with their oldest open request in plain view; the more agents, the more requests reach one person. We built this view into Crew Lens: a 2D wheel for each sprint, with an IOU compass that names the agent to unblock first. The walkthrough and a 65-second video, on synthetic data: agenticobservability.app/2d.
RAIVEN runs its own software work in its agentic lab, with a crew of AI coding agents, Claude Code and Codex side by side, in RAIVEN Base Camp, our multi-vendor meta harness. The agents do long-horizon work, semi-autonomously: an agent carries a task for hours or days, through hundreds of steps and more than one context window, instead of answering a single prompt.
The crew is organised the way a small software team is. Work belongs to a project, a project runs in sprints, and each agent keeps its own backlog of the work items it owes. One agent produces a work item and another reviews it, an agent from the other vendor where we can arrange it: we call that xLLM review. Different vendors' models have different blind spots, and a cross review finds and fixes bugs that one model's own review lets through; the code is better for it, and a wait for such a review is the process working, with the reviewer producing while the producer waits.
Two agents carry a role on top of their own work: a sprint master runs each sprint's rhythm, and a project manager keeps each project's plan; a Sentinel watchdog watches the agents' health. All three exist so that one person can run a crew. They help me, the crew's human operator, orchestrate the rest; they do not replace me. I set the direction, take the decisions that need a person, and nudge an agent that has gone quiet. Human ownership and guidance stay vital in a crew like this; what the crew's size changes is where that guidance should go.
This report is about the other kind of wait: the long, unproductive ones, where nothing moves because the agent that owes the next step is held, by a usage limit, by a vendor's cyber classifier, by its own harness, or because it waits for a person. The sample behind it: 53 days, 26 August to 18 October 2026, two of our projects (the harness itself, and Deckmate, our macOS app for presenting slide decks you author with your agent), seven sprints, and fifteen agents among the waits. It is a case study of our own crew, not a survey.
Work in a crew like this moves by hand-offs, and each hand-off is a wait. A reviewer waits for the producer to freeze a version it can review; the producer then waits for the review; an agent waits for my decision. Part 1 of this series made the crew's record watchable as a 3D replay; you do not need it to follow this one. Watching that replay, I kept seeing agents standing still, and in 3D an agent that waits looks the same as an agent with nothing to do.
What 53 days of record show
Our harness does not record waits as such, yet. It records the messages that open and close them: a review request opens one and the review closes it; a decision put to me opens one when the work reaches me, and my decision, or the work moving on, closes it. Reconstructed that way, our crew's record from 26 August to 18 October 2026 holds 369 waits. Two of them are not waits, and they happen to be the two longest (more on them below). Without them, 367 remain, across 7 sprints.
Most are short, as our way of working expects of a review wait. Half ended within about half an hour, and nine in ten within about eight hours. Thirteen lasted more than a day, and those thirteen hold 61 percent of all the waiting hours, 908 of 1,495. Four ran past three days.
In most of the long ones, the agent that owes the wait has stopped. The record keeps each agent's output in tokens per five minutes. In 11 of the 12 waits over a day that an agent owed, that agent produced output in fewer than 6 percent of the wait's five-minute slots, while the rest of the crew kept working; six agents account for the eleven. Our harness has an alarm for an agent idle while it owes work. It fired six times up to 1 October, and not once for these.
The longest was still open when we exported the record: x11 waiting on x12 for a fix. x12 committed a finished fix on the evening of 10 October, and nine minutes later the vendor's cyber classifier held it. x12 produced nothing for the next nine days. On 19 October I handed the fix to c1, who composed it onto the current base that evening.
The longest that ended: x6 waited five and a half days, from 7 to 12 October, for c1 to freeze a version it could review. c1 stopped producing on the evening of the 9th, came back on the evening of the 12th and handed over its version within two hours. BC2 had reported its watcher, the task that wakes it when a message arrives, down on 7, 8 and 9 October, though it reports that on days c1 keeps working too. The fix x12 had finished was for the check that notices a Claude agent idle while it owes work.
The two that are not waits were still open when we exported the record, 27 days each: x10 waiting on my review, and x7 waiting on x10. Neither was waiting on anything by then. We had set that branch aside for a long spike, nothing in the messages said so, and the reconstruction kept both open. Counted as waits, those two would have made me the crew's biggest debtor, with 26 percent of all the waiting hours; without them, my share is 6 percent.
Waits on me are few: 10 of the 367, 3 percent, and 91 of the waiting hours, 6 percent, seventh of the 13 who owed any. Counted from when the work reached me, half ended within about two hours, against half an hour for a wait on an agent. The longest, almost three days, was a review that reached me on the evening of 1 October, two days before I travelled. For 35 of its hours, in several stretches, the whole crew produced nothing, most likely with the laptop closed, and the work was cancelled an hour and twenty minutes after the crew's output resumed on the 4th.
Our first reconstruction counted a wait on me from when its work was filed, not from when it reached me. That put the agents' own producing and reviewing on my account and made my median almost seven hours; one request stayed on my account for a day after the crew had replaced its work.
Agents wait on each other in loops too, briefly. Seven times, two agents each waited on the other at once, each time over different work items, for 51 minutes at the longest; on 17 October three agents waited on each other in a ring, twice for about an hour (and once for 20 seconds). We have not seen a deadlock on the record so far (a loop whose waits all sit on one work item).
A wait is a line between two agents
So the waits got a view of their own, flat this time. The 2D lens draws one sprint as a wheel: each agent a place on the rim, the human's place, labelled owner, at twelve o'clock, the sprint's work items in the middle. A wait is a line from the agent that owes it, thick at that end, to the agent that waits, through the work item it is about. A pill on the line gives its age, mint under an hour, then amber and orange, red after three days. Frost forms on a wait with no progress for a day, and the light along a line slows as the wait ages, so an old wait looks stuck before you read its pill.
The IOU compass
Next to the wheel sits the IOU compass, one pie for the sprint. Each wedge is an agent that owes waits, sized by the hours those waits have run and coloured by its oldest. The needle points at the agent to unblock first: the root of the longest chain of waits, an agent that waits on nobody else. Rings inside a wedge count its waits, dashed while one of them has not been picked up, and the middle of the compass switches the wait lines on and off.
Chains, loops and deadlocks are worked out from the waits at every moment of the replay; nothing about them is stored. A loop shows in amber, with a mark on its longest hop. When every hop of a loop sits on one work item, it is a deadlock, and it turns red. When a loop holds up more hours than any chain, the compass names the loop, and the agent to break it at.
One nudge
The 2D walkthrough tells one story on a synthetic record, made up for the page: the crew, the sprint and the timings are invented, and each kind of wait in it occurs in our crew. x5 is to review x2's work and waits for x2 to freeze a version. x2 went quiet at 01:00 on Tuesday. By Thursday at 09:00 the wait is 2 days, 19 hours and 40 minutes old, x4 waits on x5 behind it, x6 waits on x2 for a version of another work item, and the compass says to unblock x2 first: 127 hours held up across three agents.
At 09:05 the human owner nudges x2. x2 is back at work two minutes later, freezes the first version at 09:40 and the second at 10:05. x5 and x6 review them, both work items converge, x4's wait closes at 11:05, and the compass is empty: nobody owes a wait.
Every sprint at once
Zoomed out, the atlas draws every sprint as a galaxy in its project's cloud, with its wait lines still drawn, and one IOU compass adds up the waits of every sprint on the map. A project can be switched off to give the others the room, and the galaxies open into their wheels as you zoom in. It works on a phone too: there the compass folds into a band over the map.
Waits in the Crew Record
Version 0.1 of the Crew Record adds the waits as data: who waits on whom, over which work item, since when, and whether anyone picked the wait up. It also adds approvals, roles and spikes. Chains, loops, deadlocks and the compass are computed from the waits, so a harness that writes waits gets all of them with it. Two rules came from our own record. A wait on a person starts when the work reaches them, not when the work is filed. And a wait can end without an answer: when its work item or its branch is set aside, it ends as superseded and stops counting. A version 0 record still opens, and the format keeps the course Part 1 set out: toward OpenTelemetry's conventions for agents as they mature.
What to do with it
Two things are worth asking of a setup that runs agents on long tasks. First, ask for the open waits, oldest first, with who owes each one, what waits behind it, whether the agent that owes it is producing anything, and if not, what holds it: a usage limit, a classifier's hold, its own harness, or a question for a person. A short wait for a cross-vendor review is the process working; on our sample, most of the long waits were an agent that owed the next step and had stopped, while the crew as a whole looked busy.
Second, give the people in the loop a turnaround. One person guides many agents, and more agents bring more review and approval requests to that person; a sprint master, a project manager and a watchdog take the routine off them, and the decisions that remain are the ones that need a person. On our sample a wait on me ran about two hours at the median once the work reached me, against half an hour for a wait on an agent, and the longest came while I was travelling. An approval queue deserves the care you give any other service with users waiting on it: the oldest open request in plain view, wherever the person is, so that the person's attention goes where it keeps the crew sound and moving.
Where to see it
The walkthrough, on the synthetic record, and a 65-second video: agenticobservability.app/2d. Crew Lens runs in our lab and is being readied for release as an app that runs next to your agents and sends your record nowhere. Early adopters get early access.
Where the numbers come from
The crew's figures come from our crew's record as the 2D lens reads it, exported on 18 October 2026: the metadata of the messages between the agents and with me, from 26 August, and each agent's output in tokens per five minutes. A wait opens with a request (to produce, to review or to decide) and closes with its answer, or with the work item's next state; a wait on me opens when the work reaches me and closes with my decision or the work's end (four of the ten approval entries name no one; we count them as mine); a wait still open at the export runs to the export. Waits left open by set-aside work end as superseded: the two on the branch we set aside for a spike, which do not count at all because the moment is not on record, and one request whose work the crew had replaced, 49 minutes into my turn. That leaves 367 waits; the three still open at the export were all live. An agent is silent in a five-minute slot when its output is zero. Waits run in clock time: 16 percent of the waiting hours fell in stretches of three hours or more when the whole crew was silent, most of them, we think, with the laptop closed. A loop counts when its waits are open at the same moment, and once for each stretch of time it holds. The median of an even count is the midpoint of the middle two; the 90th percentile is by nearest rank. The story in the walkthrough and the video is a synthetic record generated for them, and its numbers are read from it. The numbers are measured, and the record behind them stays in our lab; a second agent re-derived every figure before publishing.
What this doesn't claim
- That our harness measures waits directly. They are reconstructed from message metadata: a wait the messages do not show is missing, and a request nobody answers stays open. We ended the ones we know were set aside; others like them may remain.
- That the waits on me measure how fast I answer. They run in clock time from when the work reached me, travel included.
- That we know why each silent agent stopped. Zero output says the agent produced nothing; a cyber hold explains two of the eleven waits, and a watcher reported down may explain a third.
- That every wait is waste. A review that waits for a frozen version is the process working; the cost sits in the long ones.
- That the compass's first is the most important first. It ranks hours held up, not value or urgency.
- That the story in the walkthrough happened. Its crew and its sprint are synthetic, and so is the nudge; the kinds of wait are real.
- That this generalises beyond one lab: one crew, 53 days, our own harness.
- That Crew Lens is released. It runs in our lab; the release is being prepared.
P.S. New here? What a RAIVEN field report is, and what it refuses to be:
About these field reports
Let's be honest: most AI-generated content in your feed right now is slop. Prose written from other prose, about nothing that happened, worth nobody's time. Here is my promise instead: these posts are AI-polished, but never AI-invented. Every one of them is anchored in real work in the technology trenches.
They are first-hand field reports from RAIVEN, my AI lab in Eindhoven: a working multi-vendor fleet of AI agents that I run daily, both to build real systems and to find out exactly where this technology breaks, and what imperfect but practical remedies push it further. Some reports come with full forensics behind them, down to file hashes. Others describe a pattern from real work whose details stay private: client engagements, security-sensitive systems. Each report says which kind it is, and its claims never pretend to more evidence than it shows.
I write first for executives and decision makers steering in-house AI efforts. The strategy world is full of AI decks assembled by people who never operated the technology they present. These reports are the opposite: trench-level truth, translated into what it means for your decisions. I use my own agents to draft and polish; I am not a native English speaker, and I have a fleet for a reason. But the experiences are real, the judgments are mine, every post is vetted and signed by me, and the numbers are checked against the underlying evidence before publishing.
Field reports are dated observations, not eternal truths, and I will get some things wrong. When a substantive mistake surfaces, whether I find it or a reader does, I publish a dated correction on the post itself. Being corrected in public is part of the method here, not a failure of it.