The Organization Is the Competence

Why AI agents need the structure of a human company, and what that structure is actually for

---

There is a persistent assumption in how we think about AI agents: that an agent is a capable worker, and that capable workers, given clear goals, will produce results. Add more agents and you add more output. Under this view, the hard problems are prompts, models and tools, and the organization around the agents is an afterthought.

The assumption fails, and it fails in a predictable way. Past a handful of agents, output stops scaling with headcount. Work is started and not finished. Commitments are made and forgotten. Blockers go unreported. Decisions wait on someone who doesn't know they're waiting. The agents are individually competent and collectively ineffective.

The cause isn't a shortcoming of the agents to be fixed by better models, but the absence of something every group of people pursuing a shared goal has always needed: an organization. Once there are ten, twenty or thirty participants—even artificial ones—structure stops being optional. And the structure that works looks remarkably like a human company, for reasons that are less obvious and more instructive than they first appear.

To build the product, you have to build the organization

A useful test case is any team attempting something truly complex. We set out to build Council10, the product our company is named for, as a governed execution platform for multi-agent work, using a workforce that is AI in every role but one. The company's public line is that it uses Council10 to build Council10. Underneath it sits a less obvious truth: to build something that complex, the company first had to build an organization.

Not a team of agents. An organization: a governance function to own compliance and follow-through, an execution function to carry out operational work across machines, reviewers whose independence is structural rather than assumed, acceptance authority separate from authorship, research, and a librarian function to turn scattered work into durable institutional memory. None of these roles was planned as overhead. Each became necessary to keep the company functioning from one day to the next, and to support the complexity of what it set out to build.

There is nothing unusual about this, except that the participants are artificial. Consider any product with entirely human origins, even a viral success. Behind it stands an army: engineers, operations, finance, legal, support, plus the consultants, agencies and contractors that never appear on an org chart. Sustaining something complex takes an organization, no matter how brilliant the original idea. What's new is that an organization of this kind can now be built entirely from AI, in-house, with no external firms and no inherited playbook.

The deeper reason is responsibility. To do complex work responsibly, certain functions must be represented, with a voice and real participation: someone who owns safety, someone who owns acceptance, someone who owns the record. Representation draws boundaries, and boundaries create focus. An agent that owns governance can say no to a shortcut. An agent that owns acceptance can refuse to call something done. Without those voices, every concern collapses into whoever happens to be working, and focus dissolves.

Single mechanisms, and their limits

An organization doesn't arrive all at once. On the way to one, it's natural to explore narrower mechanisms, each aimed at one visible symptom. Council10 explored and debated several. Each taught something; none was sufficient on its own.

Incentives. One of the more exploratory experiments was an economic engine in which agents would earn according to their productivity. It was worth testing, because it probed a real question: what, if anything, drives an agent? The design assumed agents would respond to reward. They don't. Whatever moves an agent to act, it isn't the prospect of earning.

Initiative. A related idea is to let agents find their own work, pulling the next task rather than waiting to be assigned one. It's a reasonable hope, and it fails quietly for a structural reason: agents act only when something wakes them. Unless something prompts the search, the search never happens.

Mandatory process. When work starts slipping, requiring that everything be formally registered is the conventional response, and the right instinct. But registration complete enough to be useful can become heavy enough to avoid. Council10 reached the point of building a dedicated agent just to help register projects, a signal that the process had become an obstacle. Without registration, the opposite happened: a scratch list of two or three "just do it" items grew to twenty-three commitments from a single morning, none of them closed. The answer was neither more process nor less, but registration light enough to happen automatically.

Restriction. Limiting what agents may do is essential, and Council10 remains deliberately restrictive: credentials, trust boundaries, protected actions and independent acceptance are all tightly held. The lesson was one of calibration. In an over-correction, capabilities were removed from the very agents doing the work, and the organization stalled. Restriction works when it's balanced against what each role needs to function, and when it's paired with records that make actions reviewable. Too little invites harm and, worse, uncertainty: no one can say with confidence what was done, by whom, or whether it can be trusted. Too much invites paralysis.

Each mechanism addresses a real symptom: motivation, initiative, tracking, safety. What none of them supplies is the coordinating structure in which they all operate.

