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

NieJingChuan — Wed, 15 Jul 2026 09:22:38 +0000

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:

Which operations may be exposed to an agent-facing surface?
Which invocation must carry a trusted acting subject?
Which operation is high consequence?
When does an invocation express approval intent?
Which calls need stronger audit handling?
Which execution properties should a runtime know before it invokes the API?

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

Start with a concrete operation

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.

The missing layer is not another transport

It helps to separate the stack into responsibilities.

Layer	Primary question
OpenAPI and JSON Schema	What operation exists, and what are its inputs and outputs?
MCP, A2A, and other transport or discovery mechanisms	How are tools or agents discovered, connected, and invoked?
ACC	What portable governance meaning does this business operation declare?
Runtime controls, gateways, and policy components	How is a live invocation inspected, paused, denied, transformed, throttled, or audited?
Business authorization and data	Is this subject allowed to perform this action now, against this resource?
Workflow and transaction systems	How are multi-step work, recovery, and compensation coordinated?

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 describes shape, not agent-facing governance

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 and A2A solve different connectivity problems

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 hooks enforce; declarations describe

Runtime control specifications and secure gateways are important. They define interception points around a live invocation and actions such as allow, deny, modify, pause, 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.

Reach is not authority

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

Reach: what an agent-facing runtime may expose or attempt.
Authority: whether the acting subject may perform the action against the current business state.

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.

Why not use only OPA, Cedar, RBAC, or an API gateway?

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
      +
local policy
      =
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.

A small core is an architectural constraint

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:

interface parameters remain in OpenAPI and JSON Schema;
transport remains in MCP, A2A, HTTP, or another binding;
runtime decisions remain with the runtime and its policy system;
final authorization remains with the business system;
multi-step coordination remains with workflow and transaction systems.

Portability requires testable semantics

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.

What should come next?

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

document a precise ACC-to-MCP binding;
describe how runtime control systems consume ACC fields without changing their meaning;
expand conformance vectors where cross-implementation behavior can be tested;
collect independent implementation and integration evidence;
keep final business authority outside the contract.

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.

Read and review

ACC website: https://agentcapability.org/
Ecosystem landscape and FAQ: https://agentcapability.org/ecosystem/
Specification and conformance: https://agentcapability.org/docs/
GitHub: https://github.com/agent-capability/agent-capability-contract
Proposal process: https://github.com/agent-capability/agent-capability-contract/tree/main/proposals

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.

DEV Community: NieJingChuan