Agent Infrastructure Control Protocol

Introduction Infrastructure control interfaces are commonly designed for human operators, provider SDKs, or declarative reconcilers. An autonomous caller can use those interfaces, but must often reconstruct essential control semantics from many provider-specific reads, natural-language descriptions, asynchronous job APIs, and unstructured error messages. The caller may be unable to determine whether a request was authorized, whether a preview is still valid, whether an interrupted mutation took effect, whether retry is safe, what side effects occurred, or which recovery action is permitted. Generic agent protocols improve invocation and interoperability, but an invocation envelope does not define the meaning of infrastructure control. Two providers can expose tools through the same protocol while using incompatible action names, state models, error semantics, and safety behavior. Conversely, existing infrastructure standards define valuable resource and orchestration models, but generally do not define a complete control contract optimized for an autonomous principal. AICP defines that contract as a linked control loop:

discover the capabilities available to the authenticated principal;
obtain a bounded, freshness-labelled situation;
state an intent, hard constraints, and success criteria;
receive a concrete, expiring plan with material changes, assumptions, unknowns, risk, feasibility, and authorization state;
bind approval and execution to that exact plan revision;
observe a durable asynchronous operation;
verify the actual outcome and side effects; and
reconcile or compensate when effects are uncertain or unacceptable.

The protocol is designed so that each object supplies the decision inputs for the next stage and remains linked to its causes. This permits a different process, agent, or human operator to resume control without relying on a lossy transcript or private model state.

Scope of the Contribution Cloud Infrastructure Management Interface (CIMI) , Cloud Application Management for Platforms (CAMP) , Topology and Orchestration Specification for Cloud Applications (TOSCA) , Kubernetes , and related systems already define infrastructure resources and operations. Model Context Protocol (MCP) and Agent2Agent Protocol (A2A) already define agent integration mechanisms. OAuth, workload identity, and provider policy systems already address identity and authority. AICP therefore does not claim to be the first infrastructure API or the first agent protocol. Its contribution is the interoperable semantic boundary between an autonomous principal and an infrastructure control plane: the representation and lifecycle of situation, intent, exact plan, authority, execution, effect certainty, verified outcome, and recovery.

Layering AICP follows the architectural preference to profile and extend existing Internet protocols rather than define a monolithic agent protocol . It defines a core model and an HTTP binding. Infrastructure vocabularies are supplied by profiles. MCP can expose AICP through a small set of tools, A2A can carry or delegate AICP objects, and provider adapters can map AICP profiles to native APIs. All bindings are expected to invoke the same provider planning, policy, execution, journaling, and verification services. AICP objects can reference existing resource representations rather than copying them. For example, a profile can use Kubernetes objects, a TOSCA service template, or a provider resource identifier as the target or arguments of an AICP action.

Conventions and Terminology 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.

Agent: An autonomous or semi-autonomous software system acting for a principal. A conforming client need not use artificial intelligence.
Principal: The authenticated security principal to which permissions, delegation, quotas, and audit records apply. It can represent an agent, workload, user, or service.
Control plane: A service that reads or changes infrastructure state, directly or through provider adapters.
Resource: An infrastructure object identified by a profile-defined type, provider-stable identifier, and optional scope and revision.
Action: A stable, profile-defined operation or outcome class advertised as a capability.
Situation: A bounded observation of resources, relationships, health, active operations, applicable constraints, and available actions, including freshness and coverage metadata.
Intent: A requested outcome expressed as an action, target, arguments, constraints, and success criteria. An intent is not an instruction to bypass planning or policy.
Plan: A provider-generated, revisioned, and expiring proposal for satisfying an intent, including exact material changes and decision metadata.
Consequential action: An action that can modify infrastructure state, incur cost, expose data, affect availability, alter authority, or produce another externally visible effect.
Operation: A durable representation of an execution attempt and its evolving control and effect state.
Outcome: A durable comparison between intended, expected, and observed effects after an operation reaches a terminal state.
Effect state: The provider's degree of certainty about external effects: none, possible, partial, complete, reversed, or unknown.
Reconciliation: An observation-oriented action used to determine actual infrastructure state when an operation's effects are uncertain.
Compensation: A new consequential action intended to counter some effects of an earlier action. Compensation is not assumed to restore identical prior state.
Profile: An independently versioned specification that defines resource types, actions, schemas, constraints, observations, and additional conformance requirements for an infrastructure domain.

Design Goals and Non-Goals

Goals

Legibility: facts that affect a control decision are represented as typed fields rather than only as prose.
Bounded context: the provider can return a compact decision view with explicit freshness, coverage, truncation, and omissions.
Outcome orientation: the caller states the desired result and constraints separately from the provider's mechanism.
Preview fidelity: a consequential execution is bound to an exact, expiring plan revision and is rejected if that plan is stale.
Authority clarity: feasibility, authorization, approval, and readiness are separate states derived from authenticated context.
Failure legibility: problems disclose retry safety, effect certainty, alternatives, and remediation actions in machine-actionable fields.
Durability: plans, operations, outcomes, and events can outlive a client session and support resumption.
Composability: profiles and bindings reuse existing resource models, authentication, event, telemetry, and evidence mechanisms.
Resource efficiency: clients can cache capabilities, request bounded views, follow deltas, and use structured next actions instead of repeating open-ended discovery.
Binding parity: no transport or agent adapter creates a privileged path around planning, policy, or audit.

Non-Goals This document does not:

define model prompts, private reasoning, chain-of-thought, or agent planning algorithms;
define agent-to-agent conversation or task delegation;
define a global directory of agents or infrastructure providers;
define a universal representation for every cloud or infrastructure resource;
replace provider-native APIs, Kubernetes reconciliation, CIMI, CAMP, TOSCA, OAM, or infrastructure-as-code systems;
define a new authentication, credential, payment, telemetry, signature, or approval protocol;
guarantee exactly-once execution or perfect rollback;
permit a client to self-assert permissions, risk acceptance, or approval; or
require providers to disclose sensitive topology, capacity, policy, or tenant information.

