Summary

  • draft-paxton-aicp-00, posted on 2 September 2026, is an active individual Internet-Draft. It has no IETF endorsement or formal standing, no RFC stream, no Responsible Area Director and no telechat date.
  • AICP progress can contain completed, active and total step sets plus an optional percentage. The step sets are authoritative; the percentage is advisory.
  • The draft says that percentage must not be read as either a probability of success or a safe cancellation boundary.
  • Phase and effect state are independent. A failed or cancelled operation can retain partial effects, and cancellation is a separate, idempotent, best-effort request rather than proof that nothing happened.
  • A consequential stop needs its own receipt: exact step sets, phase, effect state, operation sequence, cancellation state, observations still missing and any required reconciliation.

One number is carrying three different questions

The current Datatracker record describes Agent Infrastructure Control Protocol (AICP) as revision 00 of an active individual Internet-Draft by Tihan-Nico Paxton, updated on 2 September 2026. Its header lists Standards Track as the intended status, but that is the author's destination, not the document's present institutional standing. Datatracker records no RFC stream, Responsible Area Director or telechat. The IETF's own guidance says anyone may submit an Internet-Draft and that such documents have no formal status until the standards process gives them one.

Within that modest boundary, AICP identifies a real operational confusion. A progress display is commonly asked to answer three questions at once: how much planned work has been traversed; how likely the operation is to end well; and whether it is safe to stop now. Those questions can move independently.

The frozen revision therefore gives progress a deliberately narrow shape. It can list completed steps, active steps and total steps, and it can add a percentage. The sets are authoritative. The percentage is advisory. The text then forbids the two most tempting inferences: percentage is not success probability, and it is not a safe cancellation boundary.

This is more than careful interface wording. Imagine a five-step plan in which four read-only checks precede one irreversible mutation. Eighty per cent of the steps may be complete before any external effect exists. Reverse the order—make the mutation first and verify it four times—and 20 per cent may coincide with the decisive effect. A percentage derived from step count cannot distinguish those plans. The draft does not define a hidden conversion between numeric progress and effect magnitude, so neither should an operator.

Phase and effect refuse to collapse into a bar

AICP's lifecycle makes the reason explicit. An Operation can be queued, awaiting approval, executing, verifying, paused, succeeded, failed, cancelled or indeterminate. Beside that phase, it carries a separate effect state: none, possible, partial, complete, reversed or unknown.

The two fields are independent. Failure does not prove absence of effect. Cancellation does not undo a partial change. Success can still carry side effects. Providers are told to update effect state conservatively because the absence of an observation is not the observation of absence.

That separation corrects a familiar visual mistake. A bar that reaches its end often becomes green, while a cancelled bar becomes grey and a failed one red. Colour then quietly merges three facts: lifecycle phase, consequence in the world and confidence in the evidence. AICP has enough vocabulary to keep them apart. The interface that throws the vocabulary away is making a governance choice, not merely simplifying a screen.

The outcome model reinforces the point. A terminal Operation links to an Outcome that can distinguish expected changes from observed changes, record side effects, resolve each success criterion and name next actions. Expected changes must not be copied into observed changes without observation. A criterion may be satisfied, unsatisfied, unknown or not evaluated; provider API calls returning success are not by themselves the success of the Operation.

Progress therefore answers a locational question about planned execution. Phase answers where the lifecycle has arrived. Effect state answers what may have changed. Outcome and evidence answer what has actually been observed. None is a substitute for the others.

Cancel is a request, not a rewind button

The draft treats cancellation as a separate idempotent control request. That matters. The client can repeat the request without inventing a second cancellation, while the provider reports its state and the Operation that resulted. But cancellation is best effort. A request can race with completion, in which case the current Operation is returned. Pause and resume behavior is profile-defined, and resumption must revisit authority, constraints and preconditions.

Most importantly, the provider must report the resulting terminal phase and effect state and must not claim that cancelled means no effect occurred. This is where the progress bar becomes actively hazardous. If an operator sees 35 per cent and assumes “early enough,” the interface has supplied a safety judgment that the protocol has withheld. The active step may already have made a non-reversible call; the completed steps may include mutations; or the observation path may simply not know.

Compensation is not cancellation with the sign reversed. Reversing an effect is itself a consequential action, with its own authorization, failure modes and possible side effects. Even an effect state of reversed should describe evidence about the compensating result, not promise that every external condition is identical to its earlier state.

The same discipline applies to retries. AICP says possible, partial and unknown effects should not be blindly retried. Its problem model can expose whether retry is safe and whether reconciliation is required. This prevents a timeout, a low percentage or a red phase label from becoming permission to repeat a mutation that may already have happened.

A stop receipt should preserve the uncomfortable fields

A consequential pause or cancellation deserves a receipt separate from ordinary progress. This is my recommendation, not a requirement in revision 00. Its purpose is to stop a convenient display from becoming an unauthorized decision rule.

The receipt should identify the durable Operation and the latest operation sequence. It should reproduce the completed, active and total step sets rather than only their ratio. It should show phase and effect state side by side, name the cancellation request and its current state, list observations still outstanding, and say whether reconciliation is required before retry or compensation.

The receipt should also preserve the distinction between expected and observed changes. If an active step was expected to rotate a credential but no independent observation has arrived, “rotation expected; effect unknown” is more accurate than “35 per cent cancelled.” When criteria remain unknown or not evaluated, the receipt should say so. Where the provider cannot establish whether an effect is none, partial or complete, unknown is the result—not an empty cell to be filled by the percentage.

Heng Lu's right to accurate records supplies a useful editorial test: records should describe reality rather than create it. Applied here, the Operation should retain observations and uncertainty without allowing a dashboard to manufacture success odds or safety from a ratio. This is an analytical application of Heng Lu's principle, not a claim that his essay mandates AICP's design.

Useful proposal, unproven deployment

Revision 00 includes a worked HTTP control loop and a set of protocol invariants. I found no Implementation Status section in the reviewed draft. The reviewed sources establish no independent implementation, production deployment, interoperability result or adoption by the IETF. That evidence limit matters because the most important behavior is not the presence of six effect-state words in a document; it is whether implementations, user interfaces and incident procedures preserve their separation under pressure.

The RFC Editor's account of the standards path is a reminder that an Internet-Draft can expire, change substantially or never become an RFC. The fair description is therefore narrow: AICP revision 00 proposes a promising control grammar and is explicit about one dangerous inference. It does not yet demonstrate that vendors will display or implement the grammar faithfully.

Tests for this boundary should be adversarial. A 0 per cent operation with a possible effect must not render as untouched. A 100 per cent operation with an unsatisfied criterion must not render as successful. A cancelled operation with partial effects must not invite automatic retry. An indeterminate operation must not be assigned a synthetic percentage merely to complete a chart. Passing those cases would show that the caution survives beyond prose.

Sources

  1. IETF Datatracker: Agent Infrastructure Control Protocol
  2. IETF archive: draft-paxton-aicp-00
  3. IETF: About Internet-Drafts
  4. RFC Editor: How RFCs Are Created
  5. Heng Lu: The Bill of Rights of Uniqueness Coordination