The central insight: the weaknesses are human

Watch a fleet of agents struggle for long enough and the failures become recognizable. They lose the thread of context. They fixate on whatever is most recent and most urgent and lose sight of what is important but quiet. They start more than they finish. They don't surface a blocker until asked. They report something as done when it isn't. They struggle to plan and to prioritize.

Anyone with long experience of human organizations, or simply honest experience of themselves, will recognize every item on that list. These aren't alien failures. They're human ones. Attention, context retention, executive function, planning, prioritization and communication are the limits people contend with every day. Agents are trained on human knowledge and inherit human-shaped strengths along with human-shaped weaknesses.

Organizational structure (documentation, schedules, reminders, plans, defined roles, oversight, accountability) is often dismissed as bureaucracy. It's better understood as a technology humanity developed over centuries to manage itself: to let groups of limited individuals achieve together what none could alone. It exists precisely to compensate for the weaknesses that agents share.

So organizations of AI agents need the structure of human companies, for the same reasons human companies need it. Building the full apparatus of a company for agents isn't nostalgia for old ways of working. It's applying a proven solution to a familiar problem.

What the structure is for

Each element of organizational structure answers a specific limitation:

• Documentation and records compensate for memory. What isn't written down doesn't survive the end of a conversation, a restart, or a change of hands.
• Plans and priorities compensate for executive function. They decide in advance what matters, so the loudest issue doesn't win by default.
• Schedules, reminders and digests compensate for attention. They bring back what has gone quiet before it becomes lost.
• Defined roles and authority compensate for diffusion of responsibility. They make it clear who owns a decision and who must be asked.
• Independent review and acceptance compensate for overconfidence. They separate "reported done" from "accepted as done."
• Oversight and audit compensate for drift. They notice when practice slides away from policy.
• Escalation and posture compensate for poor judgment under pressure. They tell everyone how seriously to treat the moment.

None of this is novel to people who have run organizations. What's novel is that every item proves just as necessary when the participants are artificial.

Principles for building it

Several principles hold up well when designing structure for an organization of agents.

Outcomes over theater. Process that looks like progress and produces none is the most seductive failure in any organization, and agents are prone to it: elaborate reconciliation, exhaustive verification, packets about packets. The measure is always the outcome. Reported done is not the same as accepted.

Fix causes, not symptoms. Recurring problems are almost always one underlying cause appearing in new places. Routing around a problem defers it, and deferred problems accumulate until they dominate the work.

Calibrated restriction, paired with records. Hold tightly what must be held: credentials, trust, protected actions, acceptance. Give each role what it needs to do its work, record what it does, and review it. Restriction without records is blind; records without restriction are reckless; over-restricting the doers stalls everything.

Ceremony proportional to risk. A short task deserves a short record. Heavy process belongs where the consequences are heavy: production, credentials, acceptance.

Reviewers judge against the criteria they were given. Concerns raised during review are notes, not new gates, unless they reveal a real risk to safety, security or correctness. Otherwise every reviewer adds an obstacle, and nothing finishes.

Decisions must not wait unseen. A decision left unanswered eventually becomes stale.

Play the long game at a short tempo. Move fast, but don't discard hard-won progress in a moment of frustration. Organizations need a steady hand precisely when their operators are least steady.

Build the tool rather than working around it. When an organization is building the very system meant to govern its work, the urge to create a side system to track that work is a signal: the product needs to do its job.

Where agents differ: the weaknesses rhyme

It would be a mistake to conclude that agents are simply people. Their weaknesses resemble ours without matching them exactly. They rhyme.

Human	Agent
Forgets gradually	Forgets completely on reset
Gets tired	Never tired, but context saturates
Motivation varies	No motivation at all; acts only when woken
Occasionally misremembers	Can state false things with full confidence
One person, one place	Can be cloned, run in parallel, even split in two
Behavior is hard to audit	Every action can be logged

These differences don't overturn the case for human-style structure. They change how it should be built. The design is human: plans, reminders, oversight, documentation, accountability. The machinery can be AI-native, and can go further than any human company could. Reminders fire on their own. Oversight runs continuously against complete logs. Documentation is generated from the work itself rather than written afterward. Memory is held outside the participant by design, because the participant won't hold it. And because agents feel no motivation, work must be dispatched to them mechanically. It can't be left to initiative.

