The Computational Enterprise

The evidence does not yet support the arrival of the autonomous enterprise.

It supports a narrower and more consequential conclusion.

Software is beginning to acquire bounded capabilities for interpreting conditions, selecting actions, using tools, maintaining limited state, and coordinating sequences of work. At the same time, enterprises are making more of their operating context, authority, controls, and commitments accessible through digital systems.

When these developments converge, selected forms of organizational coordination can become computationally maintained.

A system may identify an unresolved commitment, assemble relevant context, determine which authority applies, initiate permitted action, monitor progress, surface exceptions, and retain evidence of the resulting outcome.

This is different from conventional automation.

Automation executes a predefined process. Computational coordination helps maintain an organizational obligation as conditions change.

The distinction is central to this research.

This dossier separates measured findings, conceptual foundations, technical specifications and architectural inference. The proposed coordination architecture is an interpretation of those sources, not a demonstrated enterprise-wide operating model.

The source notes identify the materials used and source-specific evidence limits. The dossier does not document source-selection criteria, the extent of coverage or a dossier-level last-reviewed date.

Organizations have always been information processing systems.

They sense conditions, interpret signals, allocate attention, make decisions, coordinate specialized work, and adapt their behavior. Enterprise software has progressively encoded parts of this activity through transaction systems, workflow engines, planning platforms, identity controls, integration layers, and systems of record.

Yet the coordinating logic of the enterprise has remained heavily dependent on human attention.

People carry context between functions. They determine who is allowed to decide. They notice when an exception invalidates the normal process. They chase unresolved dependencies, negotiate priorities, reconstruct incomplete histories, and decide whether an outcome is acceptable.

Artificial intelligence does not remove these institutional requirements.

It creates the possibility that software may participate in satisfying them.

The important transition is therefore not from human work to machine work.

It is from software that records and routes organizational activity to software that interprets and helps maintain organizational commitments.

1. 01

   Coordination is becoming an architectural concern

   When software participates in coordination, commitments, authority, context, escalation, evidence, and recovery must become explicit system responsibilities.

2. 02

   Current capability is real but bounded

   Models and agents can already perform meaningful sequences of digital work. Their reliability remains uneven, especially as task duration, ambiguity, environmental change, and consequence increase. Research therefore supports bounded delegation, not generalized autonomy.

3. 03

   Productivity evidence does not establish enterprise transformation

   Research on AI-assisted customer support found productivity gains in that setting. METR’s randomized study of experienced open-source developers using early-2025 tools found longer completion times in its setting. These studies examine different work, populations and systems. Neither establishes enterprise-wide agentic transformation. Task productivity also does not establish how released capacity becomes financial value.¹³¹⁴

4. 04

   The enterprise brain is the wrong governing metaphor

   Organizations contain distributed authority, specialized knowledge, conflicting incentives, regulated responsibilities, and legitimate disagreement. These features support federation as a design direction where distinct authorities and meanings must be preserved. They do not establish that every computational enterprise requires a federated technical topology. Centralized services may coexist with distributed authority if permissions, domain ownership, disagreement and accountability remain explicit.

5. 05

   Institutional memory becomes active and contestable

   When agents retrieve prior decisions, policies, records, and operating histories to guide action, enterprise memory stops being passive storage. Provenance, correction, expiry, confidence, and managed disagreement become operating requirements.

6. 06

   Management changes rather than disappears

   As machines absorb selected routing, monitoring, synthesis, and follow-up work, management shifts toward defining outcomes, assigning authority, governing exceptions, allocating capacity, resolving ambiguity, and remaining accountable for institutional consequences.

7. 07

   Firm boundaries may become more computationally permeable

   Agents may reduce the cost of coordinating work across suppliers, platforms, customers, and partners. Whether this makes firms smaller depends on trust, contracting, control, strategic knowledge, liability, and the economics of external coordination.

This inquiry does not assume machine consciousness, human equivalence, or unrestricted autonomous decision making.

It examines delegated software operating within institutional authority.

The relevant question is not whether an agent can appear intelligent.

It is whether an enterprise can permit software to maintain consequential commitments without losing accountability, recoverability, evidentiary integrity, or economic control.

That is the threshold of the computational enterprise.

The enterprise is commonly described through its visible structure: business units, functions, reporting lines, platforms, products, and processes.

Beneath that structure lies a less visible system.

The enterprise must continuously coordinate interdependent work.

A sale changes demand. Demand changes inventory. Inventory changes production. Production changes logistics. Logistics changes customer commitments. Each action creates information, dependencies, decisions, and consequences elsewhere in the organization.

The enterprise exists partly to make this coordination possible.

Why firms coordinate internally

Ronald Coase’s theory of the firm began with a foundational question: if markets can coordinate economic activity through prices and contracts, why do firms exist?¹

His answer was that using the market carries costs.

Relevant prices must be discovered. Separate contracts must be negotiated and concluded. In long-term contracts, forecasting difficulties can make it impractical or undesirable to specify every detail in advance, leaving some decisions to later direction. When coordinating activity through the market becomes more expensive than directing it within an organization, the firm internalizes the work.

