Services Become Software-Defined

I originally thought the product would be the platform.

If Autonomous Business Units were going to be useful, then surely the opportunity was to build the place where companies could create them: define the business outcome, connect the knowledge, add the systems and tools, configure the human decision points, and let the platform assemble the specialist workers required to operate the unit.

That was the founder version of the idea. Then I realized I was getting ahead of myself.

Before there can be a platform for creating ABUs, an ABU itself has to be proven. Somebody has to show that a bounded software-defined office can receive real work, make decisions across several domains, involve people when needed, communicate outward, and progress a business case from intake to outcome. That is why I kept returning to examples such as procurement, governance, tax preparation, renewals and marketing operations. They were not random use cases. They were attempts to find a service unit small enough to prove and substantial enough to matter.

First prove the unit

A platform is an abstraction of repeated success. If I cannot make one Procurement ABU useful, there is little value in giving somebody a platform that can generate fifty different kinds of ABUs.

The sequencing therefore matters:

Prove one operating unit. Prove that the shape repeats. Then abstract the platform.

Procurement is attractive because almost every enterprise understands the work and the function is not tied to one industry. Governance is useful because it forces policies, shared knowledge, specialist roles and human authority into the design. Tax preparation is useful because it is already purchased as a service and combines structured rules with exceptions, document intake, analysis, review and customer interaction.

Each one tests the same question from a different angle: can software stop being merely the tool used by a service organization and begin to constitute part of the service organization itself?

From software that helps do the work to software that does the work

For most of the software era, the commercial boundary was clear. A business employed people to perform a function and purchased software to make those people more productive. The software recorded the work, routed the work, analyzed the work or gave the worker a better interface.

Generative AI and agents have started to blur that boundary. A system can now interpret a request, gather evidence, choose among tools, communicate, revise a plan and hand a consequential decision to a person. That means the product no longer has to stop at productivity.

Sequoia Capital described this shift in 2026 as moving from selling the tool to selling the work. I agree with the direction. The question I keep coming back to is architectural: what has to exist behind that promise before the customer can safely buy the work?

My answer is increasingly the ABU.

A service delivered through software cannot simply be a model with a prompt and a collection of APIs. It needs the things a functioning office needs: intake, specialist roles, common operating knowledge, permission boundaries, escalation, communication, continuity of state, evidence, and human decision points. It needs a harness around the agents and a business outcome that defines when the work is actually complete.

That is what makes an ABU closer to a software-defined service organization than to another application.

A rentable operating unit

The commercial model I imagine is not pure SaaS and not traditional outsourcing. It is a hybrid.

A customer could rent a Procurement ABU much as it rents a software platform today, but what gets configured is not only screens and workflows. The unit is connected to the customer's policies, approved suppliers, systems, authority limits, knowledge sources, human decision makers and business measures. The reusable part is the operating shape. The enterprise-specific context is supplied by the customer.

The result could have a standing subscription for the configured unit, usage charges for the work it performs, and, where attribution is clean enough, an outcome component tied to savings, cycle time, recovery, conversion or another measurable result.

That feels more natural than seat pricing. If the product is performing work, the customer should not have to buy more seats because more work arrived.

The unit of value moves from access to software toward operating capacity.

This is also why I do not think of Vyuham as another Salesforce-sized platform. The better analogy is a much smaller, bounded and configurable operating environment for a specific business unit. One enterprise may instantiate a narrow Renewals ABU. Another may configure a broad Procurement ABU. An SMB may combine several functions into one unit. A large enterprise may keep them separate and let the capability map coordinate work between them.

The platform only becomes interesting after enough of those units have been proven that the common shape is obvious.

Why the service boundary matters

Calling this a service organization delivered through software changes the design incentives.

If I sell a tool, I can measure adoption, seats, sessions and feature usage. If I sell the work, those metrics become secondary. The important questions are whether the case completed, whether the result was correct, whether policy was followed, how long it took, how much human attention was required, and what the outcome cost.

That is a healthier pressure on the architecture. A customer does not care how clever the internal agent topology is. The customer cares that the procurement request was processed correctly, that the tax filing was defensible, that the governance recommendation was evidence-backed, or that the renewal reached the right disposition.

The service boundary also forces a graceful relationship with humans. The machine does not need to pretend that every case can be completed autonomously. It needs to know when a human decision is part of completing the service. That human may be the customer's legal approver, budget owner, risk authority or business manager. Their participation is not a failure of automation. It is part of the operating model.

The platform comes after the pattern

I still believe there is a platform opportunity here.

If several ABUs can be made to work, the repeated machinery becomes visible: front office, specialist workers, shared knowledge, capability discovery, external communication, authority boundaries, human decision nodes, evidence, SDAL, observability, cost controls and lifecycle management.

At that point the platform can help an enterprise configure a new unit rather than engineer the entire runtime from scratch. It can provide the scaffolding while leaving the actual business knowledge, authority and outcomes to the enterprise.

But the platform should remain downstream of proof. I would rather demonstrate one office that reliably performs real work than a beautiful studio that can generate a hundred offices nobody trusts.

That is also why the economics matter so much. Once the customer buys operating capacity rather than seats, the provider has to understand what it actually costs to produce a business outcome, how much human work remains inside the service, and how the unit behaves when demand changes.

That leads to a property I was thinking about even while naming the ABU: elasticity.