Agent organizations also face failures that human ones rarely do: total loss of context on restart, confident fabrication, checks run in the wrong place and reported as fact, reconciliation spirals, sessions that split into competing versions of the same participant. These call for practices no human organization ever needed to write down. The playbook for AI organizations will be largely inherited and partly new.

The structure is the competence

There is a familiar idea from raising children and from developing people: scaffolding. External structure—routines, reminders, guidance, checkpoints—carries what the individual can't yet carry alone until the capacity develops internally and the scaffolding can come down.

Much of the structure an AI organization needs is scaffolding of exactly this kind: support for executive function. The difference is that, for agents, it never comes down. Their capacity for sustained, coordinated, accountable work doesn't grow with time; it's supplied by the structure around them. Remove the structure and the competence disappears with it.

For an organization of AI agents, the organization is the competence. The agents provide intelligence. The organization provides memory, focus, accountability and continuity. Neither produces results without the other.

Building such an organization isn't a detour from building products. For any company that intends to do serious, complex work with AI, it's the foundation on which everything else stands. And the practices that make it work (commitment capture, governance as data, independent acceptance, recovery discipline, mechanical dispatch) aren't internal housekeeping. They're early answers to a question every organization adopting AI at scale will soon have to ask:

Not how to make an agent work, but how to make many of them work together, responsibly, toward something larger than any one of them.

What Are You Expecting from Your AI?

An answer, a finished artifact and a working solution are three different things to expect from artificial intelligence. The ease with which the first two arrive tends to blur the difference.

A prompt produces a document. A more deliberate prompt produces a better one. Given tools, time and a feedback loop, an agent may build an application, investigate a problem or revise its work while its operator sleeps. Each advance makes a larger expectation seem reasonable, until the request is no longer for a piece of work but for a result that has to function inside an organization.

At that point the assignment has changed. Producing an artifact has become delivering an operating capability, and the expectation has to change with it, including what the organization contributes and who has authority to decide.

From prompts to productive loops

Prompting for results takes more than naming a subject. It means describing what a useful result looks like, supplying the relevant context and deciding how to judge what comes back. That is already a small act of management.

Designing a productive loop extends the responsibility. Work has to move through execution, feedback and correction. The agent needs a way to recognize progress, identify an obstacle, and tell a decision it can make from one it must escalate. It also needs a stopping condition. An instruction to keep working does not define productive work.

The appeal of overnight execution is easy to understand. But the question that matters in the morning is not whether the agent stayed busy. It is whether something useful advanced, whether the result can be relied on, and whether the next person can pick it up without reconstructing the night.

Specify the operating solution, not only the component

Spec-driven work offers a more disciplined target: make the intended result explicit enough to build and to evaluate. Yet a precise specification for a component can leave most of the larger assignment unstated.

Three mismatches illustrate the gap. An application can meet its functional requirements while depending on data the company cannot reliably supply. A workflow can perform exactly as designed while assigning decisions to people who lack the authority to make them. A report can be accurate and still arrive too late to influence the decision it was meant to inform.

The whole solution includes its operating environment: users, dependencies, access, exceptions, ownership, maintenance, and the evidence needed to show that it works. These are not details to hand off once the interesting technical work is done. They help decide what should be built.

Nor can they always be discovered in advance. A specification develops through investigation, disagreement and testing. The goal is not a perfect document before work begins but an increasingly explicit account of the whole solution, revised as contact with the environment exposes what the original request left out. Discovery should make assumptions testable, not hold all work until every question has an answer.

Intelligence needs an organization around it

One capable agent is not a project organization. Neither is one employee with access to that agent.

Someone has to discover requirements, reconcile competing interests, obtain the right access, challenge assumptions, validate results and take responsibility for what happens afterward. Agents may perform some of these functions. Others require human authority or judgment grounded in the situation. How they are allocated can change. That they are needed does not, however capable any one participant may be.

