We should not confuse agent orchestration capabilities with an Agent Orchestrator platform. The enduring architecture is simpler: expose enterprise capabilities through thin, governed APIs; let authorized AI harnesses discover and compose them; and treat the harness as the Agent Runtime rather than as a mandatory central platform.

That means:

  • REST/OpenAPI for service contracts

  • OAuth/OIDC for identity and authorization

  • MCP or equivalent open mechanisms for machine-readable discovery where useful

  • the harness for execution, skills, scheduling, state, policy and orchestration

The harness might be a coding assistant, a local application, a cloud service, a domain-specific runtime or a custom application. The capability should survive replacement of any one of them.

I’m not disputing the need for orchestration capabilities; I’m disputing the assumption that those capabilities imply an enterprise Agent Orchestrator platform.

The market framing

The market is converging around the idea that enterprises need an orchestration or control layer for AI agents. Gartner describes a fragmented market in which BOAT, BPA, AI agent platforms, iPaaS and open-source frameworks can all provide agent orchestration, and frames the emerging competition as one over control of enterprise execution:

McKinsey uses the term agentic mesh for a composable, distributed and vendor-agnostic orchestration layer connecting agents and traditional systems. Its proposed capabilities include discovery, registries, authentication and authorization, observability, evaluations and governance. It also identifies repeatable and executable actions through secure APIs as foundational infrastructure for agentic systems:

There is clearly a real set of capabilities here. The questionable step is the move from capability to mandatory central platform.

Old wine in new bottles

This closely resembles the integration-platform discussion. Integration platforms and iPaaS products solved real problems, but the architectural mistake was allowing the product to become the architecture, effectively making all integration depend on one central platform.

The same pattern is emerging again around agent orchestration. Workflow execution, tool invocation, authentication, state, scheduling, retries, audit, observability, policy and human approval are all legitimate needs, but most are familiar software and integration capabilities. The genuinely new part is that an LLM can decide dynamically what to do next, and multiple autonomous runtimes can collaborate. That creates a need for orchestration capabilities; it does not automatically create a need for a new enterprise platform category.

The harness is the Agent Runtime

A harness gives an AI model the ability to do useful work by combining instructions, skills, tools, context, permissions, execution semantics and guardrails. Increasingly, harnesses also provide scheduling, state, evaluation and observability. In practical terms, that is already an Agent Runtime.

It might be Codex, another local runtime, a cloud-hosted service, a scientific runtime or a custom application. There is no architectural reason why all of these must sit beneath one central Agent Orchestrator. The runtime is replaceable; the enterprise capabilities it consumes should be enduring.

Great APIs are the architecture

The durable enterprise asset is the set of business and technical capabilities exposed through stable service boundaries. Applied to AI, the implication is simple: if a capability can be securely invoked through a governed API, any suitable harness can orchestrate it.

The enterprise standard can therefore remain thin:

  • standard web APIs, predominantly REST where appropriate

  • OpenAPI or equivalent machine-readable contracts

  • OAuth/OIDC authentication and authorization

  • clear scopes and least privilege

  • stable versioned contracts

  • consistent auditability and policy enforcement

If business systems, data services and document workflows expose capabilities this way, a suitably capable and authorized harness can use them. A local Codex runtime executing skills on a schedule can orchestrate work. So can a cloud service, a domain-specific runtime or a traditional application.

Discovery does not require a central orchestrator

A predictable objection is that, without a central Agent Orchestration Platform, a runtime needs another way to know which capabilities exist. That is a discovery problem, not an execution-centralization problem.

UDDI, WSDL, OData and OpenAPI all attempted to make services describable and discoverable. Their weakness was that a developer still had to understand the interface and wire it into an application. AI changes that equation because a capable runtime can interpret machine-readable descriptions and decide dynamically how to use the advertised capability.

As described in Old Wine, New Bottles: Why MCP Might Succeed Where UDDI and OData Failed, MCP can connect services to AI runtimes capable of interpreting discovered capabilities rather than merely cataloguing them.

The resulting pattern is straightforward: REST/OpenAPI describes what can be called, OAuth/OIDC governs who may call it, MCP or equivalent mechanisms can help machines discover it, and the harness decides how to compose and execute it. Registries and catalogs may still be useful, but they should describe capabilities rather than become mandatory execution paths.

Governance belongs at durable boundaries

This approach does not weaken governance; it moves governance to places that survive technology replacement. At the capability boundary, authentication, authorization, policy, auditing and data contracts should be enforced. At the runtime boundary, the harness should govern models, skills, tools, execution, observability and human approval.

That lets us change the harness, model provider or execution environment without redesigning enterprise capabilities.

The test

If we replace the agent orchestrator in five years, do we still possess the orchestration capability? If not, we have created a platform dependency rather than an enterprise capability.

Keep the capability when the platform changes

There is a legitimate need for orchestration: scheduling, tool invocation, state, security, policy, observability, evaluation, human approval and coordination. We should resist turning those needs into a mandatory enterprise Agent Orchestrator.

Enterprise capabilities should be exposed through thin, governed standards, while autonomous runtimes and harnesses remain free to discover and compose them wherever they run.

I’m not disputing the need for orchestration capabilities; I’m disputing the assumption that those capabilities imply an enterprise Agent Orchestrator platform.