Nine people joined the weekly status meeting. The first ten minutes disappeared while everyone arrived. The next twenty-five were spent repeating information that already existed in project tools, messages, and documents. Seventeen minutes produced the one useful discovery: a real blocker. The final eight minutes became a debate about ownership and a promise to schedule another conversation.
Then the follow-up became somebody else’s job.
That hour is the starting point for Zero Status. I have the model. I have not run the live test yet. I am publishing it now because saying “I am building this” creates an obligation to show the work, including what is incomplete.
The basic cost is easy to see. Nine people multiplied by one hour at an illustrative compensation cost of $46.60 per hour is $419.40 for one meeting. Across fifty working weeks, that becomes $20,970. The estimate does not include preparation, follow-up, context switching, delayed decisions, or the cost of discovering a blocker six days after it first became visible.
The larger cost is harder to calculate. Every person has to reconstruct the state of the work before the meeting can begin. People arrive with different evidence, different definitions of progress, and different ideas about who owns the next decision. The meeting becomes a temporary operating system built out of memory and conversation. When it ends, much of that operating system disappears again.
The replacement is not a better meeting
Zero Status starts from a narrower question: what information and decisions did the meeting exist to produce?
The proposed operator collects changes from the systems where the work already lives. It verifies claims against project records instead of treating every update as equally reliable. It looks for contradictions, risks, stalled work, and missing owners. When a real decision is needed, it routes that decision to the person with authority. Then it records the decision, the owner, the deadline, and the evidence that supported it.
The intended output is not another dashboard. It is a finished update. The reader should be able to see what moved, what is blocked, what changed since the last report, and whether one decision needs human attention. If there is no decision, the system should not manufacture urgency to justify its own existence.
A sample result might say that a campaign launch is at risk because the landing-page copy and tracking links are complete while the final video is still waiting on product footage. The only decision is whether to launch Thursday without video or move the complete launch to Friday. One accountable person receives that decision. Everyone else gets the recorded outcome.
This model overlaps directly with work already underway in Calm Operator. That system is designed around context reconstruction, decision detection, commitment detection, ownership reconstruction, and attention routing inside Slack. Zero Status is the meeting-replacement expression of the same underlying idea: software should reconstruct the work so people do not have to keep reconstructing it for one another.
Some of the surrounding machinery already exists. The workflow can distinguish decisions from discussion, commitments from vague intentions, owners from participants, and confirmed facts from inference. What does not exist yet is a completed evaluation across a varied set of worked examples. That distinction matters. A working component is evidence of progress, but it is not evidence that the full replacement works.
There are boundaries. The operator should not infer motive, invent an owner, or turn message history into employee surveillance. It should distinguish confirmed facts from inference and uncertainty. It should preserve the source behind every material claim. A human remains responsible for decisions involving authority, sensitive judgment, or consequences the system cannot reverse.
What I still owe
The next step is to put Zero Status through a set of worked examples. Each one should represent a different reason companies hold status meetings in the first place: a week where everything is moving normally, a blocker hidden inside an otherwise positive update, two sources that disagree, work with no clear owner, and a decision waiting on someone with authority.
One example might show a campaign that looks on schedule until the system notices that the final video still has no approved footage. Another might show three people discussing the same deliverable without anyone explicitly accepting ownership. A third might show the project tracker saying “complete” while a newer message says the work needs another revision. The point is to show what evidence Zero Status receives, what it concludes, what it refuses to conclude, and what it sends to a human.
The examples need failure criteria too. If the operator invents an owner, treats an old update as current, hides conflicting evidence, or turns uncertainty into a confident answer, the example fails. It also fails if a human has to do so much preparation and correction that holding the meeting would have been easier.
Worked examples will not prove that Zero Status can replace a live meeting. They will show whether the operating logic deserves to move forward. They should expose where the model is useful, where it becomes unreliable, and which decisions still depend on context that the system cannot see.
Publishing those examples matters because a diagram can make almost any idea look finished. The harder test is showing the same system handle different situations without quietly changing the rules each time. If an example breaks the model, that failure becomes the next installment instead of something edited out of the story.
The useful parts will stay public: the scenario, the available evidence, the resulting update, the mistake, and the rule I changed afterward. The complete prompts, internal routing, production configuration, and implementation details will remain private. The reader gets enough to understand the method and judge the result without receiving the entire machine.
The model is the easy part. Next I have to show Zero Status working through situations where the answer is not obvious. I will publish the useful outputs, the unsupported conclusions, and the examples that force me to change the system.
I do not want AI attending the meeting. I want it to remove the conditions that made the meeting necessary.
Yours in unnecessary meetings,
Z