Architecture

Linked Control Objects The AICP control loop consists of seven durable object classes: Capability Document, Situation, Intent Request, Plan, Operation, Outcome, and Problem. An Operation Event is an incremental delivery form for Operation changes. Each object MUST identify or link to the immediately preceding control objects where applicable. A Plan identifies its Intent Request and the Situation on which it was based. An Operation identifies the exact Plan revision. An Outcome identifies the Operation and preserves the expected and observed effects. These links form an audit and resumption graph; they do not expose model reasoning. A provider MAY retain objects for different periods, but it MUST advertise relevant retention limits and MUST NOT discard an active Operation before reaching a terminal phase.

Separation of Responsibilities Consistent with intent-based networking concepts , the client states a desired outcome separately from the provider's implementation mechanism. The client selects an advertised action, identifies targets, supplies arguments, states constraints and success criteria, and chooses preview or execute-if-ready mode. The provider observes native state, proposes mechanisms, evaluates policy, executes through native systems, journals effects, verifies outcomes, and reports uncertainty. The provider MUST derive identity, delegation, permissions, and approval validity from authenticated server-side context. It MUST NOT grant authority because a request body claims that authority. A purpose string or delegation reference is input to policy evaluation, not proof of permission.

Bindings and Profiles The core object model is independent of transport. This document's HTTP binding defines interoperable retrieval and mutation semantics. Other bindings MUST preserve object identity, request deduplication, plan-revision binding, operation durability, error semantics, and authorization parity. A profile defines domain vocabulary. Action and type identifiers MUST be absolute URIs controlled by the profile publisher. A profile MUST publish machine-readable input and output schemas and MUST define the semantics that affect interoperability, including effect class, idempotency, reversibility, preconditions, success criteria, and observation types.

Preview and Execute-if-Ready Consequential intents default to preview. To avoid an unnecessary round trip for routine, low-risk work, a client can request execute-if-ready. The provider still creates an internal plan, evaluates current policy, binds execution to that plan, and returns the resulting Plan or Operation. It MUST NOT execute when feasibility is not feasible, authorization is not allowed, a required approval is absent, a hard constraint is unsatisfied, or policy requires explicit preview. The execute-if-ready mode is permission to use the safe fast path, not an instruction to weaken policy.

Common Data Model

JSON Encoding AICP JSON objects MUST be valid JSON as defined by and MUST satisfy the Internet JSON (I-JSON) constraints in . Object member names are case-sensitive. A producer MUST NOT emit duplicate member names. Time values MUST use the Internet date-time format in and SHOULD use UTC. When a profile needs an integer outside the exact interoperable range of IEEE 754 binary64, it MUST encode that value as a string and define the lexical form. Monetary values SHOULD use decimal strings in profiles that require exact accounting; the numeric cost examples in this document are illustrative.

Common Members Except for Problem Details objects, AICP objects contain these common members: Common AICP Members

Member	Requirement	Meaning
`aicpVersion`	Required	The major.minor core version. This document defines `0.1`.
`kind`	Required	The object class.
`id`	Response objects	A provider-stable opaque identifier.
`revision`	Mutable durable objects	An opaque value that changes on every semantically observable revision.
`createdAt`	Durable response objects	Creation time.
`updatedAt`	Optional	Time of the represented revision.
`links`	As specified	A map from registered-by-this-document relation names to URI references.
`extensions`	Optional	A map whose keys are absolute extension URIs.
`criticalExtensions`	Optional	Extension URIs that must be understood for safe processing.

Identifiers are opaque. Clients MUST NOT infer type, ordering, time, tenancy, or authority from their syntax. Providers SHOULD generate identifiers with enough entropy to prevent enumeration.

Resource References A Resource Reference contains an absolute profile-defined type URI and provider-stable id. It can also contain scope, opaque revision, and non-authoritative displayName. The scope object narrows resolution with provider-defined string members such as account, project, tenant, region, namespace, or cluster. A provider MUST use the authenticated principal and scope together when resolving a reference and MUST NOT allow a display name to override the identifier.

Extension Processing Extension keys MUST be absolute URIs. A recipient MAY ignore an unrecognized extension unless its URI occurs in criticalExtensions. If a critical extension is unrecognized or unsupported, the recipient MUST reject the object with code unsupported-extension before causing a consequential effect. A provider MUST NOT change core semantics through a non-critical extension. An intermediary that preserves an object SHOULD preserve unrecognized extensions byte-for-byte where its representation permits.

Structured Semantics and Prose Human-readable titles, summaries, descriptions, and details are supplemental. A client MUST NOT treat prose as authorization, executable instructions, a replacement for a stable code, or a reason to violate a structured constraint. Providers MUST represent safety-relevant state in normative structured members. Neither clients nor providers are required to expose private chain-of-thought. Concise rationale, assumptions, evidence references, and policy reason codes are sufficient.

Discovery and Capabilities

Service Discovery An AICP HTTP provider MUST publish a Discovery object at /.well-known/aicp, as specified in . It lists supported core versions, profile URIs, authentication metadata, and links to the capability and request endpoints. Discovery only identifies a service and protocol surfaces. It is not a global provider directory and does not imply that every advertised profile or endpoint is authorized for the current principal.

Capability Document A Capability Document MUST contain a revision, supported profiles, an action list, and relevant protocol limits. Each Action Descriptor MUST contain:

a stable absolute action URI, title, and concise description;
one or more target type URIs;
an input schema URI and, when applicable, an output schema URI;
an effect class of read-only or consequential;
whether planning is unsupported, optional, or required;
whether idempotency is unsupported, request-id based, or inherent;
whether reversibility is always, conditional, never, or unknown;
a default risk level;
permissions names sufficient for user explanation but not usable as proof of authority;
observation types usable to verify the action; and
applicable size, rate, retention, cost, or execution limits.