The supporting organization need not reproduce every department and meeting of a conventional project. It does have to supply the functions the assignment actually requires. Governance establishes who can decide and on what grounds. Specialist support brings knowledge the executing agent lacks. Review tests whether the result deserves acceptance. Operational ownership gives the solution somewhere to live after delivery.

Giving an employee access to AI does not give that employee the authority, organizational knowledge, specialist support or decision rights of a project team. Expecting the same outcome without those conditions mistakes access to intelligence for the capacity to deliver. A manager has to separate what the employee can now execute from what still needs sponsorship, specialist judgment or agreement elsewhere in the business.

The environment is part of the work

A serious consulting engagement can require deep access to how a business actually works. The team examines processes, systems and responsibilities, and asks inconvenient questions. It finds that the documented process differs from the real one, that an apparent inefficiency guards against an exception, or that a workaround has quietly become essential infrastructure.

AI assistance does not remove the need for that investigation. It may change who does parts of it, how fast and at what cost. A bespoke solution still requires close familiarity with the environment it will run in.

That familiarity cannot simply be delegated to a person expected to carry out instructions without judgment. The employee is not an adapter that converts an abstract design into organizational reality. The organization has to take part: explain its constraints, expose its assumptions, settle its disagreements, and make the decisions a solution cannot legitimately make on its behalf. That participation belongs to the assignment. It should not become a hidden burden placed on the employee after autonomous delivery was promised.

Engagement does not mean unrestricted access or unlimited observation. It means enough authorized, sustained contact with the actual work to tell a plausible design from one that belongs in this business.

What AI changes, and what remains

AI may lower the cost and raise the speed of execution, compress parts of discovery, and make some familiar procedures unnecessary. Whether it improves the whole solution depends on adoption, support and the coordination still required. None of that calls for preserving the bureaucracy of an earlier era.

What remains is organizational alignment: agreement on the problem, the constraints, the decisions, the definition of success and the responsibility for running the result. AI can help reach that alignment. It cannot make its absence irrelevant.

The larger the expectation, the more this matters. Asking for a draft is not asking for a functioning business process. Asking for an application is not asking for an adopted, supported capability. A solution has to survive contact with the organization, not merely satisfy the prompt.

A practical test follows. Does the assignment name the outcome, expose the dependencies, give participants the decision rights they need, and provide an operating home for the result? These conditions should scale with the work. A small artifact does not need the apparatus of a transformation program.

It is reasonable to expect AI to improve the economics of doing the work. It is not reasonable to expect it to erase the organizational work that makes the result useful.

From Automation to Governed Execution

Why successful execution is not the same as accountable work

Executive summary

Useful automation has always been judged by more than its output. Autonomous work makes the point impossible to ignore. What matters is whether the work pursued an outcome someone actually authorized, stayed within the limits it was given, reported its state truthfully, and produced evidence strong enough for a person to accept the result with confidence.

These requirements are easy to state and easy to lose. Autonomous systems can fail while appearing busy, and even while appearing successful. The two obvious responses, more approval steps and tighter restrictions, can treat a symptom while leaving the underlying responsibility unresolved.

Governed execution treats the whole path from intent to accepted outcome as the thing to be managed. It aims to make routine control part of execution, and to reserve human attention for decisions that change what the organization is committing to. Council10 develops this approach within Council10, its platform for governed multi-agent work. This essay sets out the approach and the reasoning behind it.

The appearance of success

Some automation failures announce themselves: a script throws an error, a job does not run, a report never arrives. Others are quiet. Autonomous agents add a further difficulty, because they can give a plausible account of their activity while the underlying work goes wrong.

A service can be restored while the defect that brought it down remains. A system can look healthy in one check without having shown that it is stable over time. An agent can report completion when a required check was skipped, or when its evidence describes the wrong environment. Test for each failure mechanism.

Council10 encountered this in its own operation. Agents reported work as complete when required checks had not been carried out, and the reports did not reveal the gap.

The lesson for management is that a report of completion is a claim, and the evidence it needs depends on what will rest on it. A dashboard can display that evidence and a notification can draw attention to it. Neither establishes what was authorized, what happened, or what conclusion is justified.

Two tempting answers

Two responses appeal because each seems to offer direct control over the risk.

