Resumen

  • draft-paxton-aicp-00, publicado el 2 de septiembre de 2026, es un Internet-Draft individual activo. No cuenta con respaldo ni posición formal de la IETF, flujo RFC, Area Director responsable o fecha de teleconferencia.
  • El progreso de AICP enumera pasos completados, activos y totales, y puede añadir un porcentaje. Los conjuntos de pasos son autoritativos; el porcentaje solo orienta.
  • La propuesta dice que ese número no debe interpretarse como probabilidad de éxito ni como frontera segura para cancelar.
  • La fase y el estado del efecto son independientes. Una operación fallida o cancelada puede dejar efectos parciales, y cancelar es una solicitud idempotente de mejor esfuerzo, no la prueba de que nada ocurrió.
  • Una parada con consecuencias necesita su propio recibo: pasos exactos, fase, efecto, secuencia, estado de la cancelación, observaciones pendientes y necesidad de conciliación.

Contar pasos no mide consecuencias

El registro de Datatracker identifica Agent Infrastructure Control Protocol (AICP) como la revisión 00 de un Internet-Draft individual de Tihan-Nico Paxton, actualizado el 2 de septiembre de 2026. El encabezado apunta a Standards Track, pero esa es la intención del autor, no el estado institucional presente. No constan flujo RFC, Area Director responsable ni teleconferencia. La explicación oficial de la IETF añade la cautela decisiva: cualquiera puede presentar un Internet-Draft y el documento no adquiere posición formal por publicarse.

El borrador aborda una ambigüedad cotidiana. La barra de progreso suele mezclar tres preguntas: cuánto itinerario se ha recorrido, qué probabilidad hay de terminar bien y hasta cuándo puede interrumpirse sin daño. Las tres pueden divergir.

Pensemos en dos planes de cinco pasos. En el primero, la modificación irreversible ocurre al principio y después vienen cuatro verificaciones. En el segundo, cuatro lecturas preparan una única escritura final. Un 20 % en el primero puede esconder el efecto decisivo; un 80 % en el segundo puede no haber producido ninguno. El número de pasos no informa sobre su peso causal.

La revisión archivada mantiene la diferencia. El progreso identifica los pasos completados, activos y totales. Esos conjuntos son la referencia autoritativa. El porcentaje opcional solo sirve de orientación y no puede usarse ni como probabilidad de éxito ni como frontera segura de cancelación.

El borrador no define una correspondencia entre porcentaje y magnitud del efecto. Tampoco autoriza a deducir none de 0 % ni complete de 100 %. Cualquier pantalla que ofrezca esas equivalencias estará añadiendo una política propia.

El ciclo de vida va por un carril y los efectos por otro

AICP describe una Operation que puede estar en cola, pendiente de aprobación, ejecutándose, verificándose, pausada, completada con éxito, fallida, cancelada o indeterminada. En paralelo, asigna un estado de efecto: ninguno, posible, parcial, completo, revertido o desconocido.

La independencia es deliberada. Una operación fallida puede haber alcanzado un sistema externo. Una cancelada puede conservar cambios parciales. Una exitosa puede registrar efectos secundarios. El proveedor debe actualizar el efecto con criterio conservador, sin convertir una falta de observación en certeza de ausencia.

El Outcome terminal conserva todavía más matices. Separa lo que se esperaba cambiar de lo que se observó, incluye efectos secundarios, evidencias y acciones siguientes, y evalúa criterios como satisfechos, insatisfechos, desconocidos o no evaluados. Que las llamadas a una API hayan respondido correctamente no basta para declarar éxito.

Por eso una barra no puede representar fielmente el estado del control. Ubicación en el plan, fase operativa, efecto material y calidad de la evidencia son dimensiones distintas. Comprimirlas en un color y un número hace que el diseño visual adopte decisiones que el protocolo dejó abiertas.

Cancelar no equivale a borrar

La cancelación en AICP es una solicitud de control separada e idempotente. Puede repetirse sin crear nuevas cancelaciones por un fallo de red, pero su ejecución es de mejor esfuerzo. Si la solicitud compite con la finalización, el proveedor devuelve la Operation actual. Las reglas de pausa y reanudación dependen del perfil; al reanudar deben revisarse autoridad, restricciones y precondiciones.

El resultado debe incluir fase terminal y estado del efecto. El proveedor no puede afirmar que cancelled significa que no hubo efecto. Ese límite invalida la idea de «cancelar mientras la barra esté por debajo de X». El paso activo puede haber emitido ya una orden; un paso anterior puede contener la única mutación; o la observación puede llegar después de la decisión.

La compensación tampoco es una película al revés. Revertir requiere otra acción con autorización y riesgos propios. Puede fallar o añadir efectos laterales. Incluso reversed debe basarse en observaciones del resultado, no en la esperanza de restaurar todas las condiciones anteriores.

También el reintento exige un juicio separado. AICP advierte que efectos posibles, parciales o desconocidos no deben provocar una repetición ciega. El problema puede declarar si es seguro reintentar y si primero hace falta conciliar. Ni un timeout ni un porcentaje bajo responden esa pregunta.

El recibo que falta al pulsar detener

Mi propuesta es emitir un recibo de parada siempre que pausar o cancelar pueda tener consecuencias. No forma parte de las obligaciones de la revisión 00. Es una manera de transportar hasta la decisión humana las distinciones que AICP ya conserva.

Ese recibo identificaría la Operation durable y su última secuencia. Mostraría literalmente los pasos completados, activos y totales, junto con la fase y el estado del efecto en campos distintos. Añadiría la identidad y el estado de la solicitud de cancelación, las observaciones aún pendientes y la indicación de si es obligatorio conciliar antes de reintentar o compensar.

También separaría cambio esperado de cambio observado. Si un paso debía revocar un permiso y todavía no existe lectura independiente, la frase correcta es «revocación esperada; efecto desconocido». El 35 % no vuelve más comprobable esa afirmación.

El derecho de Heng Lu a registros precisos aporta una pauta editorial: un registro describe la realidad, no la crea. Por analogía, el recibo no debería inventar seguridad ni probabilidades donde solo existen pasos y observaciones incompletas. Es una aplicación analítica, no una atribución de esta propuesta a Heng Lu o a la IETF.

Una propuesta sin despliegue demostrado

La revisión 00 incluye un bucle HTTP de ejemplo e invariantes del protocolo. No encontré una sección Implementation Status. Las fuentes revisadas no prueban implementación independiente, despliegue productivo, interoperabilidad ni adopción por la IETF. La guía del RFC Editor recuerda que un Internet-Draft puede cambiar, caducar o no convertirse nunca en RFC.

La prueba importante será si una implementación conserva combinaciones incómodas: 0 % con efecto posible, 100 % con criterio insatisfecho, cancelación con efecto parcial o fase indeterminada con observación pendiente. Una interfaz que no pueda mostrarlas habrá descartado precisamente la cautela que hace útil la propuesta.

Fuentes

  1. IETF Datatracker: Agent Infrastructure Control Protocol
  2. Archivo IETF: draft-paxton-aicp-00
  3. IETF: qué son los Internet-Drafts
  4. RFC Editor: cómo se crean los RFC
  5. Heng Lu: The Bill of Rights of Uniqueness Coordination