The Enterprise Execution Harness

I arrived at that conclusion from two directions at roughly the same time.

Inside Vyuham, I was adding more small agents and watching the orchestrator discover them, call them and pass work around. The more modular the agents became, the more obvious it was that the valuable layer was moving upward into the environment that knew what existed, remembered the state of the work and understood enough context to decide what to do next.

Outside Vyuham, tools such as Claude Code made the same point from another angle. I could use a Claude model directly through an API and get a very different result from the experience of using that model inside a product engineered for software development. The difference was not just the prompt. The product surrounded the model with context, tools, state, execution, feedback and recovery.

That gave me the word I needed: harness.

Agents are small. The environment is not.

I think of agents as relatively small, self-contained cognitive units. They can be specialized, swapped out and priced independently. One agent may interpret policy. Another may extract evidence. Another may plan. Another may review. The model underneath each can change without changing the business unit they serve.

But those agents do not become an enterprise by themselves. They need an ecosystem around them.

That ecosystem needs to know which agents and tools currently exist. It needs to carry context across their interactions. It needs to remember the state of a longer-running objective. It needs access to the policies and knowledge that define the environment. It needs to route work, communicate outward and bring a human into a decision when required.

Most importantly, it cannot be frozen to the environment as it looked on the day the automation was built.

This is why I separate the harness from the orchestrator. Orchestration is one function inside the harness. The orchestrator decides what should run next. The harness is the broader operating environment that allows that decision to remain useful as the organization around it changes.

Discovery was the first antidote to rigidity

The early A2A implementation in Vyuham mattered because the orchestrator did not need a permanently hard-coded inventory of specialists. Agents could advertise what they could do. The host could discover them and choose one based on the goal.

The same principle applies beyond agents. If new tools, APIs, data products or capabilities appear in a registry, the operating environment should be able to become aware of them. If one disappears, the system should not continue behaving as if the old path still exists.

This was the direct answer to the brittleness that bothered me in traditional automation. The enterprise changes. The automation should not require a redesign every time the enterprise changes.

Discovery alone is not enough, of course. Knowing that a capability exists does not tell the system whether it is appropriate, authorized or useful for the current objective. That is where context and policy matter. But discovery changes the architecture from a fixed path to a live capability environment.

Then the harness had to learn

The next requirement was continuous learning.

I do not mean that the first version of the harness learned from every human override or automatically retrained a model after each case. That is a later possibility. The first kind of learning was more basic: the world around the ABU changes, and the ABU has to know that it changed.

A new policy is published. A threshold changes. A new technical capability appears in the registry. An old capability is retired. A new knowledge source becomes available. Those changes can alter the decisions the business unit should make tomorrow even if the business objective has not changed.

So the harness needs watchers and listeners. It needs ways to detect changes in its operating environment and bring those changes into the context used for future decisions.

This is what I mean by learning in the first instance. The office keeps itself current.

Human corrections and overrides can eventually become another learning signal. A private-AI pipeline can go further and use accumulated enterprise experience to improve or fine-tune smaller domain models that agents consume. But I would not start there. Before a system can learn from its mistakes, it has to stop being ignorant of the fact that its environment changed.

SDAL came out of SemForge

The four words Sense, Decide, Act, Learn did not begin as a grand enterprise framework. They emerged while I was building SemForge.

The problem there was turning an enterprise database into a living semantic layer. The system had to notice when the underlying schema changed. It then had to decide whether that change created new business meaning, such as a new concept or a new question that could now be answered. It had to act by minting the semantic artifacts required to make that meaning usable. Then the changed understanding had to become part of the next cycle.

In that setting the loop was straightforward:

Sense the change. Decide what it means. Act on that decision. Learn the new state.

Once I saw it there, I could not unsee it elsewhere.

A procurement ABU senses incoming requests, policy changes and capability changes. It decides what those events mean in the context of the business outcome. It acts through the available systems and people. It learns enough about the changed environment to make the next decision with a more current view.

A governance ABU has the same shape. So does a renewals unit, a marketing operation or a claims operation. The details differ. The loop does not.

The loop belongs to each ABU

I do not imagine one giant SDAL loop sitting above the entire company. SDAL is generic. Each ABU should have its own configured loop, connected to the knowledge, events, tools, agents and human decisions relevant to that unit.

Humans configure and connect the knowledge that the loop is allowed to rely on. They define outcomes and guardrails. They remain present at decision nodes where judgment, authority or consequence requires a person.

The enterprise then becomes a mesh of these bounded operating units rather than one omniscient autonomous machine.

This framing also changed how I looked at today's enterprise. I do not think enterprises lack sensing, decisioning, action or learning. They have all four in abundance. The problem is fragmentation.

Sense is scattered across lines of business, systems, reports, queues and teams. Decide is similarly siloed, often with incomplete or conflicting context. Action happens through another set of systems and organizational boundaries. Learning is local, delayed or lost when the people who understood the exception move on.

The opportunity for an Agentic Enterprise is not to invent intelligence where none exists. It is to close those loops in a way that software can participate in without pretending the enterprise is simpler than it is.

The practical bet

I am deliberately not claiming a fully autonomous enterprise. I do not think that is possible today, and I am not sure it is even the useful near-term goal.

The more credible bet is that the ratio between humans and operated business capability can change dramatically. A small number of humans can supervise machine business units that perform much more of the execution themselves. Over time that ratio may become extreme. But the useful way to test the idea is not to start with the entire enterprise.

Start with one contained business unit where the outcome is clear, the knowledge can be bounded, the tools can be connected and the human decision points can be named. Build the harness around that unit. Let the agents underneath it remain replaceable.

That is the advice I would give a CIO today.

Do not spend the next year building prompt-plus-model systems. Start assembling the harness.

Models will improve. Model providers will change. Specialist agents will come and go. The durable advantage is the enterprise environment that can give those agents context, let them discover what they can use, constrain how they operate, carry state across work and keep learning as the organization changes.

Six months from now, I do not expect anyone to remember which model I thought was best. I want them to remember that this was the layer I said to build.