Williamson’s later transaction-cost economics develops the comparative governance of contractual relations, including performance monitoring, dispute resolution and adaptation under uncertainty.¹⁶

The boundary of the firm therefore reflects a coordination choice.

Some activity is coordinated through management, employment, shared systems, and internal authority. Other activity is coordinated externally through contracts, suppliers, platforms, and markets.

This distinction becomes important when artificial intelligence changes the cost of finding information, matching capabilities, negotiating routine terms, monitoring commitments, and coordinating action across institutional boundaries.

The technology may not simply change how work is performed.

It may change where the work is economically organized.

Coordination manages dependencies

Coordination theory defines coordination as the management of dependencies among activities.

The definition is deliberately broader than communication.

Two groups may communicate frequently and still fail to coordinate if ownership is unclear, resources are unavailable, sequencing is wrong, or neither group has authority to resolve the dependency.

Coordination requires the organization to answer recurring questions:

• What depends on what?
• Who owns the resulting commitment?
• What information must move between participants?
• Which resource must be available?
• What sequence must be preserved?
• Who can resolve a conflict?
• What proves that the dependency has been satisfied?

Malone and Crowston’s work showed that similar dependencies appear across very different organizational settings. Shared resources must be allocated. Producer and consumer activities must be synchronized. Preconditions must be established. Multiple contributors must be combined into a usable result.²

The visible workflows may differ.

The underlying coordination problems often repeat.

This creates the possibility of a reusable computational coordination layer.

Such a layer would not encode every business process as one fixed sequence. It would recognize common coordination responsibilities and apply them within a specific operating context.

Uncertainty creates coordination demand

Organizations can predefine work when tasks, conditions, and dependencies are sufficiently predictable.

As uncertainty increases, exceptions increase.

Information known at the beginning of the process becomes insufficient to determine every later action. New evidence must be interpreted while work is underway. Decisions move upward or across the organization. Teams exchange more information. Additional coordination mechanisms appear.

Jay Galbraith’s information processing view of organization design connected uncertainty directly to organizational form. When uncertainty increases, the organization must either reduce the information required to perform the work or increase its capacity to process information during execution.³

Enterprises have historically increased this capacity through hierarchy, planning, lateral roles, meetings, specialist teams, dashboards, and information systems.

Agentic systems may add another mechanism.

They may continuously interpret events, retrieve relevant context, identify affected commitments, and route exceptions toward the authority capable of resolving them.

This does not eliminate uncertainty.

It changes the organization’s capacity to process uncertainty.

The hidden coordination bill

Coordination cost rarely appears as a single financial category.

It is distributed across:

• Meetings required to reconstruct shared context.
• Messages used to locate ownership.
• Management time spent following incomplete work.
• Delays caused by unresolved decisions.
• Rework produced by conflicting interpretations.
• Duplicate systems created because information is not trusted.
• Control activity required to prove that procedures were followed.
• Escalations caused by exceptions the workflow could not absorb.

Each activity may appear reasonable in isolation.

Together, they form the coordination bill of the enterprise.

These activities can increase coordination demand. Their net effect on cost depends on the organization and its coordination mechanisms. This dossier does not estimate the size or trend of that bill.

Digitizing activities need not remove the human effort required to connect them. This is a possible mechanism, not a measured finding about the frequency or net effect of enterprise digital transformation.

More systems can create more interfaces.

More data can create more interpretation.

More automation can create more exceptions that require human recovery.

From recorded coordination to maintained coordination

Traditional enterprise systems make coordination visible.

They store tasks, cases, approvals, transactions, messages, and status.

Computational coordination introduces a stronger capability.

The system can participate in maintaining the dependency itself.

It can detect that a commitment has become endangered, determine which context matters, identify who or what holds authority, initiate permitted action, and continue observing the commitment until the required outcome exists.

This is the architectural shift:

The enterprise moves from systems that record coordination to systems that help maintain it.

The shift remains bounded by the quality of the enterprise around it.

If commitments are ambiguous, authority is informal, context is contradictory, and completion cannot be verified, the agent inherits organizational confusion.

Computational coordination does not make an incoherent enterprise coherent.

It makes the enterprise’s coordinating logic executable, including its omissions, conflicts, and weaknesses.

The computational enterprise depends on what agentic systems can actually do, not what product language implies they can do.

Current systems can interpret natural language, retrieve information, generate structured outputs, write and execute code, use application interfaces, operate graphical environments, and coordinate multistep tasks.

These capabilities are significant.

They do not yet constitute dependable general autonomy.

The evidence describes a moving boundary: agents can complete increasingly consequential digital work, but their performance remains sensitive to task length, ambiguity, environmental change, evaluation method, and the availability of objective feedback.

From generation to participation

Generative models initially entered enterprise work as producers of content.

They drafted text, summarized documents, generated code, classified information, and answered questions.

Agentic systems extend this capability through action.

