Autonomous Business Units

The phrase Autonomous Business Unit came from a founder's instinct more than from a technical taxonomy. I was no longer satisfied with building a clever multi-agent system. I was asking whether a company could hand a bounded business outcome to software and have that software operate enough of the function to resemble a real unit of work.

That shift in language mattered. "Multi-agent system" describes an implementation. "Business unit" describes responsibility.

An ABU is therefore not defined by how many agents it contains. It is defined by whether it can accept work, coordinate specialists, use shared business knowledge, involve humans where needed, interact with the outside world, and progress an end-to-end outcome inside a bounded operating environment.

The smallest working ABU

I think the smallest useful ABU needs five things.

First, it needs a way to interact beyond itself. Today that may be email. Tomorrow it may include voice, messaging, portals, APIs or other channels. A business unit that cannot receive work from people or systems and communicate results back out is still only an internal automation.

Second, it needs a front office. The front office is the intake and coordination function for the unit. It understands enough about incoming work, the state of the case and the available workers to decide who should be engaged next. It is closer to a switchboard than to an all-knowing super-agent.

Third, it needs specialist workers. Those workers can be small agents, deterministic services or, where appropriate, humans. One may interpret policy. Another may gather evidence. Another may analyze a contract. Another may prepare a communication. Their roles can be separated for risk, economics and clarity, and the model underneath each role can change over time.

Fourth, the unit needs shared knowledge. The office has to know the policies, current portfolio, operating rules and other context required to do its job. That knowledge is not a giant prompt. It is part of the environment the harness makes available to the workers, and it needs to stay current as the business changes.

Fifth, the ABU has to own an end-to-end outcome. That is the line between an ABU and a workflow of cooperating agents.

A workflow completes steps. An ABU is responsible for progressing the case.

A Renewals ABU, for example, should not stop after extracting contract terms or drafting an email. It should be capable of taking a renewal case from intake through evidence gathering, analysis, communication, required human decisions and the permitted follow-through until the case reaches a legitimate outcome.

That outcome may still depend on another ABU, an external system or a human authority. End-to-end responsibility does not mean every skill lives inside one office. It means the unit owns the progression of the work rather than dropping responsibility at the boundary of its own agent.

The office is a better metaphor than the chatbot

The word assistant has become so broad that it often means little more than a conversational interface. That is not the model I have in mind.

A real office contains an intake point, people with different specialties, common operating knowledge, escalation paths, decision rights and ways to communicate with customers, suppliers and other parts of the organization. The office does not require one employee to know everything. It requires the organization around those employees to make their combined work coherent.

The ABU follows the same shape.

The front office receives a request. It understands the current objective and context. It may engage one worker, then another. It may ask an external capability for help. It may need to contact a person for information or authority. The workers can remain narrow because the harness carries the context and state that belong to the office as a whole.

This is also why the ABU is a useful boundary for the harness. The unit has a mandate, shared knowledge, a population of workers, human decision points, external channels and an operating history. Those things persist even when individual agents or models are replaced.

ABU boundaries follow the enterprise

There should not be one canonical ABU topology.

A small business may reasonably put procurement, renewals, supplier communication and finance-adjacent work into one broad operations ABU. The same few humans may already span those responsibilities, and there may be little value in reproducing Fortune 10 organizational boundaries inside software.

A large regulated enterprise may make the opposite choice. Procurement, legal review, supplier risk, technology renewals and financial approvals may belong in different ABUs because their knowledge, authority, accountability and scale are different.

The common architecture should support both.

Inside an ABU, the front office should normally prefer its own workers. When it needs a capability outside the unit, it can request that capability from the enterprise's living capability layer. The other ABU may then provide the service through its own front office and workers.

This keeps the internal organization flexible while making cross-unit collaboration explicit.

Humans do not disappear from the unit

It is tempting to describe an ABU as an autonomous machine team with a human approval button. I think that framing is too crude.

