Agent Infrastructure Control Protocol

1.1. Scope of the Contribution

Cloud Infrastructure Management Interface (CIMI) [CIMI], Cloud Application Management for Platforms (CAMP) [CAMP], Topology and Orchestration Specification for Cloud Applications (TOSCA) [TOSCA], Kubernetes [KUBERNETES], and related systems already define infrastructure resources and operations. Model Context Protocol (MCP) [MCP] and Agent2Agent Protocol (A2A) [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.¶

1.2. Layering

AICP follows the architectural preference to profile and extend existing Internet protocols rather than define a monolithic agent protocol [AI-ARCH]. 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.¶

3.1. 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.¶

3.2. 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.¶

4.1. 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.¶

4.2. Separation of Responsibilities

Consistent with intent-based networking concepts [RFC9315], 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.¶

4.3. 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.¶

4.4. 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.¶

5.1. JSON Encoding

AICP JSON objects MUST be valid JSON as defined by [RFC8259] and MUST satisfy the Internet JSON (I-JSON) constraints in [RFC7493]. Object member names are case-sensitive. A producer MUST NOT emit duplicate member names. Time values MUST use the Internet date-time format in [RFC3339] 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.¶

5.2. Common Members

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

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.¶

5.3. 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.¶

5.4. 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.¶

5.5. 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.¶

6.1. Service Discovery

An AICP HTTP provider MUST publish a Discovery object at /.well-known/aicp, as specified in Section 14. 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.¶

6.2. 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 [JSON-SCHEMA]. 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.¶

6.3. 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.¶

7.1. 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.¶

7.2. 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.¶

7.3. 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.¶

8.1. 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.¶

8.2. 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.¶

8.3. 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.¶

8.4. Intent Example

{
  "aicpVersion": "0.1",
  "kind": "IntentRequest",
  "requestId": "req-7f2c",
  "action": "https://example.com/aicp/actions/workload.deploy",
  "targets": [{
    "type": "https://example.com/aicp/types/workload",
    "id": "signal",
    "scope": {"project": "production", "region": "jnb1"}
  }],
  "arguments": {"release": "sha256:9c9f0d4a", "replicas": 3},
  "constraints": {
    "impact": {"maxUnavailable": 1, "forbidDataLoss": true},
    "cost": {"currency": "USD", "maxIncrement": 15}
  },
  "successCriteria": [{
    "id": "health",
    "type": "https://example.com/aicp/criteria/healthy-replicas",
    "required": true,
    "parameters": {"operator": "equals", "value": 3},
    "windowSeconds": 300
  }],
  "mode": "preview"
}

9.1. 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.¶

9.2. 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 [RFC6902], 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.¶

9.3. Feasibility, Authorization, and Readiness

Feasibility and authorization are independent:¶

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.¶

9.4. 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 Section 20.¶

9.5. 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.¶

9.6. 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.¶

9.7. 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.¶

10.1. 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.¶

10.2. 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.¶

10.3. Phases

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.¶

10.4. Effect State

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.¶

10.5. 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.¶

10.6. 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.¶

10.7. 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 [CLOUDEVENTS]. Such an encoding preserves the AICP operation identifier, sequence, and event type.¶

11.1. 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.¶

11.2. 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.¶

11.3. 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 [VIRP] and EMILIA [EMILIA] and telemetry standards such as OpenTelemetry [OTEL]. Access to evidence MUST be independently authorized and MUST NOT be granted merely because a client can read an Outcome.¶

11.4. 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.¶

12.1. Problem Representation

HTTP errors use Problem Details for HTTP APIs [RFC9457] 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.¶

12.2. Core Problem Codes

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.¶

12.3. 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.¶

13.1. 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.¶

13.2. Optimistic Concurrency

Plans bind to observed resource revisions and preconditions. HTTP representations use entity tags and conditional requests as specified in Section 14. 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.¶

13.3. 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.¶

13.4. 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.¶

14.1. General Requirements

The AICP HTTP binding uses HTTP semantics from [RFC9110], 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 [RFC8446] 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 [RFC9728] when OAuth is used. Authorization requests can use Rich Authorization Requests [RFC9396] or another policy mechanism. Bearer and proof-of-possession credentials MUST NOT appear inside AICP JSON objects.¶

14.2. Well-Known Discovery

The path /.well-known/aicp is formed according to [RFC8615]. A successful GET returns a Discovery object. The object contains at least:¶

{
  "aicpVersion": "0.1",
  "kind": "Discovery",
  "service": "Example Infrastructure Control",
  "versions": ["0.1"],
  "profiles": ["https://example.com/aicp/profiles/workload/0.1"],
  "auth": {
    "protectedResourceMetadata":
      "https://c.example/.well-known/oauth-protected-resource"
  },
  "links": {
    "capabilities": "https://control.example.com/aicp/capabilities",
    "situations": "https://control.example.com/aicp/situations",
    "intents": "https://control.example.com/aicp/intents"
  }
}

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.¶

14.3. 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:¶

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.¶

14.4. 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 [RFC6585]. 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.¶

14.5. 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.¶

14.6. Asynchronous Preference and Waiting

Clients can use the Prefer header from [RFC7240]. 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.¶

14.7. 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.¶

14.8. 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.¶

15.1. Model Context Protocol

MCP [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.¶

15.2. Agent2Agent Protocol

A2A [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.¶

15.3. Agent Execution Protocol

The Agent Execution Protocol (AEP) [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.¶

16.1. 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.¶

16.2. 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.¶

16.3. 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.¶

16.4. 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.¶

16.5. 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.¶

17.1. 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.¶

17.2. 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.¶

17.3. 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.¶

18.1. 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 Section 14.¶

18.2. 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.¶

18.3. 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.¶

18.4. Minimum Test Cases

A conformance suite MUST test at least:¶

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

19.1. 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.¶

19.2. 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.¶

19.3. 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.¶

19.4. 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.¶

20.1. 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.¶

20.2. 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.¶

20.3. 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.¶

20.4. 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.¶

20.5. 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.¶

20.6. 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.¶

20.7. 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.¶

20.8. 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.¶

20.9. 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.¶

22.1. Media Type Registration

This document requests registration of application/aicp+json in the Media Types registry according to [RFC6838] 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 Section 20 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¶

22.2. 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, Section 14.2.¶

Related information

The resource returns an AICP Discovery object and does not itself authorize infrastructure operations.¶

22.3. 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 Table 5. Future registrations require Specification Required as defined by [RFC8126].¶

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.¶