A model can select tools, inspect external systems, preserve intermediate state, adapt a plan, and continue working across multiple steps. Computer using agents can interact with graphical interfaces. Research agents can browse, compare sources, and synthesize findings. Coding agents can modify repositories, run tests, and respond to execution results.

The relevant progression is:

Generation → Interpretation → Tool Use → Execution → Coordination

Each transition increases potential value.

Each transition also increases operational consequence.

A generated recommendation can be reviewed before use. A tool call can change a system. A coordinated sequence can create effects that are difficult to reverse or may not become visible until another part of the enterprise is affected.

This is why agent capability cannot be evaluated only through the quality of its final answer.

The system must also be evaluated through its actions, state transitions, dependencies, recovery behavior, and actual outcomes.

Capability is expanding unevenly

METR’s time-horizon research measures the human task duration associated with a specified agent success rate on a bounded task suite, primarily in software and research. Its historical results show improving performance on that suite. A 50% time horizon is not the length of time an agent can work independently or an enterprise reliability threshold.¹¹

The trend is meaningful, but its interpretation requires discipline.

A time horizon at which an agent succeeds half the time is not an enterprise reliability threshold. Consequential processes may require far higher confidence, and current evaluation sets do not establish performance at reliability levels approaching operational certainty.

The measured tasks are also not equivalent to the full environment of an enterprise.

Enterprise work can involve incomplete instructions, changing priorities, contradictory records, tacit knowledge and consequences not captured by an automated score. This is the dossier’s deployment interpretation. Separately, Thomas Kwa’s METR limitations note cautions against precise estimates of very high reliability and against assuming that the measured task distribution represents all real work.¹¹

Capability therefore expands faster than trustworthy delegation.

This is the autonomy gap.

Benchmarks are not operating environments

Benchmarks isolate a capability so that it can be measured.

Enterprises combine many capabilities under conditions that are difficult to standardize.

An agent may locate obscure information in a research benchmark, complete a defined coding task, or reproduce parts of a published experiment. These results demonstrate real advances in planning, search, tool use, and execution.

They do not establish that the same system can safely maintain an enterprise commitment.

A customer resolution process, for example, may require the agent to determine which record is authoritative, interpret policy, recognize an exceptional circumstance, protect sensitive information, calculate economic exposure, obtain approval, avoid duplicate action, update multiple systems, communicate appropriately, and prove that the issue was resolved.

No individual benchmark captures the complete institutional burden of that outcome.

Enterprise capability emerges from the model and the surrounding execution system.

Reliability declines through composition

A multistep system inherits the uncertainty of each decision and action within the sequence.

A small probability of error at one step can become a substantial probability of failure across a long workflow. The risk becomes greater when later actions depend on earlier interpretations or when the system changes the environment it is observing.

Retries do not solve every failure.

A repeated action can create duplication. A corrected step may not reverse an earlier consequence. A successful tool response may still represent the wrong business action.

Agentic execution therefore requires more than improved model accuracy.

It requires checkpoints, idempotency, bounded permissions, evidence, state management, recovery paths, and explicit conditions for human intervention.

Automation is not the only objective

The future of work is often framed as a choice between human work and machine replacement.

The evidence suggests a more varied design space.

Shao and colleagues’ WORKBank preprint records worker preferences for automation and augmentation and distinguishes desired levels of human involvement through a Human Agency Scale. Preferences vary across tasks and occupations. These responses and expert capability assessments do not establish that a deployment is safe or economically effective. This dossier therefore treats worker preferences as one input to delegation alongside authority, accountability and operational evidence.¹²

The computational enterprise is therefore not defined by maximum autonomy.

It is defined by deliberate allocation.

Software performs and coordinates work where delegation is technically credible, institutionally authorized, economically useful, and socially acceptable.

Humans retain responsibility where judgment, legitimacy, contested interpretation, and accountability remain essential.

The question is not how much work the machine can perform.

It is how much consequence the institution is prepared to delegate.

Computational coordination does not emerge from adding an agent to existing enterprise systems.

It requires an institutional architecture around the agent.

The system must know what commitment it is maintaining, which authority permits action, what context may be trusted, how work progresses, what evidence supports a decision, and whether the resulting outcome is economically acceptable.

The following six elements form this dossier’s proposed coordination architecture. They are a design synthesis informed by coordination theory, risk-management guidance and technical specifications, not a validated architecture prescribed by those sources.

1. Commitments

Organizations operate through commitments.

An order must be fulfilled. A control must be satisfied. A defect must be resolved. A supplier must deliver. A decision must be made before another activity can proceed.

Traditional systems represent fragments of these commitments through tasks, tickets, transactions, service levels, and workflow states.

Computational coordination requires a more complete representation.

The system must understand:

• The outcome being promised.
• The party to whom the commitment is owed.
• The accountable owner.
• The conditions that define acceptance.
• The dependencies that could prevent completion.
• The time and economic boundaries surrounding the obligation.
• The evidence required to prove satisfaction.

A task records activity.

A commitment connects activity to accountability and outcome.

