Keep a decision log, not a status update

The board is green. Every card says done. Made-up case, to keep it concrete: last week the team picked polling over webhooks for a sync job, ran the work through an agent, and closed the ticket. Today a new agent session opens the same board, sees green, and starts drafting a webhook redesign because the codebase "looks unfinished" without one. Nobody left a note saying polling was a deliberate choice. Status said the work finished. It never said why that path won.

This is an opinion piece about running work where agents produce updates, and here's my claim. I think when agents do part of the work, the record that matters is why a choice was made, not a checked-off status line. Status says what moved. A decision log says what was picked, what was left out, and who owns the call. That is what the next person, or the next agent, needs.

Why status fails when agents are in the loop

Status is good at answering "did this step finish?" It is bad at answering "why did we do it this way?"

I think that gap gets worse with agents in the loop. An agent can mark a step done without carrying the reason the path was chosen. It completes the checklist it was given. It does not automatically write down that option B lost because of a rate limit, or that webhooks were deferred on purpose. The board turns green. The reason evaporates.

Between people, hallway memory sometimes fills that hole. Someone remembers the debate. With agents, the next session often has none of that memory. It reads the green board, the code, and the open tickets, and it reasonably treats a missing webhook as unfinished work rather than a rejected option. Status invited that misread. Nothing on the board said "we chose not to."

We've been watching this pattern on our own work. The updates that look healthiest are often the ones that hide the most. A full row of dones feels like progress. It can also mean the team is about to re-argue last week's call with no record of who decided what.

There is a quieter failure mode too. Status invites people to reopen settled questions because the board looks empty of reasoning. Someone asks "why aren't we on webhooks?" The honest answer lives in a meeting nobody recorded. The agent, asked the same question in a new session, does not even know the question was settled. It treats the absence of webhooks as a gap to fill. I think that is how green boards quietly undo themselves.

What a decision log holds

A decision log is not a second project plan. It is a short list of calls that later readers should not have to reconstruct.

Each entry can be four lines:

The choice. What we picked. "Use polling for the sync job."

The options rejected. What we left on the table. "Webhooks deferred. Not building a push path in this change."

The constraint that mattered. The one reason that settled it. "Partner API has no reliable push and retries are expensive on our side."

The owner. Who owns the call if someone wants to reopen it. A name, not a channel.

I think that is enough. You do not need an essay. You need a place where "why" is written once, in public to the team, before the next session starts inventing a different why.

The format matters less than the habit. A section at the top of the plan, a short file next to the board, or a dated note in the ticket all work if people actually read them. What fails is relying on status alone and hoping the next reader will reconstruct the debate from the diff.

A made-up pair of entries, labelled as example only:

• Choice: polling every five minutes for partner sync. Rejected: webhooks in this release. Constraint: partner has no durable push. Owner: the lead on the sync work.
• Choice: no backfill of old orders into the new receipt mailer. Rejected: historical send. Constraint: legal review not done. Owner: the PM on billing mail.

Two blocks. Either one stops an agent from "helpfully" building the thing you already decided against.

How it gets used

The next human reads the log before changing course. If they want webhooks after all, they reopen the decision with the owner, they do not quietly start a new ticket that pretends the old call never happened.

The next agent session starts from the decision, not from a green checkbox. Put the relevant entries in the brief. "Polling is intentional. Do not add webhooks." That sentence is cheaper than a long cleanup after the agent invents a push path.

I think status and the decision log answer different questions, so both can exist. Keep the board for what moved. Keep the log for what was chosen. When the two disagree, trust the log for intent and fix the board afterward.

What I would avoid is treating the decision log as a diary of every thought. If everything is a decision, nothing is. Log the calls that another person or another agent might reverse by accident: scope cuts, deferred options, constraints that are easy to forget, ownership of the call.

Writing the entry is part of making the call, not homework after. If the decision is real enough to send an agent to work, it is real enough for four lines. If you cannot name the rejected options or the constraint, you may not have decided yet. In that case the log is a useful brake: finish the call before you start the run.

Keep the why

Here's the reframe I'd leave you with. We often treat a green board as proof the team is aligned. With agents writing steps and marking them done, green only proves the checklist moved. It does not prove anyone still knows why.

I think the durable record is the why. Write the choice, the rejected options, the constraint, and the owner. Keep that next to the work, not in someone's head. Status can stay. Just don't let it be the only thing the next session reads.

Written by the team building Gander, live review for markdown an agent is still writing.