The schemas MUST be retrievable by an authorized client and SHOULD use JSON Schema 2020-12 . The profile specification remains authoritative when schema validation alone cannot express a semantic requirement. A consequential action MUST advertise planning as required. A read-only action can advertise planning as optional or unsupported. Submitting preview for an action whose planning is unsupported fails with planning-unsupported; submitting it in execute-if-ready mode can create a read-only Operation.

Principal Scoping and Freshness A capability response MAY be scoped to the authenticated principal. If so, principalScoped is true, HTTP caching is private, and the provider MUST ensure that a response for one principal cannot be reused for another. A capability listing indicates discoverability, not a durable authorization grant; policy is evaluated again when planning and immediately before execution. Capability documents MUST have an opaque revision. Providers SHOULD support conditional retrieval so that clients can cache schemas and avoid repeated context transfer.

Situation Acquisition

Situation Request A Situation Request identifies one or more targets, a purpose, a view, optional categories to include, freshness requirements, and response budgets. The defined views are:

decision: The smallest representation the provider considers sufficient for choosing or evaluating an action for the stated purpose.
summary: A compact operational representation including principal resources, health, relationships, constraints, and active operations.
full: The most complete representation the provider is willing and authorized to disclose, still subject to explicit budgets and pagination.

A client SHOULD request decision first and expand selectively. A provider MAY return less detail for policy, privacy, size, or availability reasons, but it MUST disclose omissions in coverage metadata unless disclosing the existence of omitted data would itself violate policy. The optional budget can bound bytes and items. A provider MUST NOT exceed a hard client budget merely to make the response appear complete. It instead returns a cursor, truncation flag, and omissions.

Situation Representation A Situation contains a provider-stable identifier and revision, observation and freshness times, coverage, resources, relationships, active Operations, applicable constraints, and available action URIs. Every resource observation MUST identify its observation time and health as healthy, degraded, unhealthy, or unknown. Profile-defined state can be included inline or by link. Secrets and credential values MUST NOT be included; references and redaction metadata are used instead. Coverage contains the delivered view, complete, truncated, explicit omissions, and an optional next cursor. The absence of a resource from an incomplete or truncated Situation MUST NOT be interpreted as proof that the resource does not exist.

Consistency and Use A Situation is an observation, not a transaction snapshot unless a profile explicitly guarantees that property. Different resource observations can have different timestamps. Providers SHOULD minimize skew and disclose material skew as an omission or unknown. When an Intent Request cites a Situation identifier and revision, the provider MUST disclose in the Plan whether it reused, refreshed, or could not validate that Situation. Execution still requires current precondition evaluation.

Intent Requests

Required Semantics An Intent Request contains:

a caller-generated requestId used for deduplication;
an advertised action URI;
one or more Resource References;
arguments that validate against the action's input schema;
hard constraints;
success criteria;
an optional cited Situation identifier and revision;
a mode of preview or execute-if-ready;
an optional human-readable purpose; and
an optional reference to externally verified delegation.

The provider MUST validate the action, targets, arguments, constraints, and profile before planning. Unknown, ambiguous, or contradictory requirements produce a Problem or a Plan whose feasibility is conditional, infeasible, or unknown. The provider MUST NOT silently relax a hard constraint.

Constraints Core constraints can restrict allowed scopes, time, cost, impact, and applicable policy references. Impact can include maximum changed resources, maximum unavailable resources, and prohibitions on data loss or downtime. Profiles can add a profile constraint object with semantics defined by the profile. A plan MUST echo the effective hard constraints. If policy adds a more restrictive constraint, the Plan includes it and explains its origin. If a requested constraint cannot be measured or enforced, feasibility is unknown or infeasible; it is not assumed satisfied.

Success Criteria A success criterion has an identifier, profile-defined type URI, optional subject, required flag, parameters, and optional observation window. The profile defines how it is measured and the evidence needed to evaluate it. Required criteria that cannot be evaluated cause the final Outcome to be failed or indeterminate as defined by the profile. An operation is not successful merely because provider API calls returned success; the required outcome criteria must be evaluated.

Intent Example

Plans and Authorization

Plan Purpose and Immutability A Plan is the reviewable boundary between desired outcome and infrastructure mutation. It describes what the provider proposes to do, the state on which that proposal depends, and whether the proposal is feasible and authorized. Each Plan has an opaque revision and expiresAt. A provider MUST change the revision whenever any execution-relevant member changes, including changes, steps, constraints, preconditions, risk, authorization, approval requirements, assumptions, unknowns, estimates, or success criteria. A Plan revision is immutable once referenced by an execution attempt or approval. Later evaluation creates a new revision and preserves the older audit record.

Basis, Changes, and Steps The basedOn object records the Situation identifier and revision when one was used, plus the observation time of the state used for planning. A Plan MUST include all known material changes in changes. A change identifies the operation, resource, optional before and after representations, optional JSON Patch , a materiality flag, and a concise effect. The steps array describes execution order and dependencies. Steps are operationally informative; the complete material effect remains authoritative in changes. A provider MUST NOT omit a material effect merely because it occurs in an internal or provider-native sub-operation. If a precise effect cannot be known before execution, the provider includes an unknown and a worst-case risk factor. Providers SHOULD minimize incidental implementation detail. The Plan should be sufficiently precise to support authorization, comparison, and recovery without requiring the client to understand every provider-internal call.

Feasibility, Authorization, and Readiness Feasibility and authorization are independent: Plan Decision States

Dimension	States	Meaning
Feasibility	`feasible`, `conditional`, `infeasible`, `unknown`	Whether the provider can satisfy the intent and hard constraints.
Authorization	`allowed`, `denied`, `approval-required`, `clarification-required`, `unknown`	Whether the authenticated principal can execute this exact plan revision now.
Readiness	`ready`, `blocked`, `expired`, `unknown`	The provider's combined answer about whether execution can safely be requested now.