Without an explicit commitment, an agent can complete steps while the underlying obligation remains unresolved.

2. Authority

An agent cannot derive legitimate authority from its ability to act.

Authority must be delegated by the institution.

The architecture must distinguish between what the system can technically do and what it is permitted to do under specific conditions.

Delegation should define:

• The identity under which the agent operates.
• The principal granting authority.
• The permitted actions and systems.
• Financial, temporal, and risk limits.
• Required approvals.
• Conditions that suspend or revoke authority.
• Responsibility for consequences.

This authority may change during execution.

An action permitted for a low value case may require approval when cumulative exposure increases. An agent allowed to read a customer record may not be allowed to modify payment instructions. A system authorized to propose a decision may not be authorized to enact it.

NIST’s AI Agent Standards Initiative identifies interoperability, security and identity as areas for standards and research. Separately, the December 2025 Initial Preliminary Draft of NIST IR 8596 proposes, in the PR.AA-03 Defend focus-area consideration, assigning each AI agent a unique identity and credentials and treating it with the security precautions applied to privileged users. This draft consideration is not a binding or final standard.⁴

3. Enterprise Context

Coordination depends on context.

The agent must know which policies apply, which records are authoritative, what has already happened, what constraints remain, and how the current situation differs from the normal case.

More context is not necessarily better.

Enterprise context must be selected, governed, and temporally valid.

The architecture must preserve:

• Source.
• Ownership.
• Effective date.
• Confidence.
• Access restrictions.
• Relationships to other evidence.
• Correction and expiry conditions.

Context without provenance can create confident action from obsolete or contested information.

W3C provenance standards formalize relationships among entities, activities, and responsible agents so that the origins and transformations of information can be examined. The principle becomes more consequential when retrieved information influences action rather than merely informing a report.⁵

4. Coordination Workflows

A computational coordination workflow is not simply a predefined sequence.

It is a governed mechanism for maintaining a commitment while conditions change.

The system must be able to:

• Detect relevant events.
• Interpret their effect on commitments.
• Select permitted actions.
• Coordinate dependencies.
• Preserve state across interruptions.
• Request decisions when authority is insufficient.
• Recover from partial execution.
• Continue until acceptance or formal termination.

Some paths will remain deterministic.

Others will require model interpretation.

The architecture must make the boundary visible. A probabilistic inference should not silently become an irreversible action.

5. Evidence and Disagreement

Enterprise reality is not always singular.

A customer record may conflict with a contract. A policy may be interpreted differently across functions. Two systems may claim to be authoritative. Evidence may be incomplete.

The architecture must allow the system to represent disagreement rather than prematurely erase it.

Every consequential action should retain:

• The evidence considered.
• The source and time of that evidence.
• The interpretation applied.
• The authority supporting the action.
• The alternatives rejected.
• The resulting system changes.

Trustworthy operation requires validity, reliability, accountability, transparency, safety, security, resilience, and appropriate explanation. These are operating properties, not presentation features.

6. Management and Economics

Computational coordination consumes resources and redistributes work.

Its value cannot be measured through task completion alone.

The enterprise must determine whether the system:

• Reduces coordination delay.
• Improves accepted outcomes.
• Releases usable human capacity.
• Reduces rework and exception cost.
• Introduces new infrastructure or assurance expense.
• Concentrates risk in new control points.
• Changes managerial spans and responsibilities.

Management remains responsible for deciding which commitments become computational, where exceptions land, and whether the resulting operating model creates value.

The complete architecture therefore connects technical execution to institutional consequence:

Commitments define what must be maintained. Authority defines what may be done. Context informs action. Workflows coordinate execution. Evidence preserves accountability. Management determines whether the system remains legitimate and economically useful.

Coordination depends on memory.

The enterprise must retain what was decided, why it was decided, which evidence supported the decision, what action followed, and what consequence occurred.

Historically, this memory has been distributed across people, procedures, records, systems, routines, and culture.

Agentic systems make organizational memory active.

The system does not merely preserve prior information. It retrieves that information, interprets it, and uses it to influence future action.

This changes both the value and the risk of enterprise memory.

Memory becomes an operating participant

Walsh and Ungson’s (1991) organizational memory model describes how information from an enterprise’s history is acquired, retained and retrieved for present decisions.¹⁵

That memory does not reside in one repository.

Their model distinguishes five internal retention facilities—individuals, culture, transformations, structures and ecology—and an external source, external archives. What the organization remembers depends partly on where information was stored and whether anyone knows how to retrieve it.

Traditional knowledge systems require a person to search for information and decide whether it applies.

An agent can retrieve prior cases, policies, transactions, messages, and decisions while work is underway. It can use those materials to determine what should happen next.

Memory therefore moves from reference infrastructure into execution infrastructure.

An incorrect document no longer produces only an incorrect answer.

It may produce an incorrect action.

Institutional memory can be wrong

Enterprise records are not neutral representations of reality.

They may be incomplete, obsolete, duplicated, politically shaped, or created under conditions that no longer apply.

