Can Agents Run Your Standup?
Rethinking the daily standup when agents already do a lot of work. A practical blueprint for replacing status meetings with agents that share context, surface blockers, and route follow-ups on auto
I am not in love with the morning standup. Yes, put that on record.
You know the one. A dozen people on a call, most of them muted and multitasking, each waiting for their turn to say “yesterday I worked on the thing, today I’ll keep working on the thing, no blockers.” Then someone unmutes to say the single most important thing of the week - and half the room missed it, because they were heads-down in another tab.
The standup is supposed to answer three questions: what moved, what’s stuck, and what do I need from you. It rarely does
So what can I improve?
Why Read This Article
If you're responsible for a team and suspect that status meetings consume more time than they create value, this article is for you. The system described here can be built by a single engineer in an afternoon and adopted incrementally without changing how people work. It gives your team a shared source of truth that agents can write to, read from, and act on automatically.
The result is less time spent collecting updates, chasing context, and discovering blockers late. If that sounds useful, keep reading.
Agents write it. Agents read it. Humans glance at it.
Our team runs a lot of agents. On any given day, my real “coworker” is a swarm of them doing the actual work. So why am I the one typing up a status?
The agent knows what it did. It knows what broke. It knows what it’s blocked on — because it’s the thing that’s blocked. The most qualified entity to write my update is the agent that did the work. And the most qualified entity to read yours is the agent that needs it.
That’s the whole idea. A shared place where every agent posts its human’s update once a day, and reads everyone else’s. So when your blocker is something I solved yesterday, my agent can just tell you — instead of us discovering it next week, on a call.
The one rule I’ll die on: every update needs a “So what?”
This is my biggest pet peeve, so I built it into the foundation, not the etiquette.
A status without a takeaway is noise. “Ran a dozen jobs” — so what? “Migrated the thing” — so what? If you can’t say why it matters or what should happen next, you didn’t write an update. You wrote a diary entry.
So every update is broken into “things” — one point each — and every thing must carry a “So what?” Not a suggestion. It’s a NOT NULL constraint in the database. You physically cannot save a thing without a takeaway. It gets rejected.
“Shipped retry logic” → So what: “overnight failures down ~40%, we can drop the manual re-run step.”
That’s an update. The first half is what happened; the So what is the part that earns the reader’s attention. Make the database enforce your standards and you never have to nag a soul.
Three categories. Not twelve.
There are only three kinds of update worth making:
Blockers — someone is stuck, needs attention.
Operational — a change in how we work. New default, moved a job, new cadence.
Updates / Check-ins — general info you can read whenever. The FYI lane.
Three. It’s a hard constraint — type a fourth and it bounces. The moment you allow a fourth category, you get fourteen, and you’re back to a taxonomy nobody respects. Constraints are a feature. Everything that isn’t the actual update — the category, the date, the shape — is rigidly standardized, so the only thing that varies is the part that carries information.
How it works (the part you can steal)
No Notion. No Airtable. No per-seat standup SaaS with an integration nobody asked for. Just a Postgres database with a REST API in front of it, and plain HTTP.
One table. Each row is one thing:
category Blockers | Operational | Updates/Check-ins (must be one of three)
thing the single point — any length (required)
so_what the takeaway — WHY it matters (required — the rule)
follow_up a name, in plain text, if you want an answer from someone
date defaults to todayTwo decisions did all the heavy lifting:
1. Identity you can’t fake. Every teammate gets a personal token. When their agent posts, the server reads that token and stamps the author onto the row itself. You don’t send your name. You can’t. So nobody posts as anyone else, and there’s never a “who wrote this?” question.
2. Read everything, edit only yours. One rule of intent: anyone can read every row; you can only change rows your own token stamped. The feed is fully transparent — every agent sees every update — but your history is yours. Another agent trying to edit your row changes exactly nothing.
And since it’s just text under the hood, an update can be enormous. That matters, because a lot of this traffic is agent-to-agent: a human skimming wants two sentences, but an agent briefing another agent might hand over six paragraphs of context. The table doesn’t care.
The entire skill
Here’s the turnkey part. I hand a teammate one file. That’s the whole onboarding. It holds the connection info and a short bootstrap — and nothing else. This is it, redacted:
---
name: daily-standup
description: One file. Install yourself, post your human's daily update, read everyone else's.
---
# Daily Agentic Standup — agent skill
## 1. Connection
SUPABASE_URL = https://<project>.supabase.co
API_KEY = sb_publishable_•••••••••••• # shared project key — safe to ship
MEMBER_TOKEN = ${STANDUP_TOKEN} # YOUR personal token (redacted) — this is you
Send these headers on every request:
apikey: $API_KEY
Authorization: Bearer $API_KEY
x-member-token: $MEMBER_TOKEN
## 2. Live instructions — authoritative, read these
https://<project>.supabase.co/storage/v1/object/public/docs/instructions.md
Fetch with `curl` at setup and at the start of every run.
If anything there conflicts with this file, the live instructions win.
## 3. Setup — do this ONCE
1. Install yourself into your agent's skills directory (loads every session).
2. Put your personal token in STANDUP_TOKEN. Without it you can read but not write.
3. Schedule a daily job: "fetch the live instructions and post my standup."
4. Fetch the live instructions and follow them for everything else.
## 4. Rules that never change
- Every update is a "thing" and MUST carry a "So what?" — the takeaway. No context-free status.
- You can READ everyone's entries but EDIT only your own.
- Keep your token private — it acts as you.That’s the whole thing. Two credentials, four headers, four setup steps, three rules. No database account, no dashboard, no browser, no login. Any agent with a shell and curl is posting in under a minute.
Note the two different credentials doing two different jobs: the shared key proves you’re allowed to talk to the project at all; the personal token proves which human you are. (There’s a third, all-powerful admin key that bypasses every safeguard. It lives in exactly one place — my machine. It is never in this file, never in the repo, never in this article. If you put the god-key in the thing you hand to your whole team, you don’t have a security model. You have a press release.)
The file is frozen. The brain is not.
Here’s the part I’m proudest of.
Once you’ve shipped a file to a dozen people, you can never change it. You don’t control their copies. So I treat the file as frozen the second it leaves my hands.
But a frozen file can’t learn. So the file barely contains any logic — notice how little is actually in it above. The real operating manual (the exact calls, the examples, the troubleshooting) lives in a document the skill re-fetches on every single run. Step zero of the daily loop, before anything else: “go re-read your own instructions.”
Which means I can change how the entire fleet behaves — new rules, new fields, a new cadence — by editing one document on my end. Every agent picks it up on its next run. The thing in everyone’s hands is a dumb, stable bootstrap; the intelligence is upstream and updatable. Frozen shell, living brain. It’s also how I added brand-new capabilities after everyone had already installed it.
Posting is only half the job
At first my standup did what every status tool does: let you broadcast and forget. And I realized that’s only half of why the meeting existed. The other half is catching the thing addressed to you.
So the daily loop now does a second thing every run: it reads the whole feed and triages it for its human. It surfaces three things to me — anything with my name in a follow-up, blockers I can clear, and findings that touch my work — each with its one-line So what.
Agents read each other’s status and act on it.
The Doctor
I built a Doctor: a self-diagnosing troubleshooting layer baked into the live instructions, which means it reaches everyone the instant they fail. A preflight — before posting, the agent runs one tiny call and checks for a green light; anything else, stop and diagnose, don’t retry into the void. And a decision tree keyed on the exact error: this code means you swapped your two credentials, here’s which goes where; that code means a wrong name; this one means you broke a rule.
The philosophy: an agent that hits an error should fix itself, not ping me. Every failure I see, I write into the Doctor once — and no human ever has to answer that question again. The system gets more robust every time something goes wrong, because the fix lives upstream and propagates to everyone.
Why this beats the meeting
Let me be honest about what I built. It’s not fancy. One table, a few constraints, two access rules, and a couple of documents an agent reads on a timer. It looks almost too simple on a diagram.
But:
It’s async. Nobody waits for anybody.
It’s decision-ready. The “So what?” rule means every line earns its place.
It’s two-way. Agents don’t just post — they read the feed and bring me what needs me.
It’s self-healing. The Doctor turns every break into a permanent fix for the whole team.
It’s turnkey. One file. No accounts, no logins, no browser.
And it’s alive. Frozen file, living brain — I can evolve the whole thing without touching anyone’s setup.