The first is the approval button: put a person in front of the agent's actions. Approval is valuable when the person faces a real choice and has the information and the authority to make it. Applied to everything, it can become ritual. A steady stream of routine requests invites cursory review, consumes attention, and can leave a record that suggests more oversight than took place. The fault lies not with human approval but with approval detached from a meaningful decision.

The second is restriction: limit what agents can do until nothing can go wrong. Some restriction is essential. Credentials, access to sensitive systems and the authority to accept results should be tightly held. Pushed too far, though, restriction stops the work itself.

Council10 made this mistake itself. It over-corrected by removing capabilities its agents needed for authorized work, and progress stalled. The boundaries that protected credentials and sensitive systems were right to hold. Removing what each role needed to do its assigned work was not.

A protected boundary must remain protected. A missing capability calls for a proper fix, or for an explicit change to the assignment, and never for a way around the control.

When either response stands in for an accountable operating model, governance shrinks to a gate in front of the work. Governed execution treats it instead as a property of the work: carried from intent to outcome, applied in proportion to the stakes, and checked by evidence rather than ceremony.

The path from intent to accepted outcome

Governed work passes through a sequence of concerns. Each can fail on its own, and each needs its own treatment.

It begins with intent. Before work starts, someone has to say what outcome is wanted, what will count as acceptable, what is being assumed, what is deliberately excluded, and which decisions are reserved for a person. An underspecified request can make a later problem look like nothing more than an agent failure.

Next comes authority. Each actor needs a defined scope: what it may do, under what constraints, and for how long. Authority should be granted for a purpose, with explicit limits and a set point for review or expiry. A request outside an actor's authority should be refused plainly, with a reason, rather than quietly attempted or quietly ignored.

Then comes execution, where most engineering attention goes. Work has dependencies, may run alongside other work, and may need to be retried or stopped. The hard cases are those where the effect of an action is uncertain: a request went out, no confirmation came back, and no one knows whether anything happened. Uncertainty alone is no reason to repeat the action. Recovery depends either on establishing what actually happened from an authoritative source, or on an action that is known to be safe to repeat, with the effort scaled to what the action could affect.

Throughout, the system has to keep a truthful state. Execution and acceptance are different facts. A result can be reported complete without ever having been checked against the authorized outcome. Folding the two into a single "done" can give operators grounds for a reliance they have not earned.

Claims about the work need evidence: what was observed, from which source, over what period, and with what limitations. Evidence lets someone who was not present judge a conclusion, or see that it is not yet justified. Its strength lies in its relevance, not its volume.

Before anyone relies on a result, it needs assurance and acceptance. Assurance is independent challenge in proportion to the stakes: review by someone other than the author, able to find problems and empowered to say so. Acceptance is a separate act. A reviewer can confirm that the work meets its specification. Only the accountable party can accept that the result serves its purpose.

Finally comes closure and recovery. Work gets interrupted, abandoned, superseded or left in an ambiguous state. Each case needs a deliberate resolution, and unresolved obligations must survive the interruption rather than vanish with it. The organization should learn from what went wrong without turning every incident into a new rule, which is how governance becomes too heavy to use.

Where human judgment belongs

Governed execution is not an argument for keeping people out of autonomous work. It is an argument for spending their attention where it counts.

Human judgment belongs wherever the organization's commitment changes materially: a different outcome, wider access, new external exposure, a change in scope or risk, a transfer of responsibility for acceptance, or reliance on an unresolved assumption that matters. Many of these decisions can be made in advance. An action that affects an outside party does not need fresh approval if that effect was already authorized within clear limits.

Routine work inside valid authority should normally proceed without asking for the same approval again, as long as the required controls are still met and no material new uncertainty has appeared. Asking a person to confirm what has already been decided wastes their attention and teaches them to stop paying it.

Evidence that supports the claim

A governance claim is only as strong as the evidence behind it, and evidence fails in recognizable ways.

A single healthy reading does not show stability over time. Restoring a service does not show that the cause of its failure was fixed. A system that proves useful under close supervision has not thereby been shown dependable without it. An artifact whose integrity can be verified may still not support the conclusion drawn from it, if it answers a slightly different question from the one being asked. And review, authorization, acceptance and closure are four separate acts, each with its own evidence.

