AI project status tracking that updates itself

A status dashboard is only ever as current as the last time someone remembered to update it. This workflow updates it when the underlying fact changes, not on a meeting schedule.

Status dashboards fail for a boring, structural reason: the update is a separate action from the work. Someone finishes a call, makes a decision, or hits a milestone, and then has to remember, later, to go open the dashboard and reflect it. Most of the time that second step does not happen, so the dashboard reports last month, confidently.

Status tracking that actually updates itself removes the second step. The status view is reconciled directly from the same project files everything else already writes to.

This is also why status meetings tend to run long: half the meeting is spent establishing what is true before anyone can discuss what to do about it. If the current state is already correct when the meeting starts, that first half disappears, and what is left is the actual conversation about what happens next.

What triggers it

Anything that changes a project's real state: a decision gets logged, a meeting note gets filed, a deliverable ships, a milestone is hit. No separate status-update step required.

What the system does

1. Watches for state-changing events

A new decision, a filed meeting note, a completed deliverable, each of these is itself a signal that a project's status line may need to change, caught the same way automatic meeting notes and the decision log workflow catch their own triggers.

2. Updates the one status line that project owns

Not a separate status document maintained in parallel and prone to drifting out of sync, but the project's own current-state line, updated in place.

3. Reconciles every project into one view on request

When you want the whole picture, all project status lines get pulled together into a single current view, rather than you opening each project file individually.

4. Flags contradictions instead of hiding them

If a project's status line and its underlying decision log disagree, the workflow surfaces that instead of silently trusting whichever was updated last.

A concrete case: a project's status line says "waiting on legal review" for three weeks. In a manually updated dashboard, that line just sits there until someone remembers to change it, whether or not it is still true. In this workflow, the moment legal review actually finishes and gets logged, whether that is a decision, a filed email, or a meeting note, the status line updates in the same pass. Nobody had to remember the dashboard existed.

What lands in front of you

A current status line per project, reconciled from the actual work rather than a manual update, and, when you ask for it, one combined view across every active project.

What you still decide

Whether a status change the system flagged is actually significant enough to note, and how to resolve any contradiction it surfaces between what a project's status says and what its own record shows. On a project with several people touching it, that contradiction check is often the most useful thing the workflow does, because it catches drift before it becomes a surprise in a meeting.

Where this fits for founders and anyone running several things at once

This is the workflow behind the weekly review and the reason a review can take ten minutes instead of an hour: the status is already current when you sit down. It matters most for founders running several ventures at once and for anyone whose job is knowing where ten things stand without asking ten people.

It is also the difference between reporting status and having it. Reporting status is a task someone has to remember to do, on top of the actual work. Having current status is a property of the system, true whether or not anyone was thinking about reporting that day. The second version is the only one that survives a busy month, which is exactly when accurate status matters most and is least likely to get manually updated. That is exactly the gap engineering managers feel first, since their status view usually depends on the fewest people remembering to update it.