Daily standup

Standup exists to answer three questions: what changed, what happens next, and what is blocked. The questions are worth answering every day. The fifteen-minute call around them usually is not.

On a call, the answers are spoken once, heard by whoever showed up, and gone. Nobody can search them. Anyone in another timezone gets them secondhand. And an agent running against your repo cannot attend at all.

Write the answers down instead. Same three questions, same cadence, in a channel or a doc that anyone can scroll back through.

What a good update contains

• What you worked on since the last one.
• What you are working on next.
• What is blocking you, named plainly, with who can unblock it.

Three rules make those answers useful to somebody who was not there:

1. Write it before you post it, not while you type into the channel. You will remember more and ramble less.
2. Say what the ticket is about, not just its number. CORE-123 means nothing to the person reading on Monday.
3. Name the blocker and the person who can clear it. "Blocked on the payments API" sits there for days. "Blocked on the payments API, need staging credentials from Priya" gets cleared.

An update that follows those rules:

CORE-123, the endpoint that exposes a customer's saved payment methods: handlers and serializers are done and merged behind a flag. Next is the test suite, then review. Blocked on nothing.

Running standup with agents in the loop

An agent fleet makes the written version load-bearing rather than merely convenient.

Overnight, agents produce diffs that no human watched being written. Those diffs need the same three answers, and nobody can give them from memory. So the update stops being a report on people and becomes a report on work: what landed, what is queued, what is stuck, whether a human or an agent did it.

The written update is also context. An agent that reads yesterday's status starts its run knowing what changed and what was already tried. A spoken standup leaves it with nothing, and it rediscovers the same dead end you talked through on the call.

Two things follow:

• Agents report in the same format as people. If an agent opened a pull request, closed a ticket or failed a run, that belongs in the same place, written the same way. Separate dashboards for "what the humans did" and "what the bots did" hide exactly the handoffs that break.
• A blocker on an agent is a harness problem, not a status item. When an agent stalls for want of credentials, a missing test command or an ambiguous ticket, the fix belongs in the harness, not in tomorrow's update. Log it once, fix the layer, and it stops recurring.

Keep the meeting only if it is doing something the written update cannot: an actual decision, a disagreement to settle, or a demo. Those are worth a call. Reciting yesterday is not.