The Plan's readiness object contains its state, evaluation time, and structured reasons. A Plan is ready only while unexpired, feasible, authorized as allowed, free of unmet approval requirements, and valid against all checked preconditions. The explicit value prevents each client from reconstructing a subtly different answer. Readiness is a point-in-time advisory and MUST be re-evaluated immediately before the first consequential effect. Authorization contains an evaluation time, structured reasons, approval requirements, and explanatory permission names. Explanatory permission names are not bearer capabilities and MUST NOT be accepted as proof of authority.

Approval Binding An Approval Requirement identifies a requirement type, audience, concise summary of the material action, expiry, and optional approval endpoint. The external approval mechanism is out of scope. An accepted approval MUST be cryptographically or transactionally bound by the provider to the Plan identifier and exact revision, approving principal, intended action, material changes, and expiry. If any of those change, the approval MUST NOT authorize the new revision. Approval of prose alone is insufficient. Providers SHOULD present the approver with the same material change, risk, blast radius, constraints, assumptions, unknowns, and expiry visible to the executing client. Approval interfaces MUST defend against substitution and approval-phishing attacks discussed in .

Risk and Blast Radius Risk has a level of none, low, medium, high, critical, or unknown; structured factors; and an estimated blast radius. Blast radius can count affected resources, tenants, and regions and includes a concise worst-case description. Risk is a provider and policy assessment, not a universal numerical truth. A provider MUST return unknown when it lacks sufficient information. A client MUST NOT treat a low value from an untrusted provider as authorization. Profiles SHOULD define minimum factors and consistent level guidance for comparable actions.

Preconditions, Assumptions, and Unknowns Preconditions are facts that must hold for safe execution. Assumptions are facts the provider currently relies on but cannot guarantee. Unknowns are relevant decision inputs that the provider could not determine. Each is a structured Reason with a stable code and summary and can carry details and evidence links. A provider MUST verify enforceable preconditions immediately before execution. A material assumption becoming false or an unknown becoming unsafe causes the Operation to pause, fail, or enter compensation according to policy. The provider MUST NOT silently proceed by weakening a hard constraint.

Structured Next Actions A Plan includes nextActions selected from execute, wait, replan, approve, clarify, escalate, inspect, or stop, each with a reason, a safety indication, optional endpoint, and parameters. These are recommendations under current state, not new authority. The client still applies its policy and the provider re-evaluates authorization.

Execution and Operation Lifecycle

Execution Request An Execution Request contains a caller-generated request identifier, Plan identifier, exact Plan revision, and zero or more external approval references. The provider MUST reject execution when the Plan is missing, expired, stale, infeasible, denied, or outside a hard constraint. When a valid Plan lacks a required approval, the provider MUST NOT begin a consequential effect. It MAY create an Operation in awaiting-approval if its approval mechanism supports durable pending requests; otherwise it rejects the request with approval-required. Execution is a new authorization decision. A previously allowed Plan does not override revocation, changed principal status, emergency stop, quota, or policy changes. When rejection follows a material plan change, the provider returns or links a new Plan rather than silently executing it.

Operation Resource A provider MUST create or return a durable Operation before or atomically with accepting a consequential execution. The Operation identifies the Execution Request, Plan identifier and revision, current phase, effect state, monotonic sequence, progress, reasons, retry guidance, and structured next actions. The operation representation is the source of truth. Event delivery can be delayed, duplicated, or interrupted; a client can always retrieve the latest authorized representation while it is retained.

Phases Operation Phases

Phase	Terminal	Meaning
`queued`	No	Accepted but no consequential step is known to have started.
`awaiting-approval`	No	Execution is blocked on a bound approval.
`executing`	No	One or more planned steps can be producing effects.
`verifying`	No	Planned mutation steps ended and success criteria are being evaluated.
`paused`	No	Progress stopped for a stated, recoverable reason.
`succeeded`	Yes	Required criteria were satisfied and effects are sufficiently determined.
`failed`	Yes	The operation did not satisfy required criteria and effect state is sufficiently known.
`cancelled`	Yes	Cancellation completed; the effect state states what remains.
`indeterminate`	Yes	The provider cannot safely determine whether or to what extent effects occurred.

A provider can omit an intermediate phase but MUST NOT imply a phase that did not occur. Before a confirmed effect, queued, awaiting-approval, and paused can transition among policy-permitted non-terminal states or a terminal state. After effect begins, executing and verifying can alternate only when the exact Plan already authorizes the additional execution. A terminal phase MUST NOT be changed in place. Later discoveries are recorded in a new reconciliation Operation and a new Outcome revision linked to the original record.

Effect State Effect States

State	Meaning	Blind retry
`none`	No externally consequential effect occurred.	Permitted only when retry guidance also says safe.
`possible`	An effect may have begun, but none is confirmed.	Forbidden.
`partial`	Some effects are confirmed and the full plan is incomplete.	Forbidden.
`complete`	All planned material effects are confirmed; success criteria can still fail.	Normally unnecessary and forbidden.
`reversed`	Defined compensating effects are confirmed; exact prior state is not implied.	Forbidden unless a new plan says otherwise.
`unknown`	The provider cannot bound or classify the actual effect.	Forbidden.

Phase and effect state are independent. A failed or cancelled operation can have partial effects. A successful operation has complete planned effects but can also report side effects. Providers MUST update effect state conservatively.

Progress Progress identifies completed steps, active steps, total steps, and optionally a percentage. Step sets are authoritative; percentage is advisory and MUST NOT be interpreted as a probability of success or a safe cancellation boundary.

Cancellation, Pause, and Resume Available controls are advertised through links and structured next actions. Cancellation is best effort. A cancellation request MUST be represented as its own idempotent control request. The provider MUST report the resulting terminal phase and effect state; it MUST NOT claim cancelled means that no effect occurred. A control request racing with completion returns the current Operation. Pause and resume semantics are profile-defined. Resumption MUST re-evaluate authority, constraints, and preconditions.