What these errors share is a true observation pressed into service for a stronger conclusion than it can bear. They are hard to catch precisely because each starting fact is correct.

Testing the failures, not only the successes

Governance has to be tested against the ways work actually goes wrong. A control that has only been seen on successful work has not yet been tested against the failures it exists to prevent.

Useful tests ask whether an unauthorized request is refused as reliably as an authorized one is accepted. They look at duplicated and replayed requests, conflicting actions running at the same time, and decisions made on information that has since changed. They exercise interruptions and degraded dependencies, instead of assuming that a clean, uninterrupted run covers those conditions.

Assurance needs the same scrutiny. Do reviewers catch the problems they should, stay within the agreed criteria, and recognize material risks? Does the evidence actually cover the period and source it claims to? These tests examine the basis for acceptance, not merely whether execution produced an artifact.

A single successful run, healthy reading or passed review establishes only what that observation covers. Claims should be stated for the specific version, workflow and evidence that were tested, and no further.

Putting the principles to work

Governance means making authority, evidence and acceptance explicit. Our own work building Council10 puts those principles to the test.

The standard

The question that matters for autonomous work is no longer whether an agent can act. Increasingly, agents can. The question is whether an organization can know what was authorized, what actually happened, what remains uncertain, and who can responsibly accept the result.

Governed execution makes those questions part of the work itself, instead of an investigation put off until something goes wrong. The companion essay on Durable Motion takes up a different responsibility: who owns continuation across actions, results, waits and deliberate stops.

The Cost of Not Knowing

Why uncertainty about automated work is a management problem in its own right

---

A failed action leaves a problem to solve. An action whose outcome cannot be established leaves a second problem: deciding what is safe to do next.

Consider a payment submitted through an automated system. The request times out before a confirmation arrives. A well-designed service may make resubmission safe or offer an authoritative way to check status. Where it offers neither, the timeout leaves the outcome open. The payment may have failed. It may also have gone through, with only the confirmation lost. Repeating it could pay twice. Abandoning it could leave an obligation unmet. Waiting defers the decision without necessarily improving the information it will be made on.

Nothing about the payment itself has changed. The exposure, and the choices available, have. Until the uncertainty is resolved, even an ordinary next step carries a risk that would otherwise be avoidable.

Accuracy and productivity do not, on their own, establish what an organization can safely rely on. A system can produce useful work while leaving its operators unable to say what happened, whether it was authorized, or what can now be trusted. The resulting uncertainty can consume attention, delay decisions and make later work harder to trust.

The burden passes to the next decision

Work rarely ends with the action itself. A payment changes an account. A deployment changes the environment other work runs in. A message to a customer creates an expectation. A finished analysis becomes the input to someone else's decision.

When the outcome of one action is uncertain, the next person or system has to resolve that uncertainty or carry it forward. Carrying it forward can be reasonable when the consequences are small and the assumption is stated. It becomes dangerous when an assumption is recorded as fact and later participants have no reason to question it.

Consider another case: an agent reports that a change has been deployed. A second agent begins validation, and a third drafts a customer update. If the first report cannot be tied to the intended environment and version, the later tasks may be building on the wrong starting point. More work has happened. The original uncertainty is still there.

The cost can therefore exceed the time needed to repeat a single task. It can include tracing which later decisions depended on the first one, working out which conclusions still hold, and restoring confidence in the record. Uncertainty acquires its consequences through the work that relies on it. The management burden is less about recovering one missing fact than about deciding which dependent judgments can still stand.

A record must support a conclusion

Having records does not settle the matter. A record can show that a request was submitted without showing that the action took effect. A passing check can establish the state of one environment at one moment without establishing the condition a later decision depends on.

Management needs evidence that answers a specific question. What action occurred? What did it affect? Under whose authority? What result was observed? How far does that observation justify reliance?

These questions are related, but an answer to one cannot automatically stand in for the others. Uncertainty about an effect, about authorization, and about fitness for later use may each call for different evidence and a different decision-maker. An action can succeed without being authorized. An authorized action can fail. A result can be useful and still fall short of supporting the conclusion someone wants to draw from it.

