The agile standup when agents report their own work

Stefan-Iulian Tesoi · 18 September 2026 · 6 min read

An agile standup loses its reporting half, because the repository already answers what happened yesterday and the board already answers what is next. What it does not lose is the part nobody scheduled: two people discovering, mid-sentence, that they are about to build the same thing. That discovery rode along with the status, and removing the status removes it.

Teams that cancel the meeting usually get the fifteen minutes back and lose that, without noticing for about a month.

What is an agile standup for once agents report themselves?

Deciding which work in flight has become the wrong work. Everything else it carried is now a query against systems that already hold the answer.

The three questions divide unevenly once a coding agent is doing the building.

Two of those rows are a report that can be generated. The third is the meeting.

Was the standup ever a status meeting?

It was not, and the agile literature has said so for a decade. Jason Yip's patterns for daily stand-up meetings names the failure: a stand-up "focused on the runners, not the baton" is one where people describe what they are doing without considering whether it moves the work. His fix is to reframe the meeting so the work items attend and the team walks the board rather than the room.

That was advice a team could decline, and plenty did.

Agents remove the option. Nothing in the sprint has a person whose day needs narrating, so a meeting organised around people has no content at all, and what Yip proposed as a discipline becomes the only form left.

What the agents cannot overhear

The standup's most valuable output was usually accidental. Someone describes what they are starting and another person says it was done last week, or that it will break the nightly import. Nobody scheduled that; it was a side effect of saying work out loud in a room.

Agents generate no such collisions. They do not hear each other or the room, and two handed overlapping items will both proceed — plausibly, in different directions — until the conflict surfaces at merge. Engineering status updates from an agent are accurate about one item and blind to every other.

Removing the reporting from a standup is free. Removing the eavesdropping is not, and it goes at the same time, because it was never a separate thing.

So the coordination has to be rebuilt deliberately, and it moves out of the meeting and into the backlog:

• Dependencies as item ids, not as sentences. "After the auth work" is invisible to anything reading the item. An id is a thing the board can order and an agent can be blocked on.
• Paths on the item. Two items naming the same files are a collision visible before either starts, which is the only cheap moment to see it.
• One item per agent, in its own worktree. Isolation does not prevent overlapping work; it stops two agents corrupting each other's checkout before anyone notices.

What an item has to carry for this to hold is set out in a backlog an agent can read.

Does an agent's status report need checking?

Yes, and the check is against what Git records rather than against the tone of the report. Status reporting with AI agents fails in a specific way: the summary is confident, internally consistent, and describes the work the agent believes it did.

A commit message is a claim and the diff is the evidence — the whole argument in definition of done when an agent wrote the code, not worth repeating. The part belonging to the meeting is narrower: a human update could be sanity-checked against a person you knew, and an agent's cannot. A report saying the tests pass is worth what the command and exit code in the item are worth.

This is why in Laimonade an agent carries an item as far as In Review and no further: there is no tool that sets Done, so a claim never closes anything. How Laimonade works covers what travels with the item, and the sprint workflow where the handover sits.

What replaces the daily meeting?

A ten-minute walk of the board, held over the items rather than the people, plus somewhere to raise an obstacle that is not a meeting.

The agenda is short because most daily standup alternatives fail by keeping the round-the-room shape and changing its name:

1. In Review, oldest first. Anything sitting more than a day is the real bottleneck, and it is a person's queue rather than an agent's.
2. Ready, top three. The only question is whether they are still the right three — what sprint planning decided on Monday, and what the week has since changed.
3. Anything blocked, and on whom. An agent can report being blocked; it cannot decide that waiting three days for an answer is now the most expensive thing on the board.

One honest loss: saying "I will finish this today" to colleagues created a small social commitment, and nothing here replaces it. The work becomes more visible and less personally owned at once. For a team of five, the fifteen-minute meeting cost a little over six hours a week; recovering most of that is real, and it is not free.

Frequently asked questions

Should the team stop doing standups entirely?

No, but it should shrink and change subject. Keep a short session organised around the board — the In Review queue, the top of Ready, anything blocked — and drop the round of individual updates, which is the part the repository now answers. Teams that cancel outright usually rebuild a worse version of it in a chat channel within a month.

Can an agent write the status update?

It can write the factual part, and that part is better than a person's: the commands run, their exit codes, the files touched, the criteria checked. What it cannot supply is the judgement that something in flight has stopped being worth doing. A report describes the item it was given, with no view on whether that item still deserves the sprint.

How do you catch an agent that is stuck?

Look at the item's age rather than its updates. An agent that is looping produces steady, plausible activity, so no report will say it is stuck. What does say so is an item in progress far longer than its neighbours, or one back in review twice with the same criterion failing. Age and bounce count are the signals; narrative is not.

Does this work for a distributed team?

Better than the meeting did, because the artefacts are written rather than spoken. The board, the items and the evidence attached to them are readable at any hour, which removes the timezone problem that made a daily synchronous call awkward. What still needs a slot is the judgement call about priority, and that can be twice a week.