A previous decision may have been reasonable in its original context and inappropriate in the present one. A policy may have been superseded without every copy being removed. A customer record may reflect one function’s interpretation while another function holds contradictory evidence.

Human organizations manage some of this ambiguity through judgment, experience, informal challenge, and knowledge of institutional history.

A computational memory system needs explicit mechanisms.

Every memory capable of influencing action should carry:

• Provenance.
• Effective period.
• Accountable owner.
• Confidence or evidentiary status.
• Access restrictions.
• Correction history.
• Expiry or review conditions.
• Relationships to conflicting evidence.

The system must distinguish between a fact, an interpretation, a policy, a prior decision, and a disputed claim.

Treating all retrieved information as equivalent context creates institutional error at machine speed.

Memory creates a persistent attack surface

Persistent memory expands the security boundary of an agentic system.

Malicious or incorrect content may be stored during one interaction and influence decisions long after the original event. The system may treat retrieved memory as trusted context because it originated inside the enterprise environment.

This creates the possibility of memory poisoning.

An attacker, compromised tool, incorrect workflow, or accidental input may introduce information that alters future reasoning, tool selection, or execution. The effect can persist across sessions and spread through connected agents.

OWASP’s Top 10 for Agentic Applications 2026 identifies Memory & Context Poisoning as ASI06. OWASP’s accompanying discussion explains how attacker-controlled information retained in memory can influence later reasoning and actions. This is a threat category and mechanism, not an estimate of its prevalence across enterprises.⁶

Memory must therefore be governed as both knowledge and executable influence.

Disagreement must remain visible

Organizations do not always need immediate consensus.

Legal, financial, operational, security, and commercial functions may interpret the same event differently because they hold different obligations.

A computational enterprise must not resolve every disagreement by selecting whichever record is easiest to retrieve or whichever interpretation receives the highest model confidence.

Some disagreement is evidence of institutional failure.

Some is a legitimate feature of institutional governance.

The system must be able to preserve competing claims, identify their sources, and escalate the unresolved decision to the authority responsible for adjudication.

The objective is not a single enterprise truth.

It is accountable action under conditions of incomplete and contested knowledge.

Management moves toward exceptions and system design

If agents assume more responsibility for routing work, monitoring commitments, assembling context, and following routine dependencies, the work of management changes.

Managers spend less time asking:

• “Has this moved?”
• “Who owns this?”
• “Where is the information?”

They spend more time deciding:

• “What outcome are we maintaining?”
• “Which authority can be delegated?”
• “Which exception requires judgment?”
• “Where is capacity constrained?”
• “Which evidence should govern?”
• “Who remains accountable for the consequence?”

Management does not disappear when coordination becomes computational.

It moves upward in abstraction and closer to institutional design.

Stanford HAI’s AI and Organizations Lab lists changes in managers’ jobs, organizational structures and human roles as research questions and fieldwork topics. This is evidence of an active research agenda, not a published finding that management will shift in the direction proposed here. The preceding management model is this dossier’s conditional interpretation.⁷

Oversight must become operational

Human oversight cannot mean placing a person at the end of every automated action.

That recreates the coordination burden the system was intended to reduce and encourages superficial approval.

Oversight should be risk based.

Humans should define authority, examine unusual patterns, adjudicate contested evidence, review consequential exceptions, and intervene when system behavior departs from expected conditions.

NIST AI RMF 1.0, MANAGE 4.1, calls for post-deployment monitoring plans that include user and stakeholder input, appeal and override, decommissioning, incident response, recovery and change management. This is risk-management guidance, not evidence that a particular monitoring cadence or mix of automated and human review is effective.⁸

The managerial responsibility is therefore not constant supervision.

It is creating an institution capable of knowing when machine coordination should continue, when it should stop, and who must answer for what happens next.

The boundary of the firm is partly a boundary of coordination.

Enterprises internalize work when directing it through shared authority, systems, and management is more effective than coordinating it through external contracts and markets.

Agents may change that calculation.

If software can discover capabilities, exchange structured context, negotiate bounded terms, initiate transactions, monitor delivery, and verify outcomes, some forms of external coordination may become cheaper and faster.

The consequence could be more permeable enterprise boundaries.

It does not follow that every firm becomes smaller.

From system integration to agent coordination

Traditional intercompany coordination depends on predefined interfaces.

Organizations connect through application programming interfaces, electronic data interchange, supplier portals, shared platforms, contracts, and manual communication.

Each relationship requires agreement about data, process, identity, timing, responsibility, and exception handling.

Agent interoperability introduces a more adaptive mechanism.

One agent may discover another agent’s capabilities, request work, exchange context, negotiate an execution path, receive status, and interpret the result without every interaction being encoded in advance.

Open standards are beginning to provide technical foundations for this model.

The Model Context Protocol specification, revision 2025-06-18, defines an interface for connecting language-model applications with tools and data. The A2A Protocol specification, v0.3.0, defines communication structures for agent interactions. These specifications support technical interoperability. They do not by themselves establish lower total integration cost, trusted delegation or agreement about business meaning.⁹

