Agent Client Protocol — ACP
Problema que resuelve
Agent Client Protocol estandariza la interacción entre coding agents y clientes como editores, IDEs u otras interfaces compatibles. Su propósito es desacoplar la integración: el editor no debería necesitar un contrato completamente distinto para cada agente, ni el agente implementar cada interfaz particular para llegar al usuario. Es un protocolo de comunicación, no un framework de agentes ni una configuración de especialista.
En desarrollo, la interacción abarca más que mostrar una respuesta final. La persona necesita enviar un encargo, observar progreso, comprender acciones propuestas y continuar una conversación. El agente puede necesitar información o capacidades del cliente. ACP ofrece una frontera común para esa colaboración, manteniendo separadas la experiencia del cliente y la implementación del sistema que realiza el trabajo.
La introducción oficial contempla escenarios locales y remotos. Eso no demuestra que cada transporte o función tenga igual madurez. Tampoco obliga a usar un editor concreto: el rol cliente puede implementarse en distintas superficies compatibles. La utilidad depende de los contratos efectivamente compartidos, no de que ambos productos anuncien soporte genérico para agentes.
Estado actual y gobernanza
Consulta del 2026-10-27: el proyecto mantiene v1 como protocolo estable y publica v2 como borrador. La documentación v1 es la referencia de las interacciones descritas aquí; la línea v2 no se presenta como contrato estable de implementación. El concepto e ID no incorporan una versión particular.
La gobernanza publicada es interina y conjunta entre Zed y JetBrains, con intención de transición hacia una fundación independiente. Se registra como hecho fechado, sin atribuirle una transición ya completada. El proyecto y su proceso abierto no convierten a ACP en propiedad conceptual de un editor ni justifican asumir adopción universal.
El repositorio oficial distingue versión del protocolo de versiones del crate y los artefactos JSON Schema. Dos releases de schema pueden describir el mismo contrato wire con diferencias para generación de código. Para compatibilidad interesan la versión intercambiada y las capacidades; el número de un SDK no constituye por sí solo esa evidencia.
ACP significa aquí Agent Client Protocol. No se utiliza para Agent Communication Protocol, otro proyecto cuyo proceso de convergencia con A2A describe la comunicación oficial de AAIF. Compartir acrónimo no identifica el mismo protocolo. El título completo evita trasladar a este canonical el historial o estado de otra iniciativa.
Agent y Client
ACP Client conduce la superficie desde la que la persona interactúa con el agente. ACP Agent implementa el participante que recibe trabajo y comunica actividad bajo ese protocolo. coding-agent describe el sistema que realiza tareas de software; ACP define una de sus posibles fronteras de integración. Un rol protocolar no redefine por completo el concepto general de agents.
| Rol | Responsabilidad de integración | Límite |
|---|---|---|
| Client | Presentar interacción y ofrecer capacidades declaradas. | No es automáticamente un MCP Client. |
| Agent | Recibir encargos y comunicar actividad/resultados. | No es una definición de perfil ni un SDK. |
La palabra client también existe en MCP y en APIs genéricas. En model-context-protocol, el cliente habla con un servidor de capacidades desde un host. En ACP, participa en una interacción de tarea/sesión con el agente. Un IDE podría tener ambos roles en integraciones distintas; la similitud de nombres no los vuelve intercambiables ni determina quién inicia todas las operaciones.
Inicialización y capacidades
La inicialización v1 intercambia versión, capacidades y métodos de autenticación antes de crear sesiones. El cliente puede anunciar funciones que el agente utilizará cuando sean compatibles. Esta negociación informa soporte; no demuestra autorización comercial, disponibilidad permanente de recursos o confianza en todos los mensajes recibidos.
Discovery tampoco es aquí necesariamente un catálogo universal de agentes. Elegir o localizar un participante puede involucrar configuración o un registro del ecosistema, mientras la inicialización establece capacidades entre los participantes seleccionados. Conviene separar encontrar una implementación, poder comunicarse con ella y permitir que actúe sobre un repositorio determinado.
Una función opcional ausente requiere adaptación o un límite explícito. El cliente no debe presentar como disponible una acción solamente porque existe en otra implementación. A la inversa, negociar capacidades comunes no obliga a ofrecer todas en cada tarea. La política de producto y la autorización del usuario conservan un alcance que el intercambio técnico no reemplaza.
Sesiones, turnos y actualizaciones
En Session Setup, una sesión identifica una conversación o thread con contexto, historia y estado propios. Crear y, cuando exista soporte, retomar sesiones son funciones protocolarias. Session no equivale a toda memoria del agente, a un sandbox o al workspace completo. Su persistencia tampoco garantiza que el código externo permanezca igual entre turnos.
El Prompt Turn comienza con un mensaje del usuario y puede abarcar varias interacciones con el modelo y herramientas antes de una respuesta de cierre. El agente comunica actividad mediante actualizaciones. Por eso una solicitud de alto nivel puede producir progreso incremental sin que el cliente conduzca cada microacción del trabajo.
La persona puede necesitar interrumpir el turno. Cancelación comunica esa intención bajo el contrato correspondiente; no debe interpretarse como rollback universal ni eliminación de cualquier efecto previo. Una edición o llamada externa ya realizada necesita evaluación propia. Un estado de turno finalizado tampoco prueba que todos los criterios del encargo se hayan cumplido.
Tools, planes y capacidades del cliente
ACP v1 permite que el agente reporte tool calls y sus cambios de estado. Esa representación ayuda al cliente a mostrar actividad, pero no es el mismo contrato que exponer una MCP Tool. La herramienta puede ser interna del agente o utilizar otra integración. Reportar una operación y proporcionar la capacidad que la ejecuta son responsabilidades diferentes.
Filesystem y terminal son capacidades opcionales del cliente en v1. Su presencia permite ciertas interacciones soportadas; no significa que toda acción del agente ocurra dentro de ese cliente. Un proceso agente puede ejecutar operaciones mediante sus propios recursos. La evaluación de permisos debe localizar dónde ocurre cada efecto, en vez de asumir que la UI intercepta todo.
Los planes comunicados al cliente ayudan a observar intención y progreso. No sustituyen evidencia de acciones realizadas. task-prompts expresa el encargo; development-context-and-execution-records conserva qué ocurrió y qué quedó sin comprobar. Una lista marcada en la interfaz y un resultado comercial correcto son afirmaciones distintas que necesitan evidencia adecuada.
Permisos, autenticación y confianza
Las solicitudes de permiso pueden comunicar opciones y decisiones del usuario. La guía de seguridad v1 aclara que son advisory para operaciones propias del agente: el agente es responsable de respetarlas. El cliente realiza las operaciones de filesystem/terminal que él mismo ofrece. Esa separación impide afirmar que el protocolo impone aislamiento o enforcement completo sobre un proceso externo.
La autenticación se negocia según métodos anunciados. Autenticar una relación o cuenta no autoriza cualquier cambio en el código ni publicación. agent-permissions-and-approval-boundaries conserva esas decisiones; agent-sandboxing delimita restricciones técnicas. ACP puede comunicar aprobación sin convertirse en la política organizacional ni en el sandbox.
Mensajes, rutas y URIs del agente necesitan tratamiento según procedencia y controles del cliente. Texto leído en archivos o servicios externos puede influir en la salida. Una UI que muestra una acción propuesta no demuestra que el texto sea confiable o que la acción quede técnicamente restringida. La integración necesita preservar esa frontera, sin presentar interoperabilidad como garantía de ejecución segura.
Transportes, extensiones y fallos
La documentación de transportes v1 define stdio y muestra Streamable HTTP como propuesta en borrador; permite transportes personalizados. No corresponde elevar ese borrador a soporte estable universal ni equiparar ejecutar un CLI en terminal con hablar ACP. Stdin/stdout puede transportar muchos contratos; importan los mensajes y su semántica.
La extensibilidad v1 contempla metadata y métodos personalizados con convenciones para evitar colisiones. Extensión soportada por un participante no implica soporte de todo cliente. Depender de funciones particulares puede reducir compatibilidad aunque ambos lados implementen el núcleo. Eso merece identificación explícita, no una afirmación de portabilidad total.
Los fallos pueden ser incompatibilidad de versión, capacidad ausente, error de herramienta, rechazo de permiso o desconexión. No son intercambiables. Una actualización interrumpida puede dejar el resultado de una operación desconocido. El cliente necesita distinguir «no observado» de «no realizado», y el agente conservar la evidencia antes de repetir efectos o declarar terminación.
ACP frente a LSP, MCP y A2A
Language Server Protocol integra editores con funciones de lenguaje como navegación y completado. ACP trata interacción con un sistema de coding que recibe encargos y comunica actividad. El parentesco de desacoplar integraciones no implica reemplazo general de LSP. Un editor puede utilizar ambos para responsabilidades distintas.
MCP conecta aplicaciones con capacidades/contexto; ACP integra cliente y coding agent. Llamarlo simplemente «MCP para IDEs» oculta sesiones, interacción y roles diferentes. agent2agent-protocol aborda trabajo entre sistemas agentes; ACP no se convierte automáticamente en ese contrato porque el cliente contenga lógica AI. Las fronteras principales orientan análisis sin ser capas excluyentes.
Interoperabilidad permite comunicar bajo un contrato común. Portabilidad exige que una implementación o artefacto pueda trasladarse conservando lo necesario. ACP no garantiza portar herramientas, skills o conducta entre agentes. La compatibilidad efectiva depende de versión, capacidades y extensiones. Compartir protocolo no elimina diferencias de calidad, permisos o entorno.
Interpretar una interacción de desarrollo
En la composición de Commerce, el cliente puede mostrar el encargo de revisar una migración y recibir un plan propuesto por el agente. Una actualización indica que comenzó una comprobación; otra informa su resultado. La UI necesita preservar esas diferencias para que la persona comprenda qué ocurrió. Mostrar el plan como si fuera evidencia o resumir un fallo como una tarea completada cambiaría el significado del trabajo aunque los mensajes se hayan transmitido correctamente.
Si aparece una solicitud de permiso, interesa el efecto propuesto y su destino. Aprobar una lectura del repositorio no autoriza desplegar el resultado de la migración. Una descripción producida por el agente puede ayudar a presentar la operación, pero no debe convertirse por sí sola en fundamento de una aprobación automática. La integración necesita conservar el límite entre datos de presentación, decisión del usuario y controles efectivos del proceso que actuará.
Retomar la sesión después de cambios externos requiere revisar el estado relevante. La historia puede explicar por qué se propuso una opción sin demostrar que siga siendo válida. El cliente y el agente pueden mantener continuidad comunicativa mientras el workspace cambió. Esa posibilidad conecta protocolo y Context Engineering: una sesión reconocida no elimina el trabajo de actualizar evidencia antes de continuar ni concede autoridad para descartar modificaciones que otro participante realizó.
Relaciones en el Atlas
agent-harness puede exponer la interacción ACP de un agente, sin ser el protocolo ni necesitar implementarlo. agent-profiles configura una especialización; no es una sesión ni un participante ejecutando trabajo. agent-extension-packages puede distribuir una integración ACP; empaquetar no cambia el contrato protocolar. Ninguno de esos artefactos concede autoridad adicional por ser compatible.
ai-assisted-software-engineering conecta este canonical con contexto, instrucciones y artefactos. Los workflows concretos de desarrollo quedan posteriores. Aquí se explica por qué un cliente puede comunicarse con un agente sin compartir su implementación interna, sin configurar un endpoint ni prometer que cualquier combinación de productos funcionará de forma idéntica.
Fuentes
Fuentes primarias consultadas el 2026-10-27. Las comparaciones y consecuencias de diseño son síntesis editorial; el comportamiento versionado corresponde a ACP v1 salvo referencia explícita al borrador.
- ACP: Introduction, v1 overview, v2 draft, governance y repositorio oficial.
- Initialization, Session Setup, Prompt Turn y Tool Calls.
- Authentication, Security, Transports y Extensibility.
- LSP: página oficial y AAIF: A2A joins AAIF, para aclarar fronteras y la colisión de acrónimo.