Where ACC Fits in the Agent Stack: Transport, Runtime Control, and Business Authority

Connecting an AI agent to a tool is becoming easier. Letting that agent operate a real business system responsibly is still a different problem.

Imagine an existing commerce system with APIs for reading orders, changing inventory, creating refunds, and disabling staff accounts. OpenAPI can describe the endpoints. A tool protocol can make them discoverable. An agent framework can select an operation and generate arguments.

But those pieces do not, by themselves, answer several business questions:

These questions sit between tool connectivity and final business authorization. That is the layer the Agent Capability Contract, or ACC, is designed to describe.

Consider this API operation:

paths:
  /orders/{order_id}/refund:
    post:
      operationId: createRefund
      parameters:
        - in: path
          name: order_id
          required: true
          schema:
            type: string
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              required: [amount]
              properties:
                amount:
                  type: number
                  minimum: 0

This is enough to describe how to call the operation. It is not enough to describe how an agent-facing system should treat it.

ACC adds a small, machine-readable declaration next to the operation:

x-agent-capability:
  version: 1
  enabled: true
  scope: refund.create
  risk:
    level: high
  subject:
    required: true
  approval:
    required: true
    when:
      - param: amount
        op: ">"
        value: 1000
  audit:
    sensitive: true
  execution:
    readonly: false
    idempotent: true
    timeout_ms: 10000

The declaration does not grant the refund. It tells a compatible runtime how the operation should be presented and governed before the business system receives the call.

It helps to separate the stack into responsibilities.

These layers are complementary. A deployment can use OpenAPI, MCP, a runtime hook framework, OPA or Cedar, an approval system, and ACC at the same time.

ACC does not need to replace any of them to be useful.

OpenAPI is the right place for HTTP methods, parameters, request bodies, responses, and reusable schemas. ACC deliberately reuses that information instead of creating another parameter language.

The missing information is operation-level governance meaning. POST /refund

tells a runtime very little about whether the operation should be visible to an agent, whether a trusted subject is required, or whether an approval intent should be created for a particular argument value.

That metadata is not a replacement for the interface description. It sits beside it.

MCP helps applications and models connect to tools, resources, and prompts. A2A addresses communication and collaboration between agents.

Both can transport additional metadata. A binding could carry ACC declarations through MCP or an A2A extension. But making the declaration identical to one transport would make it less portable.

Some systems call HTTP APIs directly. Some expose MCP tools. Some use an internal gateway. Others will use protocols that do not exist yet. The governance meaning of refund.create

should be able to survive those changes.

That is why ACC treats protocol bindings as adapters around a small contract rather than making one protocol the owner of the semantics.

Runtime control specifications and secure gateways are important. They define interception points around a live invocation and actions such as allow, deny, modify, , or audit.

Those hooks answer where and how a decision can be enforced.

ACC answers a different question: what portable governance meaning does the business operation declare?

A hook can read an ACC declaration. A gateway can compile it into local policy. A control plane can combine it with runtime context. None of those enforcement architectures becomes unnecessary, and ACC does not pretend that a declaration enforces itself.

The most important boundary in ACC is the separation between reach and authority.

ACC governs reach. The business system retains authority.

For a refund, the runtime may verify that the operation is agent-visible, high risk, subject-bound, and approval-aware. The business system must still verify that the user can access the order, the order is refundable, the amount is valid, the tenant boundary holds, and the refund has not already been completed.

This separation matters because authorization depends on identities, resources, tenant data, current state, and organization-specific policy. Turning ACC into a universal authorization language would make the core larger while making the result less portable and less trustworthy.

Those systems are valuable local policy and enforcement mechanisms. They can decide whether a request is allowed using deployment-specific identities and context.

ACC can provide a common operation-level input to them:

ACC declaration
      +
trusted subject and invocation context
      +
runtime decision and business authorization path

The value of the contract is not that it can express every enterprise rule. It is that different tools can start from the same portable declaration instead of forcing each gateway, agent framework, and control plane to invent unrelated metadata for the same business operation.

It is tempting to add workflow definitions, tenant injection rules, approval ownership, retention periods, compensation logic, organization roles, and a general expression language to one schema.

Most of those concerns are real. They are also difficult to define consistently across runtimes and organizations.

ACC keeps them outside the core when they require private identity models, fresh business data, deployment-specific UI, enterprise compliance policy, or transaction coordination. This is not a claim that they are unimportant. It is an attempt to keep each responsibility in the layer that can actually enforce it.

The contract is intentionally thin:

A portable field is only useful when different implementations interpret it consistently.

ACC therefore separates conformance profiles for parsers, generators, runtimes, and policy components. Its public conformance corpus covers parsing, exposure, subject handling, conditional approval, strict comparison behavior, and security invariants.

This is still early work. A schema and a reference checker do not prove that every deployment is secure. They do make disagreements observable and give independent implementations a shared place to contribute evidence.

The most useful next steps are not to turn ACC into an all-in-one platform. They are to improve composition:

If agents are going to operate orders, inventory, refunds, staff records, and internal workflows, connectivity alone will not be enough. The ecosystem needs a portable way to describe the governance meaning of the operations being connected.

ACC is one open proposal for that layer.

Technical criticism, alternative bindings, conformance evidence, and independent implementations are welcome. The goal is not to give one product special status. It is to make the layer precise enough that multiple products can implement it independently.