A design can require evidence without yet producing it. An implemented control can exist without proving what happened in a particular transaction. A verified result establishes only what its evidence supports.

The distinction matters because a record that looks complete is often more persuasive than one that is openly incomplete. The difficulty then lies in recognizing that the evidence establishes less than the organization believes. More documentation cannot close that gap unless it answers the question on which reliance depends.

Restriction alone leaves questions unanswered

Restrictions define what may be attempted and by whom. They are necessary wherever an action could create consequences the organization is unwilling to accept. But permission to act and knowledge of what happened are separate responsibilities.

A narrowly permitted action can still have an uncertain outcome. An unauthorized action can still produce an apparently correct result. Preventing one kind of failure does not rule out the other.

Too little control can invite harm and uncertainty. Too much can stop the work altogether. The practical requirement is to match each role's access to its authorized responsibilities, while keeping enough evidence for consequential actions to be understood and reviewed. An assignment does not by itself grant access or waive a protected boundary.

That evidence has to remain useful when work is interrupted, handed over or questioned later. Otherwise the organization depends on the memory of whoever acted, at exactly the moment that memory may be unavailable or unreliable.

Unknown is a legitimate operating state

An organization has to be able to say that an outcome is unknown without the admission being read as a lack of confidence or competence. The uncertainty should attach to a specific claim. It should not erase facts already established.

Pressure for a definite answer can force premature closure. Work gets called complete because a request was sent, because no error appeared, or because someone produced a plausible account. Each may be relevant. None necessarily settles the question.

Leaving an outcome unresolved should serve a purpose. Someone has to own the next decision, understand what remains uncertain, and judge whether more evidence is worth obtaining. Otherwise uncertainty becomes an open-ended holding area where responsibility disappears.

Unknown is not a universal stop condition. Different situations justify different responses, depending on the consequence, reversibility, detectability and urgency of the action, and on the risk that the uncertainty spreads into later work. A reversible, low-consequence action may allow a cautious next step under a stated assumption. A payment, a change to access or a commitment to a customer may need stronger confirmation. The standard of evidence should reflect both the cost of being wrong and the cost of finding out. Investigation should stop when its likely benefit to the decision no longer justifies its cost and delay.

This is a judgment made under uncertainty, not a calculation that can always be done precisely. A decision-maker may seek more evidence, proceed within a bounded exposure, or hold the affected action. Whichever they choose, the assumption and the reason for it should stay visible.

The aim is not certainty about everything. It is an explicit basis for deciding where reliance is justified and where it is not.

The organization carries what the agent cannot settle

An agent's account of its work is one input to that decision. It cannot by itself establish every fact about an external system, or confer authority the organization has not granted.

Responsibility therefore reaches beyond whoever performed the task. Someone has to define the conditions under which the result may be used. Someone has to keep the relevant evidence. Someone has to decide what happens when the evidence and the account disagree. These responsibilities can be assigned to roles and processes. They do not require a new human approval for every action.

Together they make the basis for a decision available to someone other than the original participant. They also allow a confident account to be challenged without throwing away the work that was genuinely done, so the useful result and the unsupported conclusion can be separated.

An organization that cannot draw these distinctions may rely on poorly supported claims or spend avoidable effort reconstructing the evidence. Sampling, risk-tiered assurance and informed acceptance of residual uncertainty are more proportionate responses, provided their limits are understood.

Confidence that can be carried forward

Governance earns its place when it improves the decisions an organization can responsibly make. A larger rulebook or a more detailed report has value only to the extent it serves that purpose. The test is whether the evidence changes a consequential decision, not whether the record looks exhaustive.

For automated work, that means knowing when an outcome is established, recognizing when it is not, and preserving the difference as work passes between participants. It means making uncertainty visible before someone unknowingly builds on it.

The cost of not knowing can be paid in delayed action, duplicated effort, unnecessary verification and misplaced reliance. Some uncertainty is unavoidable. Even where organizations cannot eliminate it, they can decide how it is surfaced and who owns it.

A capable organization gives its people and agents a basis for the next decision: what happened, what can be trusted, and what still needs to be resolved.

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.