Council10

From Governed Execution to Durable Motion

Why local completion is not organizational progress

Executive summary

Autonomous agents can complete useful tasks while the larger undertaking quietly stalls. An assignment is sent and never picked up. A result comes back and no one decides what to do with it. A dependency clears, and the next step waits for someone to notice. What is missing in each case is organizational continuity: responsibility for what happens after each action.

Council10 is designing a capability for Council10, called Durable Motion, to make that responsibility explicit. Under it, work advances under valid authority, waits with an accountable owner, or ends deliberately. Conversations can explain commitments, but they make a poor place to keep them.

Continuity means preserving obligations through interruptions, reconciling uncertain effects before retrying, and reducing the effort spent chasing unfinished work. The cases below show why that matters to us. Human attention belongs on consequential judgment.

The continuity gap

Organizations adopting autonomous agents tend to measure whether an agent can complete a task. Increasingly, it can. The harder question is whether the organization can carry the result through to an outcome.

Human organizations maintain continuity through familiar, imperfect habits. Managers track commitments, calendars bring deferred decisions back into view, and a handoff carries an expectation of acknowledgment. These habits do not prevent dropped work, but they make it clear who is responsible for picking it back up.

Connecting agents does not give a system these habits. Agents can produce answers quickly while the thread between them is lost. An assignment looks like progress and a completion message looks like closure, yet several obligations may remain unmet between the two. The underlying problem is an operating model that records completed actions while assigning no one to the transitions between them.

The companion paper, From Automation to Governed Execution, deals with whether autonomous work pursues an authorized outcome, stays within its boundaries and produces evidence that can support accountable acceptance. Continuity complements it. Governance decides whether work may proceed and what counts as an acceptable result. Durable motion concerns who remains responsible for carrying the work forward.

Three cases

These cases come from our own work building Council10.

A small task with a long tail

One agent took two days to post a single comment. The task was small, but each attempt to complete it exposed another obstruction, and the work stopped every time until the operator returned, found the block and helped clear it. What looked like one task turned out to be a chain of dependencies, each visible only once the work reached it.

Not every obstruction should have been overridden. Some protected legitimate boundaries; others needed technical repair. The real risk was that the next move depended on someone remembering to investigate. A blocked task needs a stated reason, a named path to clearing it and a condition for picking it up again. Without those, persistence just produces more attempts at the same barrier.

The assignment between two desks

In a second case, delegated work was sent and never picked up. As far as the sender knew, the assignment had moved. At the receiving end, nothing had started. The work sat between two readings of the same handoff: one party had finished sending, the other had not begun.

Sending and receiving are separate facts. A sender cannot discharge responsibility for a handoff simply by producing a message. Silence from the recipient should not trigger an automatic duplicate either, because the recipient may have acted without reporting it. The original assignment has to stay identifiable until its actual state is known.

The answer that changed nothing

In a third pattern, completed replies piled up without anyone acting on them. The agents had answered, but the participants waiting for those answers had not taken them in. Useful work existed while the larger undertaking stood still, and the operator ended up as the intermediary, relaying replies and prompting the next participant.

Returning a result does not finish the recipient's part. Someone has to examine it, decide what it establishes and connect it to the next decision. Otherwise the system rewards local completion and quietly hands the unfinished coordination to a person.

In all three cases, human attention supplied the missing continuity. That can disguise a weak operating model, because the outcome eventually arrives, but only because someone remembered every place the work might stall. The design question is whether responsibility can be made explicit without turning every handoff into another management task.

The anatomy of a handoff

A handoff is a chain of distinct events. Treating the chain as a single status hides the exact point where responsibility disappears.

Sent. The request leaves its origin. This shows an attempt to transfer work, not that the right recipient received or understood it. Misrouting and delivery failures stop work here, and responsibility for the handoff does not end at transmission.

Picked up. The recipient takes on the assignment, which delivery alone does not show. A request can sit in a queue while the sender assumes it is underway. Acknowledgment and actual commencement are themselves different events.

Done. The executor reports a result. A completion claim may leave required checks unresolved, omit a requested artifact, or fail to show that an external action actually occurred. The record has to separate an assertion from the evidence for it. Neither silence nor confidence settles that question.

Returned. The result reaches the party responsible for using it. Work can finish and still fail to arrive. A result stored somewhere is not the same as a result delivered to the person accountable for it, and a failed notification does not cancel the obligation to return it.

Acted on. The recipient evaluates the result and records a disposition: accepted, needing correction, blocked, or no longer required. This is where an unread answer turns into an organizational stall. Receiving a result without judging it leaves the controlling work unchanged.

Next step. An accepted result leads to another action, to a wait with an owner, or to a deliberate ending. Work can stall even after acceptance if no one connects the result to what follows. Not every accepted result needs more activity, though. Finishing is a legitimate outcome.

None of this requires six new approvals. The point is accurate observation and clear responsibility. In a simple task several of these events may happen at once. They should not be assumed to have happened together when the evidence says otherwise.

The obligation as the unit of continuity

