Agent Capability and Profile Model (ACPM)

Introduction As of mid-2026, the AI agent ecosystem has converged on two adjacent but distinct interoperability problems. The first is how to express a portable, runnable agent definition so that an agent built on one runtime can be executed on another; this is the problem the Autonomous Agent Interchange Format (AAIF) addresses. The second is how to discover an agent within a registry or marketplace; this is the problem the Agent Registry (AREG) addresses. Neither problem encompasses a third, equally common need: describing, comparing, and reasoning about what an agent, the platform running it, the tools it calls, or the underlying model actually offers. Today this information is scattered across marketing pages, ad hoc vendor-specific JSON, ASCII tables in README files, and human-readable documentation that changes shape from vendor to vendor. There is no canonical way to ask, in a machine-checkable way, whether a given subject supports a particular capability and at what fidelity, what evidence backs a trust claim about that subject, what it costs to use, what service level applies, or under what conditions it may delegate work to, or accept delegated work from, another subject. Registries and orchestrators that need this information today either write bespoke parsers per vendor or forgo capability, trust, and cost comparison entirely. This document specifies the Agent Capability and Profile Model (ACPM), a portable, vendor-neutral format for a capability profile: a standalone description of what a subject offers. ACPM is deliberately scoped to be orthogonal to, and composable with, both the runnable agent definition problem and the registry discovery problem; it does not replace either.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Scope ACPM is in scope for: subject identity (agent, platform, tool, or model); declared capability support levels using a dot-namespaced vocabulary; tool-invocation protocol, model, and memory-backend inventories; trust level and attestation evidence; sandboxing characteristics; pricing model and unit cost; service-level commitments; structured rules governing delegation of work between profiled subjects; compliance posture (data residency, certifications, personally identifiable information handling); and profile provenance. ACPM is out of scope for: the execution loop of the profiled subject; registry listing and discovery mechanics; and cryptographic enforcement or verification of any claim a profile makes. ACPM specifies the shape of a trust or signature claim; verifying that claim is the responsibility of the system consuming the profile.

Terminology

ACPM document / profile: A JSON instance conforming to the ACPM profile schema.
Subject: The agent, platform, tool, or model that a profile describes.
Capability: A dot-namespaced runtime feature string a subject may offer, paired with a declared support level.
Producer: Software or a person that publishes an ACPM profile.
Consumer: Software that reads an ACPM profile to make a capability-matching, trust-gating, cost, or service-level decision.
Conformance level: One of the five cumulative conformance levels defined in that a profile satisfies.
Condition: The structured-or-string gating type used in delegation rules, reused without modification from the Autonomous Agent Interchange Format. See .

Design Principles ACPM is built on six design principles:

Claims, not contracts. A profile states what the subject claims to offer. ACPM does not itself verify any claim; a Consumer that requires assurance MUST perform its own verification.
Vocabulary-compatible with AAIF. Capability identifiers SHOULD use the same dot-namespaced strings as the Autonomous Agent Interchange Format's required-capability vocabulary, so an agent's declared needs and a profile's declared offerings can be compared directly.
Composable, not coupled. ACPM cross-references agent definitions and registry entries by identifier reference; it does not import or extend their schemas, so each specification can evolve independently.
Comparable by construction. Every offer-side concept — capability support, trust level, cost, service level — uses a closed, ordered, or structured vocabulary rather than free text, so two profiles can be diffed or ranked mechanically.
Strict by default, extensible at the edges. Every object disallows additional properties, with a reserved extension-key namespace at the document root for forward compatibility and vendor metadata.
Honest about enforceability. Fields describing trust, attestation, and signature are explicitly documented as advisory unless a Consumer independently verifies them. This specification does not imply a cryptographic guarantee it does not provide.

ACPM Document Structure An ACPM profile is a JSON object validated against the ACPM profile schema (JSON Schema draft 2020-12 ). The minimum conformant document requires only two top-level fields: The full object model is organised as follows:

