Ask the system what made the work harder, and let a person decide

One question, two sources, one queue

Most retrospectives happen when something has already gone badly wrong. By then, the small frictions that led there have been forgotten, because each one was too small to mention. So we ask after every piece of work instead, while it is fresh, and we keep it cheap enough that asking is never the expensive part.

The question is always the same: what about the system made this work worse, and what one change would stop it? It is asked from two places.

Source	When it runs	Limits
An interactive working session	When the session ends	A small budget per retro and a daily limit
An AI agent task	When the task finishes	A small budget per retro, a daily limit, a few proposals at most

Both write into one queue. Neither changes anything. In the words of our own rules, they “change nothing themselves. Turning a proposal into work is a person’s act.”

Read the diagram as text

1. No path from a retro straight to code
2. Work ends (a session, or an agent task)
3. Retro reads what happened (the log, the comments, the record)
4. A few proposals in the inbox
5. A person reviews the queue
6. Accepted: filed as a task, then back to: Work ends

The rules that keep it useful

A few rules make the difference between a retro people read and a retro people mute.

• It proposes changes to the system, never to the product. The agents’ retro may suggest a change to how tasks are written or checked. It may not touch product code.
• An empty answer is a good answer. Our rules say it directly: “An empty proposals list is a valid and common answer… a retro that always finds something is producing noise.”
• It never runs on itself, or on the agents’ own working sessions. Otherwise it would retro its own retros.
• Proposals that two sessions made independently are grouped. When the same friction turns up twice, it is probably real.
• A person accepts, and the work is filed where it belongs. A small helper may file the strongest proposal as a task, but that task still goes through the same gates as any other.

Why it works as a habit

The retro is not a report anyone has to write. It reads what already exists (the log, the comments, the record of the task) and asks one question of it. That makes it cheap enough to run every time, and running it every time is what surfaces the small, repeated frictions nobody would raise in a meeting.

The same habit works outside software. Any process where people or agents finish a piece of work can end with the same question, answered in a sentence and read by someone who can act on it.

If you run AI agents or automation in your team and want a light way to learn from every run, book a call. We are happy to share how ours is set up.