There are at least three distinct human relationships to an ABU, and they should not be collapsed into one generic "human in the loop."

The first two roles may belong closely to the ABU. The third often does not.

A Renewals ABU may analyze the evidence and recommend renewing a supplier at a certain amount. A procurement leader, budget owner, legal reviewer or security leader may still hold the decision right required for the transaction. Those people are not necessarily members of the ABU's permanent workforce. They are enterprise actors the ABU must know how to engage.

That interaction is part of the runtime. The ABU may email a business owner for context, route an approval request to a manager, ask legal for a decision or wait for a human to accept a risk. When the decision arrives, the unit should resume the work with the new state and authority captured.

This is a more faithful model of enterprise execution than treating the human as a final checkpoint after the machine has done everything else.

The Steward and Outcome Owner are different jobs

I initially leaned toward one highly capable configurator who understood the whole ABU. I still think that role will be important, but I no longer think it should absorb business accountability.

The ABU Steward is closer to an organizational systems engineer. This person shapes the machine office: which knowledge is connected, what policies apply, which capabilities are available, how authority is bounded, where human decisions sit and how the harness is configured. They do not have to hand-code every workflow because the point of the ABU is to preserve dynamic execution.

The Business Outcome Owner has a different concern. Are the business metrics moving? Is cycle time improving? Is spend falling? Are customers receiving the right outcome? Is risk acceptable? This person should not need to understand every worker or model underneath the unit.

In a small business, the same human may fill both seats. In a large enterprise, separating them will usually make more sense.

Decision makers remain part of the future workforce

The third bucket is especially important because it changes how I think about workforce transition.

Today's managers and subject-matter leaders do not exist only because software is missing. Some of them hold real organizational authority. They decide whether to commit money, accept risk, approve an exception, change a customer outcome or make another consequential choice.

An ABU can prepare those decisions extraordinarily well. It can gather the evidence, reconcile records, apply policy and present a recommendation. That does not automatically mean the decision itself should become machine authority.

Over time, some decision nodes may become more automated because policy, evidence and organizational comfort become strong enough. Others may remain human by design. The important thing is that the ABU knows which is which.

The future workforce question is therefore not simply which jobs disappear. Roles decompose.

Work that consists largely of finding information, reconciling systems, chasing status, preparing recommendations and coordinating routine execution can move into the ABU. Human work shifts upward toward configuring the machine organization, owning business outcomes, exercising consequential authority, handling relationships and making judgments that the enterprise chooses not to delegate.

The scarce human skill may move from performing the work to configuring, governing and judging the machine organization that performs it.

Autonomy is bounded, not absolute

The name Autonomous Business Unit can sound stronger than the claim I am making.

I am not arguing that a fully autonomous enterprise is possible today. I am arguing for progressively autonomous business execution inside explicit boundaries.

A useful ABU should be able to run much of its own operating loop. It senses incoming work and changes in its environment. It decides what those events mean in the context of its outcome and policies. It acts through workers, enterprise capabilities, external channels and humans. It learns enough about the changed environment to make later decisions with a more current view.

That is SDAL configured for the unit.

The human remains responsible for establishing the playground: the outcome, knowledge sources, policies, maximum authority, human decision nodes and other guardrails. Full autonomy is not required for the economics or organizational impact to become significant.

A different management span

The larger bet is about leverage.

If the harness can carry much of the coordination, context, state and routine execution that human organizations carry today, one human can potentially supervise far more operating capability than one manager can supervise through a conventional human hierarchy.

I would not turn that into a literal promise that one person can run a Fortune 10 enterprise. The near-term claim is more defensible and still disruptive: the ratio between humans and operated business capability can change dramatically.

That is why the ABU matters as an organizational abstraction. The enterprise does not merely deploy more agents. It begins to create machine operating units that can be configured, measured, governed and connected to human authority.

The next sections can then ask what happens to services, economics and the workforce when more of those units become practical.