Subject Identity The subject.subject_type field MUST be one of "agent", "platform", "tool", or "model", and the subject.name field MUST be present. The subject.sc_refs array carries structured cross-references, each an object with a "standard" field (a Schema Commons standard code such as "SC-006") and an "id" field (an identifier within that standard's own document, such as an AAIF agent_id or an Agent Registry (AREG) entry identifier). These references are advisory pointers; ACPM does not require the referenced document to exist or be reachable.

Capabilities Each entry in the capabilities array declares a dot-namespaced capability identifier and a support level. The identifier SHOULD reuse the vocabulary already established by the Autonomous Agent Interchange Format's required-capability field (for example, "tool.mcp", "memory.vector", "orchestration.parallel") where the underlying concept overlaps, and MAY extend it with new namespaces such as "vision.*", "audio.*", "reasoning.*", "auth.*", or "state.*" for concepts AAIF does not enumerate. The support field MUST be one of four values: "native" (first-class, fully supported), "emulated" (achieved through a workaround or composition of other features), "partial" (supported with material limitations that SHOULD be documented in the notes field), or "none" (explicitly absent). Declaring "none" explicitly, rather than omitting the capability entirely, allows a Consumer to distinguish "known not supported" from "not yet assessed."

Tool, Model, and Memory Inventories The tools array enumerates supported tool-invocation protocols drawn from the same four-protocol vocabulary as the Autonomous Agent Interchange Format: function, MCP , HTTP, and OpenAPI. Each entry MAY declare a concurrency ceiling and a list of supported authentication methods. The models array enumerates LLMs the subject exposes or routes to (or, when subject_type is "model", describes itself), with provider, model identifier, context window, maximum output tokens, and supported modalities (text, image, audio, video, tool_use). The memory array enumerates supported storage backends and, for each, the memory scopes available on it, using the same backend and scope vocabularies as the Autonomous Agent Interchange Format's memory configuration.

Trust and Attestation The trust.level field is an ordered, five-tier claim: "untrusted" (no claim verified), "sandboxed" (executes under some isolation boundary but claims are otherwise unverified), "verified" (claims checked, even if only by self-certification), "attested" (a named issuer has produced a dated, linkable attestation), and "enterprise" (attested, with organisational accountability typically evidenced by populated service-level and compliance fields). A profile MAY declare any trust level without external verification; this specification places no technical control in front of an inflated claim. A Consumer that gates a decision on trust.level SHOULD check trust.attestation.evidence_url and SHOULD verify that trust.attestation.expires_at, if present, has not passed before relying on an "attested" or "enterprise" claim. See . The trust.sandbox object describes the isolation boundary the subject executes within (none, process, container, or virtual machine) and its network egress policy (none, allowlist, or full). This describes isolation the subject runs under, not isolation a Consumer receives when calling the subject remotely; transport security remains the Consumer's own responsibility.

Cost Profile and Service Level The cost_profile object declares a pricing model (free, usage_based, subscription, tiered, or custom), a currency, a single unit cost (a billing dimension — request, 1000 tokens, minute, or run — paired with an amount), and an optional free tier (included units per day or month). A subject with pricing across multiple dimensions SHOULD publish the most comparable dimension, or publish one profile per pricing tier. The sla object declares uptime percentage, p50 and p99 latency in milliseconds, a support tier (community, standard, premium, or enterprise), and an incident-response commitment for Severity 1 incidents. These figures MAY represent either contractual commitments or observed historical performance; this version of ACPM does not yet distinguish the two, which is a known limitation.

Delegation Rules The delegation_rules array governs whether the subject may hand work to ("outbound") or accept work from ("inbound") another profiled subject. Each rule MAY scope itself to a specific counterparty profile, a specific capability, a minimum counterparty trust level, and an additional Condition (see ), and MUST declare an action: "allow", "deny", or "require_approval". At least one of the target fields SHOULD be present per rule, though this is authoring guidance rather than a structural requirement, so that intentionally broad direction-only rules remain expressible. When a rule's action is "require_approval", a Consumer MUST obtain explicit approval before proceeding with the delegated work; treating "require_approval" as equivalent to "allow" is a conformance violation.

Compliance The compliance object declares data residency regions (EU, US, UK, APAC, or custom), a free-form list of held certifications, and a PII-handling mode (none, redact, encrypt, or forbidden).

Condition Expressions The delegation_rules[].condition field accepts a Condition value, reused without modification from the Autonomous Agent Interchange Format. The structured form (RECOMMENDED) is an object naming an expression language and an expression: Supported languages are jsonpath, jmespath, cel (Common Expression Language), jsonlogic, always (constant true), and never (constant false). A bare string is also accepted as a non-deterministic, natural-language hint and MUST NOT be relied upon for portable, reproducible gating. A Consumer that supports a declared lang MUST evaluate the structured form deterministically. A Consumer that does not support a declared lang MUST treat the rule as unsatisfiable-unknown and apply a conservative default — deny for an outbound rule, reject for an inbound rule — rather than silently treating it as satisfied.

Conformance Levels ACPM defines five cumulative conformance levels. As with the Autonomous Agent Interchange Format, conformance is self-certified; there is no central certifying authority.

Level	Requirements
Basic	Validates against the profile schema; subject present.
Tooled	Basic + capabilities array non-empty.
Trusted	Tooled + trust.level is verified, attested, or enterprise.
Priced	Trusted + cost_profile present.
Enterprise	Priced + sla present + compliance present + provenance.signature present.

A profile claiming a given level satisfies every predicate of all lower levels as well. At the time of writing, ACPM does not yet have a machine-readable conformance report schema or public test corpus comparable to those defined for the Autonomous Agent Interchange Format; level claims are presently verified by inspection against this table rather than by an automated suite.

Related Work and Mapping to Prior Art ACPM's overall design intent parallels the Open Cybersecurity Schema Framework: one canonical schema so that disparate parties describe the same kind of thing — there, security events; here, agent capabilities, trust, cost, and service level — in a comparable way. Three further efforts overlap with ACPM closely enough to warrant explicit discussion rather than a one-line table entry. The first is ("HACP: A Capability-Contract Protocol for AI Agents and Edge Hardware"), an active IETF individual submission defining a JSON-RPC 2.0 protocol through which an LLM agent discovers, plans, executes, observes, and audits operations against physical edge hardware (GPIO, I2C, UART, sensors) via a security-checked daemon. Its servers register an immutable tool set at startup, each tool carrying a risk level from zero to three, and a session is capped at a configured maximum risk level that it MUST NOT exceed when executing a tool. This is the same underlying idea ACPM generalizes — declare what a subject can do, and at what risk or trust tier, before a consumer relies on it — but HACP is narrowly scoped to hardware control, statically declared with no dynamic capability negotiation, and organized around risk tiers rather than ACPM's combination of trust, cost, service level, and delegation. HACP is cited here as a narrow, complementary precedent for capability-contract thinking, not as a competing general-purpose effort. The second is a still-forming discovery-metadata effort within the Model Context Protocol itself. The MCP development roadmap , as published 2026-03-05, lists under "Transport Evolution and Scalability" a planned "MCP Server Cards" standard: structured server metadata exposed via a well-known URL so that browsers, crawlers, and registries can discover a server's capabilities without connecting to it, attributed to a "Server Card WG" coordinating with what the roadmap calls "the broader industry AI-catalog effort." This is directly adjacent to an ACPM profile with subject_type "platform" or "tool": both are machine-readable, well-known-style capability and metadata documents intended for discovery without a live connection. The relevant framing is superset and instance, not competition: MCP Server Cards are scoped specifically to MCP servers, while ACPM is protocol-agnostic, spans agent, platform, tool, and model subjects, and additionally expresses cost, service level, trust, and delegation that a server card is not designed to carry. An ACPM profile of subject_type "tool" describing an MCP server SHOULD be designed so that its capability- and protocol-relevant fields are exportable as, or trivially mappable to, a future MCP Server Card. Because the Server Card WG appears to have only just been chartered as of the cited roadmap snapshot, this mapping is necessarily provisional; see PUBLISHING.md Section 0 for the re-check required before any concrete compatibility claim is finalized. The third is the Agent Bill of Materials (AgBOM) concept referenced by the OWASP Agent Observability Standard (AOS) project , which proposes inventorying what an agent or system is built from — models, tools, dependencies — using existing software-supply-chain formats such as CycloneDX, SPDX, and SWID. AgBOM overlaps with ACPM's subject, tools, and models inventory fields, but its center of gravity differs: AgBOM concerns supply-chain provenance and inventory (what is inside a subject, for vulnerability and license tracking), while ACPM concerns runtime capability, trust, cost, and service-level declaration (what a subject can do, and on what trust and cost terms it can be relied upon). The two are complementary; a profile's subject.sc_refs array MAY point at a companion AgBOM document for supply-chain detail ACPM itself does not capture. No effort found during this review combines capability support level, trust and attestation, cost, service level, and delegation rules into a single vendor-neutral document spanning agent, platform, tool, and model subjects the way ACPM does. The closest individual pieces — HACP's risk tiers, MCP Server Cards' discovery metadata, and AgBOM's inventory model — each cover one facet of this narrowly and within a single domain. What is new in ACPM is the combination and its cross-domain generality, not any single constituent idea in isolation. Domain-Adjacent Efforts (Informative)

Effort	Scope	Overlap with ACPM	Relationship
HACP (draft-sunyi-hacp-protocol-00)	JSON-RPC capability-contract protocol for LLM agents controlling physical edge hardware, with static per-session risk-level caps (0-3).	Capability declaration plus trust/risk-tier gating, similar in spirit to capabilities[] and trust.level.	Narrow, complementary precedent; hardware-only, no cost/SLA/delegation model.
MCP Server Cards (planned, MCP roadmap, 2026-03-05)	Well-known-hosted structured metadata for MCP servers, for discovery without connecting; owned by a newly forming Server Card WG.	Discovery-oriented capability/metadata document using the same well-known publication pattern as an ACPM tool/platform profile.	ACPM as superset/general case; Server Cards as the MCP-specific instance. Still forming; re-check before finalizing compatibility claims.
AgBOM (OWASP Agent Observability Standard project; builds on CycloneDX/SPDX/SWID)	Supply-chain inventory of what an agent or system is built from, for vulnerability and license tracking.	Declarative inventory overlap with subject/tools[]/models[].	Complementary, different center of gravity: AgBOM is provenance, ACPM is runtime offering. sc_refs[] may point at a companion AgBOM document.

Open Container Initiative image manifests: An OCI image manifest declares what is actually present in an image, not merely what was intended. ACPM's capability support levels (native, emulated, partial, none) apply the same "declare what is actually there" discipline to agent capabilities.
NIST capability maturity models: ACPM's four-level support axis is a simplified maturity assessment in the spirit of staged capability maturity frameworks, scoped to a single binary-leaning feature rather than an organisational process.
Cloud provider service catalogs: Service catalog listings (for example, marketplace entries for managed cloud services) enumerate what a service exposes and its operational limits. ACPM's tools, models, and memory inventories serve an analogous purpose for AI agent capabilities.
Agent2Agent (A2A) Agent Cards: An Agent Card is a deliberately minimal discovery document advertising identity, capability tags, and an endpoint URL. ACPM extends this with an explicit trust, attestation, sandbox, cost, and service-level model that an Agent Card does not specify, while remaining compatible in spirit with the discovery use case.
Model Context Protocol (MCP) capability negotiation: MCP servers and clients negotiate supported capabilities at connection time via an initialize handshake. ACPM's tools array is a static, publishable analogue of that runtime negotiation, suitable for offline comparison before a connection is ever established.

Security Considerations ACPM is a claims format, not a verification protocol. Every field in a profile MUST be treated by a Consumer as a self-reported claim by the subject, or by whoever published the profile on the subject's behalf, unless the Consumer independently verifies it. This specification does not provide, and does not imply, a cryptographic guarantee of any claim's accuracy. A profile MAY declare trust.level "enterprise" with no supporting evidence. A Consumer making a consequential trust decision SHOULD require a verifiable attestation (method "third_party" or "formal_audit") with a reachable evidence_url and an unexpired attestation.expires_at before relying on an "attested" or "enterprise" claim. Capability support claims are asserted, not tested, by this specification. A Consumer performing capability matching for a safety-relevant feature SHOULD independently probe the subject before trusting a "native" support claim for that purpose. Cost and service-level claims are point-in-time and unverified. ACPM does not currently distinguish a contractually committed figure from an observed historical one. A Consumer making a procurement or routing decision of consequence SHOULD corroborate such claims against independent monitoring. The provenance.signature field is advisory. ACPM does not mandate a signature scheme, key-distribution mechanism, or verification behaviour. A Consumer that requires provenance assurance SHOULD treat a profile lacking a signature it can independently verify as equivalent to trust.level "untrusted", regardless of what trust.level the profile itself declares. A delegation rule naming a Condition language a Consumer does not implement MUST be treated as unsatisfiable-unknown, with a conservative default applied (deny for outbound, reject for inbound). Silently treating an unsupported Condition as satisfied is a conformance violation and could permit unintended delegation. Nothing in ACPM cryptographically binds a profile document to the real-world subject it claims to describe, beyond the advisory subject.sc_refs cross-reference. A Consumer SHOULD only trust profiles obtained from a channel it already trusts (the subject's own domain, or a registry it already trusts) rather than an arbitrary, unauthenticated URL.

IANA Considerations This document requests no IANA actions. ACPM's capability identifiers (the dot-namespaced strings used in the capabilities array) currently form an open, convention-based vocabulary shared informally with the Autonomous Agent Interchange Format's required-capability vocabulary, with no registry operator. A future revision of this document or an accompanying document may propose a community-operated or IANA-operated registry for capability identifiers, analogous to the extension registries described for the Autonomous Agent Interchange Format, should the vocabulary's growth warrant centralised coordination.