Why Runtime is Commodity and Governance is the Moat

The Runtime Layer Is Becoming Commodity

Think back to 2008. If you wanted to run a web application, you bought servers, set up racks, hired ops staff. AWS changed the question from “how do I run this?” to “what do I want to build?” Compute became infrastructure. Infrastructure became commodity.

Agent runtime is following the same curve, just faster.

Compare managed runtimes on the functions your deployment needs: execution, state, tool access, recovery, and integration with your existing controls. Verify each capability against current vendor documentation before relying on it.

They are all solving the same problem: where does my agent run?

As execution features become easier to obtain, differentiation can depend on how well a team defines authority, handles exceptions, and maintains evidence. Treat that as a product strategy to test, rather than a forecast about a particular cloud service.

This is not a criticism of Anthropic’s work. Commoditization is how good technology spreads. It is a signal about where to build defensible value.

The Governance Gap Nobody Is Talking About

A runtime evaluation should also ask:

• Who approved this agent for deployment?
• What is its documented scope of action?
• Can you show an auditor every decision it made over the last 90 days?
• If it caused harm, can you reconstruct exactly why?
• Does it meet the requirements of the EU AI Act?

The EU AI Act applies in phases. Under Article 113 as amended in July 2026, the main Chapter III requirements for Annex III high-risk systems apply from 2 December 2027; for Article 6(1)/Annex I systems, from 2 August 2028, subject to transitional provisions. First establish territorial scope, system classification, and your operator role.

Article 9 requires a continuous risk management system, not a one-time review. Risk must be identified, estimated, evaluated, and mitigated throughout the entire lifecycle of the system.

For high-risk systems, Article 12 requires automatic event recording with traceability appropriate to the intended purpose, supporting risk identification and monitoring. Define relevant events and necessary context; it does not require every deployment to store every input and output.

Article 14 requires human oversight measures. The system must be designed so that humans can understand, intervene, and override. Not in theory — in practice, with documented controls.

Annex IV defines the technical documentation that must exist before a high-risk AI system is placed on the market: intended purpose, version history, design specifications, risk assessment, test results, monitoring procedures.

Article 15 requires accuracy, robustness, and cybersecurity standards throughout the lifecycle — with particular attention to errors and faults.

Check which controls the runtime provides and which your organization must configure or operate. A hosting contract alone does not establish compliance; the evidence must cover your actual system, its intended purpose, and the duties assigned to each operator.

Make gaps explicit in the deployment review, with an owner and a tested mitigation for each one.

Why Governance Is the Moat

Runtime is horizontal. The same execution environment works for a legal document agent, a customer support agent, and a supply chain optimization agent. There is nothing domain-specific about it — which is exactly why it commoditizes.

Governance is vertical. What “safe” means for a medical diagnosis agent is different from what it means for a marketing copy agent. The rules that govern a financial advice agent are not the rules that govern an internal HR policy agent. Domain-specific governance constitutions — the precise behavioral boundaries, permitted actions, escalation conditions, and audit requirements for a specific type of agent in a specific regulatory context — are defensible intellectual property.

The AI Act distinguishes duties for providers of general-purpose AI models, including models with systemic risk, from duties for operators of high-risk AI systems. Map those roles before deciding which controls and documentation your deployment needs.

Consider what real governance infrastructure looks like in practice:

Incoming agent request
        |
        v
[Governance Proxy]
  - Verify request against constitutional rules
  - Check permitted action scope
  - Record the decision with selected integrity controls
  - Apply the rules selected for this workflow
  - Wait for human approval where policy requires it
        |
        v
[Runtime] (Managed Agents / LangGraph / custom)
  - Execute only after permission and required approval
        |
        v
[Response]
  - Post-execution logging
  - Deviation detection
  - Execution evidence update

The runtime is interchangeable. The governance proxy is not. It embeds the organization’s specific risk tolerances, the regulatory requirements for its industry, the audit trail format required by its compliance team, and the escalation logic specific to its operating context.

Changing runtimes can require new adapters, permission boundaries, state handling, and failure recovery. Re-test the affected controls and evidence flows before treating governance as portable.

The Proxy Pattern in Practice

The architecture is straightforward to explain and non-trivial to implement correctly. A governance proxy sits between your application and the agent runtime. Every request passes through it. Every response is logged against it.

A minimal version looks like this:

async function governedAgentCall(
  request: AgentRequest,
  runtime: AgentRuntime,
  governance: GovernanceLayer
): Promise<AgentResponse> {
  // Pre-execution: verify, log, potentially block
  const decision = await governance.evaluate(request);

  if (decision.requiresHumanReview) {
    return await governance.escalate(request, decision.rationale);
  }

  if (!decision.permitted) {
    await governance.logRejection(request, decision.rationale);
    throw new GovernanceViolation(decision.rationale);
  }

  const auditId = await governance.openAuditRecord(request, decision);

  // Runtime execution - could be Managed Agents, LangGraph, anything
  const response = await runtime.execute(request);

  // Post-execution: log result, check for deviation
  await governance.closeAuditRecord(auditId, response);
  await governance.detectDeviations(request, response, decision);

  return response;
}

The runtime object is injected. You can point it at Managed Agents today and LangGraph Cloud tomorrow. The governance layer — the evaluate, escalate, openAuditRecord, and detectDeviations logic — stays constant. That is where your compliance posture lives.

What makes this non-trivial is not the pattern. It is what goes inside those governance functions: the constitutional rules that define permitted behavior, the risk scoring that determines escalation thresholds, the hash-chain verification that makes audit records tamper-evident, the formal verification that proves the rules are internally consistent.

That work is the moat.

What This Means If You Are Building on Managed Agents

Evaluate a managed runtime against your team's operational needs and current vendor documentation. Include permissions, data handling, recovery, and the ability to export records your reviewers can use.

Then evaluate the complete deployment against its applicable duties. Runtime features may support risk management, logging, and technical documentation, but your team still needs to demonstrate how those features work in its own system.

Those things require a governance layer that is separate from, and sits above, the runtime layer.

For EU applicability, examine Article 2: relevant routes include placing systems on the EU market, deployers located in the EU, and third-country providers or deployers whose system outputs are used in the EU. A sector label alone does not establish high-risk classification.

Record the applicable dates and the legal source used in your deployment plan. Assign owners for classification, risk review, and evidence maintenance so changes in scope or law trigger a deliberate update.

The Question That Actually Matters

Every conversation in the AI infrastructure space right now is about runtime: which platform is faster, cheaper, more scalable, better integrated. These are real engineering questions worth answering.

But the question that determines whether an AI system can operate in regulated markets, survive an audit, and maintain organizational trust over time is different.

It is not: where does your agent run?

It is: can you prove it is safe?

Runtime is how you execute. Governance is how you prove. One is becoming infrastructure. The other is the moat.

Arbitra is a runtime-agnostic governance layer for AI agents. It works with Managed Agents, LangGraph, and custom runtimes. If you are building agents that need to operate in regulated environments, reach out to learn about our governance infrastructure.