These standards make connection easier.

They do not make the relationship trustworthy.

Protocol is not institution

Two agents may be technically capable of exchanging information while lacking any legitimate basis for doing business.

Cross company coordination requires more than message compatibility.

The participants must establish:

• The identity of each organization and agent.
• The principal represented by the agent.
• The authority delegated to it.
• The service or outcome being requested.
• The information permitted to cross the boundary.
• The economic terms governing the exchange.
• The evidence required for acceptance.
• The allocation of risk and liability.
• The mechanisms for dispute, correction, and recovery.

An agent cannot create institutional authority merely by presenting a capability.

It must be able to prove whose authority it carries and within what limits.

This becomes particularly important when one enterprise’s agent can trigger action inside another enterprise’s systems.

The boundary must protect both organizations without requiring a human negotiation for every routine interaction.

Commitments may become machine readable

Contracts describe commitments between parties.

They specify obligations, rights, limits, remedies, and conditions.

Most contracts remain documents interpreted by people and translated into operational systems. The execution environment rarely maintains a complete relationship between the contractual commitment and the operational activity intended to satisfy it.

Agentic coordination may require parts of that relationship to become machine readable.

The system must understand:

• What has been promised.
• Which conditions activate the obligation.
• Which actions are authorized.
• What evidence constitutes performance.
• Which exception invalidates normal execution.
• When the matter must return to human authority.

This does not mean converting every contract into software.

Legal language often preserves necessary flexibility, ambiguity, and room for judgment.

The computational layer should encode the operational commitments that can be safely executed while preserving escalation paths for interpretation and dispute.

The coordination cost may move

Agentic systems may reduce some external transaction costs.

Discovery can become automated. Routine negotiation can become structured. Monitoring can become continuous. Evidence can be exchanged directly between systems. Smaller suppliers may become easier to coordinate because the administrative burden of managing them declines.

But new costs appear.

Enterprises must verify agent identity, govern delegated credentials, control information disclosure, monitor automated interactions, investigate failures, manage protocol risk, and determine liability when agents produce unintended consequences.

The coordination cost is not eliminated.

It moves from human administration toward architecture, assurance, identity, policy, and exception management.

NIST’s AI Agent Standards Initiative reflects this emerging requirement by focusing on secure interoperability, agent identity, and standards that support trusted adoption.¹⁰

Does the firm become smaller?

Lower external coordination costs can make it economically attractive to source more capabilities outside the enterprise.

A firm may retain strategy, capital allocation, product ownership, core intellectual property, customer accountability, and governing judgment while coordinating a larger network of specialized external providers.

This could produce smaller organizational cores surrounded by computationally coordinated ecosystems.

The opposite outcome is also plausible.

Large enterprises may use agents to coordinate greater internal complexity, operate across more domains, and absorb work previously performed by intermediaries. Platforms controlling agent identity, discovery, payment, context, or trust may become more powerful rather than less.

The effect on firm size therefore remains conditional.

It depends on whether agents reduce the external cost of coordination more than they reduce the internal cost of management.

The boundary becomes an execution surface

The most defensible near term conclusion is not that the firm disappears.

It is that the firm boundary becomes more active, programmable, and continuously governed.

Agents may increasingly carry requests, context, delegated-authority information, evidence and commitments across organizational boundaries. This is a conditional architectural prospect supported by emerging interoperability mechanisms, not a measured forecast of adoption.

The enterprise must know what may cross, who may act, what remains confidential, how performance is accepted, and where accountability returns when coordination fails.

The boundary of the computational enterprise is not simply where its systems end.

It is where delegated authority changes hands.

The evidence supports a direction of travel.

It does not support a predetermined destination.

Enterprises are gaining software capable of interpreting conditions, using tools, maintaining limited state, and coordinating increasingly complex digital work. Open protocols are making agents more connected. In this dossier's assessment, organizational context is becoming more accessible, and authority, controls, and policies are gradually becoming machine interpretable.

These developments make computational coordination possible.

Whether they produce a more capable institution or a faster form of organizational disorder depends on how the enterprise chooses to design them.

What is true now

Today, artificial intelligence is materially useful in bounded forms of knowledge and digital work.

Models can generate, classify, summarize, retrieve, reason, and use tools. Agentic systems can complete multistep tasks in constrained environments. Enterprises are beginning to connect these systems to internal data, applications, workflows, and operating processes.

The strongest evidence exists where:

• The task is digitally accessible.
• The objective is explicit.
• The environment is sufficiently bounded.
• Progress can be observed.
• Results can be tested.
• Errors can be contained or reversed.
• Human expertise remains available for exceptions.

This is meaningful operating capability.

It is not generalized enterprise autonomy.

What is emerging

The emerging state is software that participates in maintaining organizational commitments.

An agent may monitor a case, detect a change, gather context, determine the permitted next action, coordinate a dependency, request approval, execute a bounded step, and continue observing the outcome.

This capability will initially appear inside selected workflows.

