The Missing Runtime

When OpenAI introduced custom GPTs in late 2023, I built a small cohort of executive personas: a CEO, CFO, CMO and CTO. The idea was simple. A founder could pitch an idea and hear it challenged from several business lenses instead of receiving one generic answer. I was not thinking about autonomous business units at the time. I was experimenting with the idea that cognition could be organized into roles.

The marketplace around custom GPTs never became the thing I had imagined, but the experiment stayed with me. I kept looking for a more consequential use of the same idea. I was thinking like a would-be founder, which forced me to get above the technology and ask a different question: what business problem could this actually own?

There was no shortage of candidates. Every large enterprise has work that looks automatable from a distance: fax-to-digital case handling, issue resolution, claims validation against prior authorizations, procurement pipelines, contract renewals, marketing operations. The common pattern was not a lack of software. It was that the automation already in place was often brittle.

The brittle path

RPA and API orchestration can be extremely useful, but both tend to encode a point-in-time understanding of the path. A screen changes and the RPA breaks. An API contract changes and the orchestration breaks. A system is replaced and somebody has to rewire the flow. The business outcome may be unchanged, but the automation is coupled to the machinery that happened to exist when it was designed.

Procurement is an easy example because the problem is domain-independent. The business intent might be straightforward: take a legitimate purchase request from intake to completion while following company policy. The actual path can change depending on the request, vendor, amount, policy, approver, system availability and exceptions. Traditional automation works best when that path can be specified in advance. The interesting possibility with AI was that perhaps the path did not have to be.

If the enterprise exposed useful capabilities through APIs, tools or later MCP-style interfaces, a reasoning system could choose which capability to invoke based on the goal in front of it. The stable object could become the business intent and its constraints, not the sequence of integrations.

That idea became concrete for me in 2025 when I started Vyuham.

The first Vyuham

The early system was deliberately small. I had a user interface, a host orchestrator and a growing set of specialist agents. Those agents described their capabilities through the emerging A2A pattern. The orchestrator could discover what was available and decide which agent to call rather than following a hard-coded workflow.

My examples were almost trivial. Ask for Apple's stock price for the week and email the result. Ask to book a Chicago-to-London trip. The point was not the stock price or the airline ticket. The point was that I stated the goal and the system assembled the path from the capabilities it could find.

That was the first important shift in my thinking. I did not want to design every route through the system. I wanted to describe the outcome and let the system determine which specialists were needed.

As I added more small agents, the limits became visible just as quickly.

Memory arrived before architecture

One of the first failures was embarrassingly simple. I could ask for AAPL prices and get an answer. In the next turn I could say, "compare that to META," and the system did not know what "that" referred to. The agents were callable. The orchestrator could discover them. But every interaction was still too close to a point-in-time invocation.

That is how memory entered Vyuham. Not because I had a grand theory of agent memory, but because an intelligent system that cannot carry forward what just happened is not much of an orchestrator. The stock-price agent did not need to own the conversation. Something above it needed to remember the evolving goal, understand the reference to the previous result and decide what should happen next.

That sounds obvious now. It was important because it changed what I thought the orchestrator was for. It was no longer just a switch that routed a request to the right specialist. It was starting to become the place where the state of the work lived.

The A2A calls in the interface made this visible. I could watch the system discover an agent, invoke it, receive a result and then choose another. The specialists could remain small and self-contained. The intelligence of the overall system was beginning to move into the layer that understood the goal and the environment around those specialists.

The enterprise has always had this layer

Looking back, this was where my enterprise architecture background started to collide with what I was building.

We describe enterprises through applications, capabilities, processes, data, integrations, policies and organizations. Those views are useful. But they do not, by themselves, make the enterprise run. People do the connecting. They remember what happened earlier. They know which source to trust. They notice that a process no longer fits the situation. They find the right person, system or workaround. They carry context across boundaries that our diagrams keep separate.

In other words, the enterprise already has a runtime. Much of it is human.

The interesting question for me became whether some of that runtime could be made explicit in software without falling back into another rigid workflow. The answer was clearly not going to be "add a model to the process." The model could reason, but it still needed memory, context, discovery and a way to operate among changing capabilities.

I did not yet call that surrounding layer a harness. At that point I was still making the orchestrator smarter.

The next jump came when I tried to make the system operate inside a real body of business rules. Governance forced the issue. A general network of agents was not enough. The whole office had to know what world it was operating in.