Events Operation Events carry an event identifier, operation identifier, monotonically increasing per-operation sequence, event type, creation time, and event data. Delivery is at least once unless a binding or profile states stronger behavior. Clients MUST deduplicate by event identifier and sequence and MUST retrieve the current Operation after a detected sequence gap. Core event types are operation.phase-changed, operation.progress, operation.effect-changed, operation.problem, and operation.outcome. Profile-specific event types MUST be absolute URIs. Event data is a notification and MUST NOT cause a client to skip retrieval of an authorization- or safety-relevant current representation. A provider MAY encode events using CloudEvents . Such an encoding preserves the AICP operation identifier, sequence, and event type.

Outcomes, Verification, and Evidence

Outcome Resource Every terminal Operation MUST link to an Outcome. The Outcome contains the terminal status and effect state, expected changes from the Plan, observed changes, side effects, per-criterion results, evidence references, and structured next actions. The provider MUST distinguish an expected change from an observed change. It MUST NOT copy the Plan into observedChanges without observation. A side effect is any material observed effect not represented in the Plan's expected changes, including unexpected cost, exposure, dependency, or availability effects.

Criterion Results Each requested success criterion receives a result of satisfied, unsatisfied, unknown, or not-evaluated, together with an observation time when applicable, actual value, structured reasons, and evidence references. A required criterion that is unsatisfied causes status failed. Any compensation is a separate action. A required criterion whose state is unknown after the provider's defined verification period causes indeterminate unless the profile explicitly defines a safe, known failed state.

Evidence References An Evidence Reference identifies an evidence type URI and contains one or more of an authorized URI, digest, or concise summary. It can include subject, observation time, and freshness limit. Evidence can point to logs, metrics, traces, signed observations, attestations, policy decisions, or provider-native audit records. AICP does not define a signature or evidence verification protocol. Profiles SHOULD reuse applicable evidence work such as VIRP and EMILIA and telemetry standards such as OpenTelemetry . Access to evidence MUST be independently authorized and MUST NOT be granted merely because a client can read an Outcome.

Compensation A compensating action is a new Intent, Plan, authorization decision, Operation, and Outcome. It links to the original Operation and describes which effects it intends to counter. A provider MUST NOT mutate the original history to make compensation appear to be an atomic rollback. The original action's reversibility descriptor is only a planning hint. Current state, authorization, and risk are evaluated again. If full restoration is impossible, the compensation Plan declares residual effects and unknowns.

Problems and Recovery Semantics

Problem Representation HTTP errors use Problem Details for HTTP APIs with media type application/problem+json. An AICP Problem adds:

aicpVersion and a stable code;
the relevant requestId and optional Operation link;
effectState;
retry.safe, optional delay, and requiresReconciliation;
structured constraint or field violations;
safe alternatives and remediations; and
links to current Plans, Operations, Situations, or capability documents.

The human-readable detail member is not authoritative. A client bases retry and recovery decisions on stable code, effect state, retry fields, and current operation state.

Core Problem Codes Initial AICP Problem Codes

Code	Typical HTTP status	Required behavior
`invalid-request`	400	Return field or semantic violations; no effect.
`unsupported-version`	400	Link supported versions; no effect.
`unsupported-profile`	400	Link supported profiles; no effect.
`unsupported-action`	400 or 404	Disclose alternatives only when authorized.
`unsupported-extension`	400	Identify unsupported critical URIs; no effect.
`planning-unsupported`	409	Use an allowed direct mode or another advertised action; no effect.
`authorization-denied`	403	Do not disclose protected policy or target existence.
`approval-required`	403 or 409	Link exact Plan and requirements; no effect.
`plan-stale`	412	Do not execute; link or create a new Plan.
`plan-expired`	409	Do not execute; replan.
`precondition-failed`	412	Do not begin new effect; disclose failed preconditions.
`constraint-unsatisfied`	409 or 422	Do not silently relax; offer authorized alternatives.
`capacity-unavailable`	409 or 503	Return delay and alternatives when known.
`request-id-reuse`	409	Same request identifier was used with different semantics.
`rate-limited`	429	Return retry delay and preserve accepted operation state.
`operation-not-cancellable`	409	Return current operation and effect state.
`effect-indeterminate`	500 or 503	Blind retry is unsafe; link reconciliation.
`reconciliation-required`	409	Caller must observe actual state before another mutation.

HTTP status codes remain transport-level classifications; the AICP code supplies stable domain behavior. Providers MAY define profile-specific codes using absolute problem type URIs and names that do not collide with core codes.

Recovery Actions Next actions and remediations use the controlled action values execute, wait, replan, approve, clarify, cancel, reconcile, compensate, escalate, stop, and inspect. Each item states whether following the recommendation is non-consequential under current state. A safe value does not grant permission and can become stale. When retry is unsafe, retry.safe is false. If reconciliation is required, the provider MUST link or describe a reconciliation action and MUST NOT recommend a repeat of the original consequential request until actual effect state is sufficiently known.

Idempotency, Concurrency, and Reconciliation

Request Deduplication Every mutation request contains a caller-generated requestId. During its advertised retention interval, a provider scopes this identifier to the authenticated principal, service, request kind, and action. Repeating the identifier with semantically identical input MUST return the same Plan, Operation, control result, or terminal record rather than start another consequential effect. Reusing the identifier with semantically different input MUST fail with request-id-reuse. Providers MUST compare a normalized internal representation sufficient to detect a material difference; this document does not standardize a cross-provider canonical JSON digest. The capability document MUST advertise request identifier retention. A client MUST NOT assume deduplication after that interval and SHOULD retrieve the prior Operation before taking another consequential action.

Optimistic Concurrency Plans bind to observed resource revisions and preconditions. HTTP representations use entity tags and conditional requests as specified in . A provider MUST reject execution if a material target revision or precondition changed unless the Plan explicitly described and authorized that variance. A provider MUST NOT recompute a stale Plan and execute the new result under the old approval. It can return a new Plan for review.