It will be strongest in domains where authority can be clearly expressed, actions are observable, evidence is available, and exceptions can reach an accountable human owner.

The enterprise will not become computational all at once.

Different commitments will support different degrees of delegation.

Some will remain deterministic. Some will become agent coordinated. Some will remain predominantly human because their legitimacy depends on judgment, negotiation, empathy, or accountable discretion.

What is plausible

A plausible next state is a mixed execution system in which people, conventional software, specialized models, internal agents, vendor agents, and external agents coordinate work across shared institutional boundaries.

In this organization:

• Commitments become observable operating objects.
• Authority becomes dynamically enforceable.
• Enterprise memory becomes active and governed.
• Routine coordination becomes increasingly machine maintained.
• Managers focus more heavily on outcomes, capacity, exceptions, and judgment.
• Organizational boundaries become more computationally permeable.
• Assurance becomes continuous rather than retrospective.
• Economics are evaluated at the accepted outcome rather than the generated output.

This state does not require every agent to be highly autonomous.

It requires the enterprise to coordinate different levels of machine and human agency as one operating system.

What remains speculative

The evidence does not establish that enterprises will become self managing institutions.

It does not establish that hierarchy will disappear, managers will become unnecessary, or market coordination will replace the firm.

It does not establish that agents can resolve political conflict, create institutional legitimacy, accept moral responsibility, or determine which outcomes an organization should pursue.

It also does not establish that lower coordination costs will distribute economic power.

Agent interoperability could support open ecosystems of specialized providers. It could also strengthen the platforms that control identity, context, discovery, infrastructure, or access to customers.

The autonomous enterprise remains a hypothesis.

The computational enterprise is the nearer institutional possibility.

The executive design choice

The most consequential decisions will not concern model selection alone.

Executives will decide:

• Which commitments may be computationally maintained.
• Which authority may be delegated.
• Which evidence the institution accepts.
• Which disagreements must remain visible.
• Which actions require human judgment.
• Where exceptions and accountability reside.
• How released capacity will be converted into value.
• Which boundaries the enterprise is willing to make permeable.

These are constitutional decisions.

They determine how power, responsibility, knowledge, and consequence move through the organization.

The technology makes new operating forms possible.

It does not determine which form the enterprise should choose.

Research Conclusion

The enterprise becomes computational when software begins to participate in maintaining the commitments that hold the organization together.

That transition requires more than capable agents.

It requires an architecture of commitments, authority, context, coordination workflows, evidence, disagreement, management, and economics.

The central research conclusion is therefore conditional:

As software gains bounded discretion over action, selected forms of organizational coordination may become computationally maintained.

If designed well, this can reduce coordination delay, improve institutional memory, release managerial capacity, and make complex work more adaptive.

If designed poorly, it can automate ambiguity, propagate contested information, obscure responsibility, and accelerate failure across organizational boundaries.

The question is not whether the enterprise will use agents.

It is whether the enterprise can make its coordinating logic explicit enough to delegate without surrendering institutional control.

Research Progression

This research establishes the evidence base for:

Field Notes

• The Enterprise Becomes Computational
• The Enterprise Brain Is the Wrong Metaphor
• An Institutional Memory That Can Be Wrong
• Management After Machine Coordination
• The Agentic Boundary of the Firm

Framework

• Computational Coordination Architecture

Flagship Publication

• The Agentic Enterprise

How Delegated Software Changes Coordination, Management, and Firm Boundaries

The research defines the evidence.

The Field Notes isolate the emerging theses.

The framework makes the argument operational.

The publication examines the complete institutional consequence.

1. 01

   Coase, R. H. (1937). The Nature of the Firm. Economica, New Series, 4(16), 386–405. https://doi.org/10.1111/j.1468-0335.1937.tb00002.x. See pp. 390–392 on discovering relevant prices, negotiating and concluding contracts, forecasting difficulties in long-term contracts, and leaving details to later direction. Relevant primary full-text scan pages inspected: https://rochelleterman.com/ir/sites/default/files/Coase%201937.pdf.

2. 02

   Malone, T. W., and Crowston, K. (March 1994). The Interdisciplinary Study of Coordination. ACM Computing Surveys 26(1), 87–119. https://doi.org/10.1145/174666.174668. Author copy: https://crowston.syr.edu/sites/default/files/acmcs94.pdf. See Abstract and section 2 on managing dependencies among activities.

3. 03

   Galbraith, J. R. (1973). Designing Complex Organizations. Addison-Wesley. Companion primary article: Organization Design: An Information Processing View. Interfaces 4(3), May 1974. https://jaygalbraith.com/wp-content/uploads/2024/03/infoprocess1974.pdf. See The Information Processing Model. Book bibliographic identity verified, full book not inspected.

4. 04

   Megas, K., and colleagues (December 2025). Cybersecurity Framework Profile for Artificial Intelligence (Cyber AI Profile). NIST IR 8596 iprd, Initial Preliminary Draft. https://nvlpubs.nist.gov/nistpubs/ir/2025/NIST.IR.8596.iprd.pdf. See PR.AA-03, Defend sample consideration on agent identity and privileged-user precautions. This is draft guidance, not a binding standard. For the separate standards initiative, see Source Note 10.