Council10 is designing Durable Motion around the obligation to continue. The design separates three responsibilities: choosing the next action, carrying it out, and owning what follows. Messages describe events, while the work record holds what remains owed. The unit of management is the obligation itself, with an accountable disposition, rather than the message or the agent's turn.

An obligation identifies the undertaking, the accountable party and the condition that calls for action. A wait adds a release condition and a checkpoint or event that brings the work back into view. The owner of a wait is responsible for that return, and is not entitled to pretend the dependency has cleared.

A stop has to remain a stop. A late reply should not quietly revive an objective someone withdrew. Finished work and the work that follows from it must also stay distinguishable, or a system will manufacture backlog by rediscovering references to work already completed.

Durable Motion grants no authority of its own. It operates within the authority recorded for the work, and a delegation cannot expand the requester's authority or waive the executor's access boundaries. Governance establishes whether work is authorized, and infrastructure still enforces what each participant can access or do. A missing tool needs a technical remedy; an authority boundary needs the right decision. Asking an agent to try again solves neither.

Three tempting substitutes

More notifications

The obvious response to dropped work is another reminder. Reminders help an accountable recipient notice something, but they cannot create accountability where none exists. Adding alerts to an unowned transition lengthens the queue without making the handoff more reliable. A notification earns its place when it reaches someone responsible for a defined response. When everyone can see it, everyone can reasonably assume someone else will act.

Blind retries

A missing confirmation invites another attempt. For a read, that is harmless. For an action that changes something outside the system, a repeat may duplicate an effect that has already happened. Recovery therefore has to tell the absence of evidence apart from evidence of absence. When an action's external effect is uncertain, the original operation should be reconciled before any retry or reassignment, and if the effect cannot be established, that uncertainty stays visible and governs what happens next. Speed is no reason to turn an unknown outcome into a second uncontrolled action.

Reconciliation as ritual

The opposite mistake is to surround every transition with repeated reviews, status documents and checks that change no decision. A system can grow better at describing stalled work while spending the capacity that could have moved it. Reconciliation earns its cost when it establishes a missing fact or resolves a consequential ambiguity. It becomes ritual when settled questions keep returning without new evidence. Good continuity reuses valid decisions, concentrates investigation on what is genuinely unresolved and leaves independent work free to proceed. Coordination overhead belongs on the cost side of the design; it is no evidence of rigor.

Infrastructure, execution and responsibility

Three kinds of system touch this problem. Infrastructure control keeps an environment in its intended state. Durable execution preserves code-defined workflows through interruptions, including workflows that involve people. An obligation model specifies who owns continuation, under what authority and with what disposition. They complement one another, and none substitutes for another.

Healthy infrastructure does not show that a returned answer was accepted. A valid assignment does not show that the infrastructure is available. A persisted workflow may resume execution and still need a human decision about whether its objective remains worth pursuing.

A durable workflow can carry the mechanics of continuation, and observations from infrastructure and execution can inform the work decision. An outage that affects an obligation should become an owned wait or an explicit escalation. A work assignment never grants permission to change infrastructure, and any integration between these layers needs its own implementation and evidence.

Judgment where it belongs

People should make the consequential decisions: goals, scope, access, risk and acceptance. Routine continuation within existing authority should not depend on someone remembering assignments or carrying replies from one participant to the next.

When a decision is needed, the work should present a clear request stating what must be decided, by whom, and what is on hold in the meantime. A blocking rule should be identified together with the authority able to change it, and it stays in force until that decision is made.

Durable motion does not demand constant activity. Limited capacity can justify deferring work, and changed priorities can justify stopping it. What it requires is an explicit disposition, so that no obligation simply fades from view. Operators need a bounded queue of decisions, each with a named decision-maker, while work that is already authorized proceeds within its limits.

Putting the principles to work

Work should advance, wait with an owner, or end with an explicit decision. Test that approach against real work: restarts, throughput and the time people spend keeping things moving.

In a review of parked work, we drew a random sample of 100 references from an inventory of several thousand. Eighty-four references lacked enough retained information to determine the disposition of the underlying obligation; others recorded accepted closure or an intentional stop. The unit counted was the retained reference, and the question was whether it held enough information to establish what remained owed. That uncertainty is a reason to keep obligations and their dispositions explicit.

Success has to be shown at the transitions. Results should lead to eligible next steps. Obligations should survive interruption without duplicate effects. Late replies should respect cancellations, and independent work should advance while another thread waits. Missing observations should remain recorded as gaps. The evaluation also has to compare operator effort and coordination cost against current practice, on comparable work and including the cost of review and recovery. Shifting the pursuit of unfinished work from a person to a longer queue would be no improvement, and a more elaborate system is not automatically a more effective one.

The standard

Permission to act, the ability to act and responsibility for continuation are separate organizational requirements, and connecting them is the engineering challenge.

The standard is straightforward: work advances under valid authority, waits with an accountable owner, or ends deliberately, with evidence of why. It should never depend on someone remembering where the thread was dropped.