No Exactly-Once Assumption AICP does not guarantee exactly-once external effects. Native provider calls, network failures, failover, and partial execution can make an accepted request's effects uncertain. Idempotency prevents many duplicates but does not prove that an external effect did or did not occur. If the provider cannot safely determine the effect, the Operation reaches indeterminate with effect state possible, partial, or unknown. The client MUST NOT blindly retry and MUST use the advertised reconciliation path or escalate.

Reconciliation Procedure A reconciliation action observes authoritative native state and compares it to the Plan's expected changes and the latest known effects. It produces a new Operation and Outcome linked to the indeterminate Operation. It can classify effects as none, partial, complete, reversed, or still unknown and can propose a new completion or compensation Plan. Reconciliation is observation-oriented. If it must mutate state, that mutation is represented as a separate consequential Plan and Operation.

HTTP Binding

General Requirements The AICP HTTP binding uses HTTP semantics from , encrypted transport, JSON representations, conditional requests, and link-driven endpoints. An implementation MUST support HTTP/1.1 or later and MUST use TLS 1.2 or later; TLS 1.3 is RECOMMENDED. AICP success representations use media type application/aicp+json. Problems use application/problem+json. Clients send Accept and Content-Type accordingly. Servers MUST reject an unsupported content type without interpreting it as an AICP mutation. Authentication and token acquisition are outside scope. HTTP providers SHOULD publish OAuth 2.0 Protected Resource Metadata when OAuth is used. Authorization requests can use Rich Authorization Requests or another policy mechanism. Bearer and proof-of-possession credentials MUST NOT appear inside AICP JSON objects.

Well-Known Discovery The path /.well-known/aicp is formed according to . A successful GET returns a Discovery object. The object contains at least: The origin of an absolute link is authoritative for that endpoint. A client MUST NOT forward credentials to a different origin unless its authentication policy explicitly authorizes that origin. Redirect handling follows the credential and redirection security requirements of HTTP and the authentication scheme.

Resource Interaction Pattern Endpoint paths other than the well-known URI are discovered from links; their literal spelling is not normative. The following interaction pattern is normative: HTTP Interaction Pattern

Interaction	Method	Request	Response
Discover service	GET	None	Discovery
List capabilities	GET	Conditional headers optional	Capability Document
Acquire situation	POST	Situation Request	Situation
Submit intent	POST	Intent Request	Plan or Operation
Retrieve plan	GET	Conditional headers optional	Plan
Execute plan	POST	Execution Request and `If-Match`	Operation
Retrieve operation	GET	Conditional headers or wait preference optional	Operation
Control operation	POST	Profile-defined control request with request ID	Operation
Retrieve events	GET	Cursor and wait preference optional	Event collection or stream
Retrieve outcome	GET	Conditional headers optional	Outcome

A created Plan or Operation is returned with Location pointing to its durable resource. A provider MUST return the same resource location for a deduplicated request.

Status Codes A synchronous retrieval or completed non-mutating request normally returns 200. Creation of a durable Plan can return 200 or 201. Acceptance of asynchronous execution returns 202 with an Operation and Location. A provider MUST NOT use 202 without a retrievable operation status. Conditional failure uses 304 for retrieval, 409 for domain conflict or expired state, and 412 for a failed HTTP or plan precondition. Authentication uses 401; authorization denial uses 403; disclosure-sensitive implementations can use 404 where required to conceal target existence. A missing required condition uses 428 and rate limiting uses 429 as defined by . Service unavailability uses 503 with appropriate retry metadata. Semantic errors include a Problem object even when the HTTP status is sufficient for a generic client.

Entity Tags and Conditional Execution Providers MUST return a strong entity tag for each Plan revision and SHOULD return entity tags for Discovery, Capability Document, Situation, Operation, and Outcome representations. The opaque AICP revision and HTTP ETag can have different syntax but identify the same semantically observable revision. An explicit Plan execution request MUST contain planRevision and MUST use If-Match with the Plan's current strong entity tag. A missing If-Match returns 428 when the server requires a condition; a mismatch returns 412 with code plan-stale. A provider MUST NOT execute a newer Plan under an older entity tag or approval.

Asynchronous Preference and Waiting Clients can use the Prefer header from . respond-async asks the server not to wait for completion. wait=N on an Operation or event retrieval asks the server to wait up to N seconds for a newer revision. The server can decline either preference and reports applied preferences with Preference-Applied. Long polling and streaming are optional. A provider supporting event streaming MUST also support ordinary retrieval of the current Operation. Cursors are opaque, scoped to the principal and collection, and MUST NOT be treated as credentials.

Caching and Bounded Transfer Discovery, public profile schemas, and non-sensitive capabilities SHOULD use explicit cache controls. Principal-scoped representations use Cache-Control: private or no-store as appropriate and ensure authorization state is not shared across principals. A Situation response respects the caller's item and byte budgets. HTTP compression SHOULD be supported. Providers SHOULD offer conditional retrieval and event deltas so that a client does not repeatedly transfer unchanged full state.

Correlation and Telemetry A provider SHOULD accept standard trace-context propagation and link authorized trace, metric, log, and audit evidence from the resulting Operation. AICP request identifiers are for deduplication and audit correlation; they are not a substitute for distributed tracing identifiers.

Relationship to Agent Protocols

Model Context Protocol MCP standardizes how an AI application discovers and invokes tools and accesses resources. An MCP server can expose AICP without defining one tool for every provider action. A recommended minimal tool surface is:

aicp.discover - retrieve Discovery and principal-scoped capabilities;
aicp.situation - submit a Situation Request;
aicp.plan - submit an Intent Request in preview or execute-if-ready mode;
aicp.execute - execute an exact Plan revision;
aicp.observe - retrieve an Operation, Outcome, or events; and
aicp.control - request cancellation, pause, resume, reconciliation, or another advertised control.

Action URIs and profile schemas travel as data. This fixed surface reduces tool-list size, selection ambiguity, and adapter churn. An implementation can expose more specialized tools, but they MUST preserve the same Plan, policy, Operation, error, and audit semantics to claim AICP conformance. An MCP adapter MUST NOT bypass the authorization path used by the HTTP binding. MCP task facilities can represent long-running delivery, but the AICP Operation remains the authoritative infrastructure effect record.