5. 05

   Moreau, L., and Missier, P., editors (30 April 2013). PROV-DM: The PROV Data Model. W3C Recommendation. https://www.w3.org/TR/2013/REC-prov-dm-20130430/Overview.html. See Abstract and model components on entities, activities, derivation and responsible agents.

6. 06

   OWASP GenAI Security Project, Agentic Security Initiative (December 2025). OWASP Top 10 for Agentic Applications 2026, Version 2026. https://genai.owasp.org/download/52117/. See ASI06: Memory & Context Poisoning. Accessible explanatory source: Idan Habler (13 May 2026), Memory Is a Feature. It Is Also an Attack Surface. https://genai.owasp.org/2026/05/13/memory-is-a-feature-it-is-also-an-attack-surface/. The report download was access-restricted in this review.

7. 07

   Stanford Institute for Human-Centered AI. AI and Organizations Lab, research agenda, undated. https://hai.stanford.edu/centers-labs/ai-organizations-lab/aiolab-research. See How does the Org Chart change? and How do Agents change the workforce? This is a research-program signal, not a completed empirical study of managerial change.

8. 08

   Tabassi, E. (January 2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf. See MANAGE 4.1, Table 4, printed p. 33, on post-deployment monitoring, appeal and override, decommissioning, incident response, recovery and change management.

9. 09

   Model Context Protocol contributors. Model Context Protocol Specification, revision 2025-06-18. https://modelcontextprotocol.io/specification/2025-06-18. See overview and architecture. Agent2Agent Protocol project. A2A Protocol Specification, v0.3.0. https://a2a-protocol.org/v0.3.0/specification/. See Agent Cards, tasks and messages. Versioned interface specifications, not proof of trusted institutional coordination or measured integration savings.

10. 10

    National Institute of Standards and Technology (17 February 2026). Announcing the AI Agent Standards Initiative for Interoperable and Secure Innovation. https://www.nist.gov/news-events/news/2026/02/announcing-ai-agent-standards-initiative-interoperable-and-secure. See the three pillars on industry-led standards, open protocols and security and identity research. An initiative announcement, not a completed technical standard.

11. 11

    METR (19 March 2025). Measuring AI Ability to Complete Long Software Tasks. https://metr.org/blog/2025-03-19-measuring-ai-ability-to-complete-long-tasks/. Thomas Kwa (22 January 2026). Clarifying limitations of time horizon. https://metr.org/notes/2026-01-22-time-horizon-limitations/. The latter explains the human-duration metric, uncertainty and limits of extrapolation to deployment reliability. The historical post now includes a warning about outdated static claims and later estimates.

12. 12

    Shao, Y., Zope, H., Jiang, Y., Pei, J., Nguyen, D., Brynjolfsson, E., and Yang, D. (1 February 2026 revision). Future of Work with AI Agents: Auditing Automation and Augmentation Potential across the U.S. Workforce. arXiv:2506.06576v3. https://arxiv.org/html/2506.06576v3. See Abstract and Human Agency Scale. Preprint evidence of preferences and assessed capability, not deployment outcomes.

13. 13

    Brynjolfsson, E., Li, D., and Raymond, L. R. (April 2023, revised November 2023). Generative AI at Work. NBER Working Paper 31161. https://www.nber.org/system/files/working%5Fpapers/w31161/w31161.pdf. See Abstract and customer-support setting. This working-paper version is not interchangeable with later publication versions.

14. 14

    Becker, J., Rush, N., Barnes, B., and Rein, D. (10 July 2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. https://metr.org/Early_2025_AI_Experienced_OS_Devs_Study-paper.pdf. See Abstract and study setting. Historical randomized trial of early-2025 tools in familiar repositories, not a current universal productivity estimate.

15. 15

    Walsh, J. P., and Ungson, G. R. (1991). Organizational Memory. Academy of Management Review 16(1), 57–91. https://doi.org/10.5465/amr.1991.4278992. See p. 61 on historical information used in present decisions, pp. 63–67 and Figure 1 on five internal retention facilities and external archives, and the article’s acquisition, retention and retrieval account. A conceptual model, not validation of a computational enterprise architecture. Publisher record and relevant primary-text scan passages inspected: https://cmapspublic.ihmc.us/rid=1255442505000_1811726224_21686/OrganizationalMemory-Walsh.pdf.

16. 16

    Williamson, O. E. (1979). Transaction-Cost Economics: The Governance of Contractual Relations. The Journal of Law and Economics 22(2), 233–261. https://doi.org/10.1086/466942. See p. 237 on dispute resolution and performance evaluation, p. 246 and n. 46 on governance and monitoring, and p. 254 on uncertainty and transaction-specific investments. Relevant primary article text inspected: https://josephmahoney.web.illinois.edu/BA549_Fall%202010/Session%203/Williamson%20(1979).pdf.