Skip to content

Why the daily standup fails an AI-native team

Daily standup not working? Why it breaks when agents write most of the code, and how to split status from coordination, with a template to run this week.

7 min read

  • status and standups
  • rituals
On this page

A daily standup stops working on an AI-native team because it assumes people did the work and can report it. When agents open most of the PRs, each person can only describe their own slice, so the round-robin produces an incomplete picture and crowds out the things only humans can say: what is blocked, what needs a decision, what no tool shows. The fix is to split status, which should come from your tools, from coordination, which is the only thing worth live attention.

Is your standup just people reading the board aloud?

Say it is 9:30 and the call has started. Someone shares the board and each person walks down their column: "Still on the onboarding flow, should be done today." "Waiting on review." "Picked up the billing ticket." Meanwhile, say 30 PRs merged overnight across three products. Nobody on the call opened most of them, and the board has no card for half of them.

You ask a simple question: "What shipped since yesterday?" Three people start scrolling. Someone says they think the settings change went out. Someone else says an agent was working on it but they have not looked. The standup is now a group search through GitHub, on the clock of everyone's morning.

You leave knowing what people say they are doing. You do not know what changed in the product.

Why does the daily standup break when agents write the code?

The core problem is a mismatch of speeds. AI-native teams create context faster than people can sync it, manage it or remember it. Agents open PRs all day, decisions get made in Slack threads, and plans shift mid-week. The standup is a ritual built for human-speed change: a handful of people, each doing one or two things, each able to summarize their own work in a short turn. It works when the sum of what people say is close to the sum of what happened.

On our own team that sum no longer holds. Agents write most of Liouville's code, and one of our products shipped 200+ PRs in two weeks. A person's "yesterday" covers the work they directed or reviewed, not everything merged under their name, and certainly not what merged under a teammate's. The report is incomplete by construction, not through anyone's carelessness.

The cost shows up in three places:

  • Time reassembling context. The first part of the call goes to establishing what happened, which a list could have told you in seconds.
  • Decisions missed or reopened. A decision made in a thread yesterday never comes up, because nobody reports it as "work." Two days later someone builds against the old assumption.
  • Blockers that stay quiet. When the call is mostly recitation, the one person with a real blocker says "nothing, I'm fine" and moves on, because there is no obvious slot for it.

What do teams usually try instead?

Each common fix solves a real part of the problem. None of them solves the part that changed.

Async standup bots. Tools such as Geekbot and Range (Standuply is another) ask each person a few questions in Slack and collect the answers. They are good for time zones and for removing a meeting from the calendar. They still depend on people typing what they did, so the agents' output stays invisible. You have moved the same incomplete report from voice to text.

Walking the Jira board. A board is a shared reference and keeps the call concrete. It is also only as current as the last person who updated it. Work that agents start and merge in a single afternoon often never gets a card, so the board describes the plan, not the product.

AI meeting notes. Transcripts and summaries save someone from taking notes and make the call searchable. But they summarize what was said. If the call was a recitation of incomplete status, you now have a well-formatted summary of incomplete status.

Reading every PR yourself. It is the most accurate option, and it stops being possible quickly. At agent volume nobody can read the diffs, which is a topic we cover in too many PRs to review.

The common gap: all of them treat status as something people report. On an AI-native team, status is something the tools already know.

What works instead: split status from coordination

Stop asking people to say what happened. Read it from the tools, and spend the human time on the three things the tools cannot tell you.

StatusCoordination
QuestionWhat changed since the last check?What is blocked, what needs a decision, what is not visible in any tool?
Best sourceThe tools: a merged-PR list per product, open reviews, CI statePeople, in a short written or live exchange
CadenceReady before the day startsDaily, but only as long as there is something to say
Failure if mixedStandup becomes a recitalBlockers and decisions get crowded out
OwnerWhoever sets up the list (once)Each person, for their own items

Step 1: Make status a read, not a report

Before standup, someone (or something) produces a list of merged PRs per product since the last check, with a link to each. A saved GitHub pull request search per repository is enough to start: filter on is:merged merged:>=YYYY-MM-DD, using yesterday's date (or the date of the last working day), with one tab per product. Everyone skims it before the call. Nobody narrates it. If something in the list surprises you, that surprise is the first agenda item.

Step 2: Cut standup to three questions

Keep the call, or the async thread, to these:

  1. What is blocked? Anything waiting on a person, a review, an access grant or an answer.
  2. What needs a decision? Name the decision and who can make it. If it is made in the call, write it down.
  3. What is not visible in any tool? A customer conversation, a design direction, a worry, a conversation that happened off Slack.

If nobody has anything for a question, that is the answer and the call ends. A very short standup is a good outcome.

Step 3: Use a five-line async template

If you run standup in a Slack thread, ask each person for this. It is a template, not real data:

Blocked: (what, on whom, since when) or "nothing"
Needs a decision: (the question, who decides, by when) or "nothing"
Not in any tool: (what the rest of us cannot see) or "nothing"
Decided since yesterday: (one line, with a link to the thread or PR) or "nothing"
Looked wrong in the merged list: (PR link, one line) or "nothing"

The last two lines are the ones that pay off at agent speed. A "decided" line gives the team a record that outlives the thread (see the decision log template). The "looked wrong" line is a cheap human check on the merged list: a sample entry might read "PR for the export change touches the permissions module, not what we agreed." Anything flagged there gets a name and an owner before the call ends.

Step 4: Run it for two weeks, then prune

Track one thing: how many standups ended early because the three questions were empty. If it is most of them, move to async only and keep the live call for the days with a real decision. If the "looked wrong" line keeps surfacing real surprises, the merged list matters more than the call, and you should spend your effort making it faster to produce.

Where does Biddle fit?

Biddle, an AI chief of staff for product teams, automates the status half of this split: it reads GitHub and Slack (the only sources today; Linear and Notion are coming, not integrated) and posts a team briefing in #askbiddle every weekday morning, so the merged-work list exists before anyone sits down. It is read-only, and per-person notes are written and reviewed but not sent yet (they run in shadow, as the member briefing section describes); Biddle is also still learning to flag a merged PR that contradicts a decision. It is in early access and runs every weekday for our own team, and how it works shows the flow end to end. If your standup is people reading the board aloud, you can request early access to see whether a weekday briefing could replace the status half.

Common questions

Is a daily standup still useful for an AI-native team?

Yes, for coordination: blockers, decisions and anything invisible to your tools. It stops being useful as the place where status gets assembled, because people cannot report work they did not do by hand.

Should we move to an async standup?

Async helps with time zones and meeting load, and the five-line template above works in a thread. It does not fix the missing status on its own, so pair it with a merged-PR list that comes from the tools.

How long should the live call be?

As long as the three questions need. If nobody is blocked, no decision is pending and nothing is hidden, ending in a few minutes, or skipping the call that day, is the right result.

Want this in your Slack?

Biddle reads your GitHub and Slack and sends you a briefing each weekday morning, with every claim linked to the PR or thread behind it. We’re onboarding a few product teams now, and we set each one up with you.

Request early access

9 min read

What is an AI chief of staff for product teams?

What an AI chief of staff for product teams does, how it differs from email assistants and exec dashboards, and how to tell whether your team needs one.

  • ai chief of staff
  • management