Agent2Agent Protocol A2A can delegate infrastructure work to another agent or carry AICP objects as artifacts. An A2A task describes inter-agent work and conversation; an AICP Operation describes infrastructure execution and effects. Implementations SHOULD link the two identifiers without collapsing their state machines.

Agent Execution Protocol The Agent Execution Protocol (AEP) describes a governed reasoning-loop boundary. An AEP ACT transition can invoke an AICP request, and an AICP Situation, Operation, or Outcome can be an input to SENSE or OBSERVE. AICP does not standardize the internal reasoning loop or replace its governing enforcement component.

Agent Ergonomics and Resource Efficiency

Progressive Disclosure Clients SHOULD begin with cached capabilities and a decision Situation. Providers SHOULD order decision views by operational relevance rather than provider database layout. A caller can then request summary or full views, specific include categories, evidence, or a continuation cursor only where uncertainty remains. Every truncated or policy-limited response identifies coverage and omissions. This allows an agent to reason about what it does not know without paying to retrieve irrelevant state.

Stable Machine Semantics Stable action URIs, schemas, codes, enumerated states, and structured reasons SHOULD be favored over parsing provider prose. A profile SHOULD use intent-aligned action identifiers such as deploy, resize, expose, rotate, or reconcile rather than method names derived from one implementation. Descriptions are untrusted explanatory data. Clients SHOULD select actions by authenticated capability identity, schema, effect class, policy, and target compatibility, not by semantic similarity to a natural-language description alone.

Accretive Context AICP objects form a durable graph. A resumed client can retrieve the current Operation and follow links to the exact Plan, originating intent, observed Situation, Outcome, and evidence. It need not reconstruct authority or effects from a chat transcript. Providers SHOULD retain concise object summaries even when bulky evidence has moved to archival storage.

Least-Call Behavior The protocol permits but does not require a single request to plan and execute through execute-if-ready. Providers still enforce planning internally. Clients use conditional retrieval, wait preferences, and event cursors to avoid hot polling. Problems carry recovery choices so the next call is deliberate rather than exploratory.

Decision Quality Without Private Reasoning Providers report relevant evidence, assumptions, unknowns, and concise reason codes. They MUST NOT require a model's hidden reasoning trace as a condition of interoperability. Clients can supply a short purpose and success criteria without disclosing private chain-of-thought or unrelated context.

Profiles, Versioning, and Extensibility

Profile Requirements A conforming profile specification defines:

a stable profile URI and versioning policy;
resource type and relationship URIs;
action descriptors and input/output schemas;
constraint and success-criterion semantics;
observation and evidence types;
materiality, effect class, idempotency, reversibility, and risk guidance;
native-state mapping and loss of fidelity;
additional Problem codes and recovery behavior; and
conformance examples and tests.

A profile SHOULD reference an existing resource or orchestration model where one is fit for purpose. It MUST disclose mapping loss rather than imply semantic equivalence.

Core Version Negotiation The Discovery object lists supported major.minor versions. A client selects a mutually supported version by sending the corresponding media type and object value. This document defines 0.1; pre-1.0 versions can make incompatible changes. After a 1.0 specification, a minor version will add only backward-compatible optional semantics, while a major version can make incompatible changes. A recipient MUST reject an unsupported version before a consequential effect.

Schema Evolution New optional fields are introduced through a negotiated core version, profile version, or extension URI. Unknown top-level members are not a substitute for extensions and MAY be rejected. Critical behavior always appears in criticalExtensions or a negotiated profile.

Conformance

Core Provider An AICP Core Provider implements Discovery, Capability Documents, Situation Requests, Intent Requests, Plans, authorization state, Operations, Outcomes, Problems, request deduplication, plan-revision binding, and reconciliation semantics in at least one binding. An AICP HTTP Provider additionally implements .

Core Client An AICP Core Client validates versions and critical extensions, treats prose as non-authoritative, honors hard constraints, executes only exact Plan revisions, deduplicates events, does not blindly retry uncertain effects, and follows binding-specific credential rules.

Profile Conformance A provider or client claiming profile conformance implements all profile requirements identified as mandatory and publishes the supported profile URI in Discovery. Core conformance alone does not imply semantic interoperability for an unshared profile.

Minimum Test Cases A conformance suite MUST test at least:

same request identifier and same semantics return the same result;
same request identifier and different semantics return request-id-reuse;
a stale, expired, or mismatched Plan is not executed;
approval for one revision cannot authorize another;
denied work cannot bypass policy through another binding;
truncation and omissions are explicit;
a partial or uncertain effect reaches an appropriate effect and retry state;
an event gap is recoverable from the Operation resource;
cancellation races report remaining effects;
compensation is a separate authorized action;
unsupported critical extensions are rejected before effect; and
malicious descriptions cannot supply authority or executable instructions.

Operational Considerations

Retention and Resumption Providers advertise request-deduplication, Plan, Operation, Outcome, and event retention. Active Operations are durable across service restarts. If detailed events expire before the Outcome, the provider preserves a terminal summary, effect state, Plan link, and evidence index sufficient for audit and safe recovery.

Backpressure and Resource Exhaustion Providers enforce authenticated quotas for Situation size, concurrent plans, active Operations, event subscriptions, and expensive verification. Rate limiting does not discard an accepted Operation. Problems distinguish rejection before acceptance from throttling of observation after an effect may have begun.

Revocation and Emergency Stop Providers MUST support operational revocation of credentials and SHOULD support policy-defined emergency stop. Revocation prevents new effects but does not erase or hide active operations. The provider attempts safe pause, cancellation, or containment and reports actual effect state.

Clock and Expiry Plan and approval expiry is evaluated by the provider's clock. Providers maintain time synchronization appropriate to their maximum expiry granularity. Clients treat expiry as an upper bound and allow for network delay; they do not assume execution is valid merely because their local clock precedes expiresAt.

