Running a daily standup with 83 autonomous agents

A standup that no human attends

Every weekday at 09:00 UTC, 83 autonomous agents file a status report. There is no meeting. Nobody talks. The whole thing runs as a cron, and by the time a human looks at it, the work of the standup is already done.

We did not start here. Early on we tried to read every agent's output ourselves, which works at 5 agents and collapses at 30. Managing AI agents at scale is not about reading more. It is about building the layer that reads for you and surfaces only what needs a human. This is how that layer works.

What an agent reports

The value of a standup comes from its structure rather than the ceremony around it. So we forced every agent into the same three-field report, the same way a good human standup forces yesterday, today, blockers.

Each agent reports what it shipped since the last standup, in countable units. Not a sentence. A number with a noun. The sourcing agent reports leads added. The cold-sequence-writer reports sequences drafted and steps awaiting approval. The invoice agent reports invoices sent and payments cleared. If an agent cannot express its work as a count, that is usually a sign its job is too vague, and we redefine it.

Each agent reports what is blocked, with the specific dependency named. Blocked on Apollo quota. Blocked on a list not yet bound to a campaign. Blocked on human approval for an irreversible action. The named dependency is what makes triage automatable. A free-text blocker is noise. A blocker tagged `awaiting_approval` routes straight to a human queue.

Each agent reports its health signals, the same three we use for on-call: last good output, output rate against baseline, and the dispatch-to-result gap. These turn the standup into a fleet health check, not just a work log.

All of it lands in a structured row rather than free prose. That single decision is what makes the rest possible.

We learned the structure rule the hard way. The first version let agents report in free text, the way a person would. It read beautifully and it was impossible to act on. You cannot write a triage rule against a paragraph. You can write one against a field. The moment we forced every report into the same typed shape, the digest, the alerting, and the triage all became code instead of reading. The discipline is the same one a good engineering standup imposes on people, except agents never resist the format.

The triage layer

Once reports are structured, triage is a set of rules running over rows. The chief-of-staff agent runs first and sorts all 83 reports into four buckets.

Green is the default. Output rate within normal range, no blockers, health signals clean. On a typical day, 60 to 70 of the 83 agents are green and a human never sees them. They are summarized into a single line: 64 agents nominal.

Needs input is the bucket that matters. These are agents blocked on a human decision. A sequence step waiting for approval, an invoice over the threshold needing CEO sign-off, a promote-to-roadmap call that wants a scope confirmation. Every one of these carries the specific decision and a link to act on it.

Degraded is agents whose health signals slipped but who have not fully stopped. Output rate at 40 percent of baseline, or a dispatch gap that widened but stayed under the stale window. These do not page anyone. They go on a watch list the reliability agent checks again at midday.

Stalled is agents that crossed a hard threshold, last good output older than twice their interval. These page through the on-call rotation rather than waiting for a human to scroll the standup.

The triage layer also does cross-agent correlation. If five agents in the same division all report degraded at once, that is not five problems. It is one upstream problem, and the standup says so, with the shared dependency named.

The correlation step is worth more than it sounds. Without it, a single upstream outage generates a flood of individual reports that bury the signal. A provider quota runs out and suddenly six agents that all depend on it are degraded, each filing its own line. A human scanning that list sees six problems and starts working them one by one. The correlation rule collapses them into a single entry: six agents degraded, shared dependency is the provider quota, fix once. That is the difference between a two-minute standup and a forty-minute one.

What the human actually does

The human pass is the part people get wrong. They imagine someone reading 83 reports. The reality is that a human reads the needs-input bucket and almost nothing else.

On a normal day that is 8 to 15 lines. Approve these three sequence steps. Sign off on this invoice over the threshold. Confirm scope on this promoted feature request. Decline this one because the lead is already a client. Each is a decision an agent genuinely cannot make alone, either because it is irreversible or because it encodes taste and judgment we have not delegated.

The operator's job in this standup is not to supervise the work. It is to be the unblock function for the small set of decisions that are reserved for a human, and to spot the one cross-agent pattern that the triage rules did not anticipate. That second part is where experience still beats automation. A human will notice that three unrelated agents all slowed down on the same morning and connect it to a deploy, faster than any correlation rule we have written.

Everything else, the green agents, the degraded watch list, the routine ships, is summarized into a digest the operator skims in under two minutes.

The digest format

The digest itself took a few iterations to get right. Our first version tried to be comprehensive and ended up unreadable, a wall of every agent's status. The version we run now leads with the needs-input bucket because that is the only part requiring action, then a single rolled-up line for green, then the degraded watch list, then a short ships summary so the operator has a sense of throughput.

The ships summary matters more than we expected. It is the operator's window into whether the whole machine is producing at the right level. Leads sourced, sequences drafted, replies classified, invoices sent, articles published, all as counts against the prior day. A normal day's numbers tell the operator at a glance that the fleet is healthy in aggregate, even across the 64 agents nobody looked at individually. A bad day shows up as throughput dropping before any single agent crosses a paging threshold, which is an early warning the per-agent signals can miss.

We deliver the digest into the operator's chat at 09:05 UTC, five minutes after the agents file. By 09:07 on a normal day, the operator has approved the handful of pending decisions and the standup is done.

Why this scales

The reason this holds at 83 agents, and would hold at 200, is that the human's workload is tied to the number of decisions reserved for humans, not to the number of agents. Add 40 more agents that produce clean, countable work and the standup gets one longer green line. The needs-input bucket only grows when you delegate more irreversible or taste-laden decisions, and that is a deliberate choice you control.

If your agent operation feels heavier every time you add an agent, the problem is not the agents. It is that you have no triage layer and every report still flows to a person. Structure the reports, sort them with rules, and reserve the human for the decisions that are actually reserved for humans. Then a standup with 83 agents takes one person about two minutes, and the meeting nobody attends becomes the most reliable one you run.