From Agent Mesh to Business Unit

The jump from a network of agents to an Autonomous Business Unit happened when I tried to make the agents work inside a shared business context.

Governance was the first domain where this became unavoidable. A one-shot multi-agent system could take a goal, discover specialists and hand work around. But a governance function cannot operate only from the request in front of it. The people in a governance office already know the policies, the standards, the current posture of the organization and the limits of their own authority. The software version needed the same kind of shared operating context.

My first implementation was crude. The knowledge was inline text. The important idea was not.

I started thinking of the system as a physical office.

The office metaphor

An office has a front desk or switchboard. Work arrives there. The front desk does not perform every specialist task itself. It understands enough about the request and the office to send the work to the right place. Behind it are specialists with narrower responsibilities. Everyone operates inside a common body of rules and shared knowledge.

That metaphor helped me get away from the idea that a single giant agent should know and do everything. A governance office could have intake, policy interpretation, pattern matching, plan assembly, review and communication responsibilities. The roles could be implemented by different agents, but the point was organizational before it was technical.

There were architectural reasons for keeping the agents small. Separation of duties is easier to reason about when one component is not simultaneously interpreting the policy, making the recommendation and approving its own action. It also creates an economic lever. A narrow extraction task does not necessarily need the same model as a high-stakes reviewer. Different roles can use different models, including cheaper or private models, without changing the business unit that contains them.

This is where the multi-agent system started to look less like a software pattern and more like an organization.

From agent mesh to business unit

The phrase Autonomous Business Unit came from my founder head more than my architect head. I was no longer asking whether I could build an elegant multi-agent framework. I was asking whether a platform could eventually let a company automate part of an actual business unit.

The distinction matters. "Multi-agent system" describes the implementation. "Business unit" describes what the buyer cares about.

A procurement leader does not begin a job with a prompt containing every possible scenario. They learn the landscape. They understand current suppliers, policy, budgets, approval patterns, systems, exceptions and the people around them. Over time they become able to operate inside that environment. An ABU should be treated the same way. Give it the policies, the current portfolio, the systems, the capabilities, the operating rules and the outcomes it is responsible for. Let the platform construct or connect the specialists it needs.

This idea showed up in other work too. In SemForge, for example, the input could be an unfamiliar database schema. Rather than asking the enterprise to manually specify every analytic role and every useful question, the system could inspect the environment and forge specialists that generate and test the questions that ought to be answerable from that schema.

The larger product idea was becoming clearer: do not make the enterprise design the AI organization in advance. Let it connect what it already has, then let the platform discover enough of the environment to assemble the specialist organization needed to operate against it.

Services made the opportunity easier to see

Sequoia's 2026 essay Services: The New Software gave me another way to frame the opportunity. Its argument was that AI-native companies would increasingly sell the work rather than merely sell a tool to the professional doing the work. That matched the direction I had been circling. The more interesting question was not how to give a governance professional or procurement professional another copilot. It was how much of the service itself could be operated by software.

Governance was a useful place to test that thought because it is full of rules, policies, recurring analysis, evidence gathering and escalation. Procurement, tax preparation, marketing operations and other service-heavy functions have the same basic attraction. They contain work that is complex enough to require judgment but structured enough that a machine organization can begin to take on meaningful portions of it.

That does not imply full autonomy. I do not believe we are there.

Autonomy stops where human authority still matters

In my mental model, humans remain responsible for defining the outcome, connecting the knowledge the unit is allowed to rely on, setting the playground and its guardrails, and occupying consequential decision nodes.

An agent can recommend that a supplier should not be renewed. That does not mean the agent should have the authority to terminate the relationship. A procurement ABU might gather the evidence, identify the applicable policy, compare alternatives and prepare the transaction. A human may still own the decision that binds the enterprise.

This is why I am careful with the word autonomous. The direction of travel is toward progressively autonomous execution inside bounded areas, not a claim that an enterprise can or should remove human judgment and accountability.

The human role changes, though. Instead of manually stitching every step together, the human increasingly defines the environment in which machine specialists can operate and steps in where authority, ambiguity or consequence demands it.

That is also why "assistant" became an unhelpful word for me. It had come to mean almost any chat interface with a model behind it. The system I was trying to build was not waiting beside a human to answer questions. It was beginning to own a bounded body of work.

Context changed the nature of the system

The first shared knowledge in the governance ABU was inline. But once the office metaphor existed, the requirements multiplied naturally. The office had to absorb new policies. It had to know when a new specialist or technical capability appeared. It had to communicate outward. It had to receive work from more than a chat window. It had to keep operating even as pieces underneath it changed.

This brought me back to the same problem I had seen with brittle automation. If I hard-wired the ABU to today's agents, tools and policies, I would simply have built a more fashionable version of the old workflow.

The business unit needed an environment around it that could keep the unit current while allowing the specialists inside it to remain small and replaceable.

That was the point where "orchestrator" stopped being a sufficient description.