Security Considerations AICP enables consequential control and therefore exposes the security impact of infrastructure APIs to autonomous and high-rate callers. Authentication alone is insufficient. Implementations require least privilege, policy evaluation, exact-plan binding, durable audit, rate control, and conservative uncertainty handling.

Confused Deputy and Cross-Tenant Access A provider resolves every Resource Reference in the authenticated principal's context, validates delegation and audience, and applies tenant boundaries at every linked resource. It does not trust scope, display name, purpose, requested permission, or delegation URI from the body as proof. Links and cursors are not bearer authorization unless explicitly specified by the authentication system.

Stale Plan and Time-of-Check/Time-of-Use An attacker or concurrent actor can change infrastructure after preview. Strong entity tags, opaque revisions, expiry, native resource preconditions, and immediate authorization re-evaluation reduce this risk. Providers do not execute a recomputed plan under old approval and do not silently widen a constraint.

Approval Substitution and Phishing An approval is bound to exact Plan identity, revision, action, material changes, principal, and expiry. Approval interfaces clearly identify the provider origin and material effect. They avoid approving a generic phrase that could be replayed against another target. High-risk plans should require phishing-resistant authentication and independent confirmation appropriate to organizational policy.

Prompt Injection, Schema Poisoning, and Tool Shadowing Descriptions, resource labels, log content, telemetry annotations, and problem detail can contain attacker-controlled text. Clients treat such text as data, never as protocol instructions or authority. Action selection uses authenticated service identity, stable URI, schema, target type, and policy. Clients do not accept a newly advertised action that shadows a trusted action by title alone. Schema and profile documents require integrity and origin validation. Clients cache them by origin, URI, and revision and apply size and complexity limits to avoid parser and validation denial of service. A provider does not allow resource content to inject critical extensions or alter core fields.

Replay, Duplicate Effects, and Retry Storms Unpredictable request identifiers, principal scoping, bounded retention, and semantic mismatch detection reduce replay. A provider rate-limits repeated retrieval without losing the durable Operation. A client backs off according to Problem metadata and never repeats a consequential request when effect state is possible, partial, or unknown.

Provider and Adapter Compromise A compromised adapter can misstate a plan, hide effects, or forge observations. Deployments should isolate provider adapters, constrain their native credentials, compare requested and native audit records, and use independent evidence for high-risk actions. AICP evidence links can support verification but do not make an untrusted provider trustworthy by themselves.

Secrets and Sensitive Data Secret values, bearer credentials, private keys, and unrestricted signed URLs do not appear in AICP objects. Profiles use opaque secret references resolved inside the authorized control plane. Logs, errors, plans, and evidence summaries are redacted before return and before inclusion in model context.

Autonomy and Blast Radius Autonomous clients can generate valid but harmful high-rate actions. Providers enforce independent limits on scope, spend, concurrent changes, unavailable resources, data destruction, region count, and approval threshold. A client's stated risk tolerance never overrides provider policy. The execute-if-ready fast path is disabled when policy requires explicit review.

Audit Integrity Audit records link authenticated principal, delegated subject when known, request identifier, Situation, Plan revision, approval decisions, native operation identifiers, Operation events, Outcome, and evidence. Providers protect audit data from modification and unauthorized disclosure. Private model reasoning is neither necessary nor sufficient as an audit record.

Privacy Considerations Situation and capability discovery can reveal topology, resource names, tenant existence, policy, capacity, cost, operational incidents, and organizational relationships. Providers return only the minimum information authorized for the principal and purpose. They can conceal target existence with an appropriate generic response where disclosure would create risk. Decision views and explicit include categories support data minimization. A provider can state an omission without disclosing protected details, for example by using a generic policy-limited reason. Clients avoid sending unrelated conversation history, personal data, or private reasoning in purpose, arguments, or extensions. Durable linked records increase accountability but also correlation risk. Retention is limited to operational, legal, and audit need. Identifiers use sufficient entropy and do not encode user identity. Evidence access is separately authorized, and telemetry links avoid embedding credentials. Cross-origin links are not automatically followed with credentials. Capability documents scoped to a principal can reveal permissions. They are privately cached or not stored, are not shared across principals, and can omit denied actions rather than exposing a permission map.

IANA Considerations

Media Type Registration This document requests registration of application/aicp+json in the Media Types registry according to using the following template:

Type name: application
Subtype name: aicp+json
Required parameters: None
Optional parameters: None
Encoding considerations: binary; the content is UTF-8 JSON
Security considerations: See of this document.
Interoperability considerations: Recipients use the aicpVersion member and negotiated profiles. Unknown critical extensions are rejected.
Published specification: This document.
Applications that use this media type: Infrastructure control planes, autonomous agents, orchestration gateways, and management clients.
Fragment identifier considerations: None are defined by this specification. A profile can define fragment semantics, including JSON Pointer, for its own representations.
Additional information: Magic number(s): none; file extension(s): none; Macintosh file type code(s): none.
Person and email address to contact for further information: Tihan-Nico Paxton, tihan-nico@apollodeploy.com
Intended usage: COMMON
Restrictions on usage: None
Author: Tihan-Nico Paxton
Change controller: IETF

Well-Known URI Registration This document requests registration of aicp in the Well-Known URIs registry:

URI suffix: aicp
Change controller: IETF
Specification document: This document, .
Related information: The resource returns an AICP Discovery object and does not itself authorize infrastructure operations.

AICP Problem Code Registry This document requests creation of the "AICP Problem Codes" registry under an "Agent Infrastructure Control Protocol" group. Initial entries are the codes in . Future registrations require Specification Required as defined by . A registration contains code, problem type URI, intended HTTP status or range, effect-state requirements, retry requirements, and a specification reference. Designated Experts should reject names that are ambiguous, disclose credentials, redefine an existing code incompatibly, or omit safe behavior for uncertain effects.