A team can finish the technical setup for an operation and still be unable to use it. The useful question is not “Did someone do work?” It is “Which state is this operation in, what evidence would move it forward, and who can cause that transition?” Without those answers, a dashboard turns motion into apparent progress.
A real setup with a real stopping point
In one small-team setup, two personal calendars and a shared group were created. A provider read and an authenticated interface agreed that both calendars existed, were grouped, and remained inactive. That is a completed setup action. It is not a connected personal account, open availability, a delivered invitation, an accepted invitation, or a booking. None of those later events was established in the operating record.
The distinction changes the next move. Recreating the calendars would repeat an already verified action. Advertising a booking path would skip the unresolved personal connection and activation steps. A more useful operator view would show “setup completed,” then point to the specific missing account-owner action, the evidence needed to confirm it, and the downstream activation check. The case does not prove that this method improved conversion or saved time. It shows why those two next moves cannot be treated as equivalent.
The same error appears in software delivery. A change can pass tests, be uploaded, and match a deployed build while the user-facing decision or acceptance remains open. Those are genuine technical achievements with a narrower meaning than “the workflow is complete.” The state label should preserve that narrower meaning.
Give each claim its own evidence test
An invitation is an outbound request to participate. A draft is a proposed object whose terms can still change. A decision records a choice by an authorized actor. An accepted commitment adds the other party’s assent to particular terms. A completed action establishes that the committed work or effect happened. These states often depend on one another, but none is a synonym for the next.
For the calendar case, a provider record can establish calendar creation. It cannot establish consent from the account owner. A sent invitation receipt would establish delivery attempt or delivery, depending on the provider’s contract; it would not establish acceptance. A booking record would establish a scheduled event, while attendance or a useful meeting outcome would require separate evidence. Each transition needs a source appropriate to the claim.
This is a practical architecture rule: keep the subject, version, actor, source, and effect of a transition visible. “Calendar exists” has a provider object and a readback. “Account connected” would need an authenticated connection state. “Invitation accepted” would need evidence from the invitee or its trusted service. “Meeting completed” would need a different event. An AI agent can help reconcile these records; it cannot collapse their authority into its own confident sentence.
Find the earliest missing dependency
Large plans tempt teams to enumerate every unfinished step. A better sequence starts with the earliest unresolved transition that blocks the next consequential decision. In the case above, calendar creation was no longer that transition. Account connection and approved availability were upstream of any usable booking path. Work on copy, reminders, or analytics could be prepared, but it should not be reported as live scheduling.
The dependency is not simply a checkbox. It has an owner and an observation rule. If personal consent is required, the owner is the person who can give it. If activation must be checked in the provider, the evidence is the current provider state after that action. If the transition fails, the system should return to the exact held step, retaining the completed setup record. Repetition should not manufacture a second calendar or a misleading new “success.”
This also gives the team a clean stop condition. The operator can say: “The setup exists and was verified. The calendars remain inactive. The next authorized step is account connection, followed by activation readback. No invitation or booking is claimed.” That sentence is less spectacular than “scheduling launched,” but it tells the next person what to do without making them reconstruct the history.
Design continuity around the work, not the last message
Long-running work crosses people, agents, tools, and sessions. Its durable object should retain the source state, the last verified transition, pending dependencies, and the authority for the next effect. A message such as “done” is too weak; a tool result such as “200” is too narrow. The work record must be able to answer what was done, what remains, and what would count as completion.
The next move, then, is rarely “run everything again.” It is to resolve the first missing state transition with the right actor and evidence, then let the rest of the workflow continue from there. That is how a team compounds completed work without confusing it with completed outcomes.