# agentclientprotocol-introduction-2026-08-02

## Veille

Página de aterrizaje de la **especificación oficial** del **Agent Client Protocol (ACP)** (`agentclientprotocol.com/get-started/introduction`), consultada el **2 de agosto de 2026**. No se trata de un artículo fechado sino de un **artefacto vivo**: la ficha se fecha por su observación, no por una fecha de publicación. **Declaración de misión en una frase**: *« The Agent Client Protocol (ACP) standardizes communication between code editors/IDEs and coding agents and is suitable for both local and remote scenarios. »* **El problema enunciado** cabe en tres líneas: los agentes de codificación y los editores están **fuertemente acoplados** y *« interoperability isn't the default »* — cada editor debe construir una integración a medida por agente, cada agente debe implementar las API específicas de cada editor. Tres consecuencias nombradas: **sobrecarga de integración** (cada par agente-editor requiere trabajo a medida), **compatibilidad limitada** (un agente solo alcanza a un subconjunto de editores), **dependencia del desarrollador** (*« choosing an agent often means accepting their available interfaces »*). **La solución está explícitamente modelada sobre LSP** — *« similar to how the Language Server Protocol (LSP) standardized language server integration »* — con el beneficio mutuo: un agente que habla ACP funciona con **cualquier** editor compatible, un editor que soporta ACP gana acceso al **conjunto** del ecosistema de agentes ACP. **Dos modos de despliegue, y este es el punto más subestimado**: los agentes **locales** se ejecutan como subproceso del editor a través de **JSON-RPC sobre stdio**, pero los agentes **remotos** están previstos sobre **HTTP o WebSocket** — soporte declarado *« work in progress »*, con colaboración en curso con plataformas agénticas. **Linaje técnico con MCP, más fuerte que una simple complementariedad**: ACP *« re-uses the JSON representations used in MCP where possible »*, añadiendo tipos específicos a las necesidades de UX de codificación agéntica (la visualización de **diff** es el ejemplo dado); el formato por defecto para texto legible es **Markdown**, elegido para que el editor no esté obligado a renderizar HTML. **Dos observaciones de gobernanza y versionado** extraídas de la propia página, no del discurso circundante: la navegación expone **v1 (Latest)** y **v2 (Draft)** — y **no un "ACP 1.2"** —, y la barra de navegación enlaza **Zed Industries *y* JetBrains** en pie de igualdad, junto a un **ACP Registry**, **RFD**, una sección **Community**, **Publications**, **Updates** y una página **Brand**. Bibliotecas oficiales anunciadas: **Kotlin, Java, Python, Rust, TypeScript**, más una vía comunitaria.

## Titre Article

Agent Client Protocol — Introduction

## Date

2026-08-02

## URL

https://agentclientprotocol.com/get-started/introduction

## Keywords

Agent Client Protocol, ACP, protocolo abierto, especificación, interoperabilidad, desacoplamiento editor-agente, LSP, Language Server Protocol, JSON-RPC, stdio, subproceso, agentes locales, agentes remotos, HTTP, WebSocket, work in progress, MCP, Model Context Protocol, reutilización de representaciones JSON, tipos personalizados, visualización de diff, Markdown, sobrecarga de integración, compatibilidad limitada, dependencia del desarrollador, dependencia del desarrollador, N+M, ecosistema de agentes, Zed Industries, JetBrains, ACP Registry, registro de agentes, RFD, request for discussion, gobernanza del protocolo, v1 latest, v2 draft, versionado de la especificación, bibliotecas cliente, Kotlin, Java, Python, Rust, TypeScript, Mintlify, documentación viva, llms.txt

## Authors

**Projet Agent Client Protocol** — spécification collective, sans signature individuelle sur cette page. La barre de navigation du site lie deux organisations au même niveau : **Zed Industries** (à l'origine du protocole) et **JetBrains**. La présence d'une section **RFDs** (*requests for discussion*), d'une page **Community** et d'un **ACP Registry** indique une structure de gouvernance ouverte plutôt qu'une documentation produit.

Documentation construite et hébergée sur **Mintlify**. La page expose un `llms.txt` en tête (*« Fetch the complete documentation index at: /llms.txt — Use this file to discover all available pages before exploring further »*) : le site est explicitement outillé pour être lu par des agents.

## Ton

**Perfil**: página de introducción de una **especificación técnica abierta**, en el registro de un *organismo de estandarización* más que de marketing de producto. Muy breve — dos secciones (`Why ACP?`, `Overview`) — y enteramente construida para ser citada.

**Estilo**: la forma canónica del discurso de presentación de un protocolo abierto, en tres tiempos mecánicos: (1) **nombrar el acoplamiento existente**, (2) **enumerar sus costes** en tres viñetas simétricas, (3) **enunciar la analogía legitimadora**. La analogía con LSP hace todo el trabajo retórico: transporta un precedente que el lector ya ha aceptado (LSP sí desacopló editores y lenguajes) a un dominio donde la demostración aún está por hacer. Economía de medios notable — sin promesa cuantificada, sin beneficio de negocio, sin mención a un competidor.

Dos marcadores de contención que generan confianza: la admisión de que el soporte de agentes remotos es *« a work in progress »*, y la **justificación basada en restricciones** para la elección de Markdown (*« without requiring that the code editor is capable of rendering HTML »*) — una decisión de diseño explicada por lo que **no** impone al implementador, que es el instinto correcto para un protocolo que busca adoptantes.

**Frases marcadoras**: *« interoperability isn't the default »*, *« Every new agent-editor combination requires custom work »*, *« choosing an agent often means accepting their available interfaces »*, *« Agents that implement ACP work with any compatible editor »*, *« This decoupling allows both sides to innovate independently »*.

## Pense-betes

- **La frase para recordar**: *« AI coding agents and editors are tightly coupled but interoperability isn't the default. »* Todo el protocolo se deriva de esta observación.
- **Los tres costes del acoplamiento** (estructura a reutilizar tal cual en presentaciones): **sobrecarga de integración** — cada combinación agente×editor requiere trabajo a medida; **compatibilidad limitada** — un agente solo alcanza a un subconjunto de editores; **dependencia del desarrollador** — elegir un agente significa aceptar sus interfaces. Los tres son costes **distintos** (producción, distribución, libertad), no tres formulaciones de uno solo.
- **La analogía con LSP hace el trabajo**: *« similar to how the Language Server Protocol standardized language server integration »*. Es eficaz porque el precedente ya está aceptado. Pero también es **donde conviene la cautela**: LSP estandariza un intercambio en gran medida **determinista** (posiciones, símbolos, diagnósticos); ACP estandariza la interfaz de un agente **no determinista**, que negocia permisos, produce diffs, y cuyo comportamiento varía de una ejecución a otra. La forma del problema es la misma; la naturaleza de lo que pasa por ella no lo es. La página no aborda esta brecha.
- **Dos modos de transporte, no uno** — el punto más subestimado en la cobertura secundaria:
- **Agentes locales**: subproceso del editor, **JSON-RPC sobre stdio**. Es el modo conocido, el que todos citan.
- **Agentes remotos**: alojados en la nube o en infraestructura separada, **HTTP o WebSocket**. Declarado *« work in progress »*, con colaboración activa con plataformas agénticas. → **Consecuencia**: ACP no es estructuralmente un protocolo de "puesto de trabajo". Su trayectoria apunta al agente alojado, de ahí la empresa. Resumir ACP como "JSON-RPC sobre stdio" describe su presente, no su objetivo.
- **La relación con MCP es un linaje, no una simple complementariedad**: *« The protocol re-uses the JSON representations used in MCP where possible. »* Se suele decir que "ACP y MCP se apilan" (el cliente habla ACP con el agente, el agente habla MCP con sus herramientas) — cierto en el plano arquitectónico, pero **incompleto**: ACP **toma prestadas las estructuras de datos de MCP**. Los dos protocolos no son solo vecinos, comparten un vocabulario de serialización. Ver [[girard-acp-deux-protocoles-un-sigle-2026-08-02]] para la distinción funcional.
- **Extensiones específicas de la codificación agéntica**: ACP añade *« custom types for useful agentic coding UX elements, like displaying diffs »*. Esto es lo que justifica que ACP exista **además de** MCP: un diff a aprobar no es una llamada a herramienta, es un elemento de interfaz que requiere una decisión humana. **El protocolo codifica el momento de revisión**, no solo la ejecución.
- **Markdown por defecto, y la razón enunciada**: *« which allows enough flexibility to represent rich formatting without requiring that the code editor is capable of rendering HTML »*. Una decisión de diseño justificada por la **carga que ahorra al implementador** — el instinto correcto para un protocolo que busca adopción. Vale la pena señalarlo para quien diseñe un protocolo: reducir el coste de entrada en el lado que se quiere reclutar.
- **Corrección de versionado**: la navegación de la especificación expone **`v1` (Latest)** y **`v2` (Draft)**. **No** expone un "ACP 1.2". Esta cifra, que circula en la cobertura secundaria (y que quedó registrada como no verificada en [[girard-acp-deux-protocoles-un-sigle-2026-08-02]]), **no está corroborada por la fuente primaria**. Citar **v1 / v2 draft**.
- **Corrección de gobernanza**: la frase "Zed lo lanzó y luego lo soltó" es demasiado fuerte. La barra de navegación enlaza **Zed Industries y JetBrains al mismo nivel**, y la estructura del sitio (**ACP Registry**, **RFD**, **Community**, **Publications**, **Updates**, **Brand**) es la de un **proyecto cogobernado con un proceso**, no un protocolo huérfano ni una documentación de producto. La formulación correcta: **apertura real y cogobernanza, no desprendimiento**.
- **Señal de ecosistema**: bibliotecas oficiales en **Kotlin, Java, Python, Rust, TypeScript** + una vía comunitaria. El par **Kotlin/Java** es el marcador JetBrains — la presencia de ambos indica que la implementación para el IDE de la JVM es de primera clase, no un port tardío.
- **Un detalle revelador**: la página se abre con un enlace a **`/llms.txt`** — *« Use this file to discover all available pages before exploring further »*. La documentación de un protocolo para agentes está ella misma **dotada de herramientas para agentes**. Coherencia del dispositivo, y una señal débil sobre lo que está llegando a ser la documentación técnica.
- **Lo que la página no dice** (no debe rellenarse por inferencia): sin fecha, sin número de versión indicado en el cuerpo, **sin licencia mostrada en esta página**, sin modelo de gobernanza formalizado, sin lista de implementadores. La licencia Apache-2.0 frecuentemente citada para ACP proviene del repositorio, **no de esta página**.
- **Meta / para enlazar**: fuente primaria de las afirmaciones sobre ACP #1 en [[girard-acp-deux-protocoles-un-sigle-2026-08-02]] (a la que corrige en versionado y matiza en gobernanza); a leer junto con [[dethlefsen-zed-anthropic-subscription-changes-2026-05-14]], que muestra lo que vale la opcionalidad aquí prometida el día en que un proveedor cambia sus precios; el desacoplamiento descrito conecta con el contrato de portabilidad analizado en janakiram-agent-platform-portability-contract-2026-07-20; una implementación de referencia del lado del producto en block-goose-mcp-ui-future-agentic-interfaces-2025-08-25. **Desambiguación obligatoria**: aquí, "ACP" se refiere únicamente a **Agent Client Protocol**. Nunca escribir la sigla como una entidad — ver `docs/solutions/conventions/sigles-jamais-entites-graphe.md`.

## RésuméDe400mots

Página de introducción de la especificación del **Agent Client Protocol**, consultada el 2 de agosto de 2026. Un artefacto vivo sin fecha de publicación: la ficha se fecha por su observación.

**El problema.** *« AI coding agents and editors are tightly coupled but interoperability isn't the default. »* Cada editor debe construir una integración a medida para cada agente que desea soportar, y cada agente debe implementar las API específicas de cada editor. De ahí se derivan tres costes distintos: **sobrecarga de integración** (cualquier combinación agente-editor requiere trabajo específico), **compatibilidad limitada** (un agente solo alcanza a una fracción de los editores) y **dependencia del desarrollador** — *« choosing an agent often means accepting their available interfaces »*.

**La solución.** ACP estandariza la comunicación agente-editor *« similar to how the Language Server Protocol (LSP) standardized language server integration »*. El beneficio es mutuo y es lo que mantiene unido al ecosistema: un agente que implementa ACP funciona con cualquier editor compatible; un editor que soporta ACP gana acceso al conjunto del ecosistema de agentes ACP. *« This decoupling allows both sides to innovate independently. »*

**La arquitectura.** ACP asume que el usuario está **principalmente en su editor** y recurre allí a un agente para una tarea específica. Dos modos de despliegue: los agentes **locales** se ejecutan como subproceso del editor y se comunican por **JSON-RPC sobre stdio**; los agentes **remotos**, alojados en la nube o en infraestructura separada, se comunican por **HTTP o WebSocket** — soporte declarado *« a work in progress »*, con colaboración activa con plataformas agénticas. El segundo modo suele omitirse en la cobertura secundaria, aunque traza la trayectoria empresarial del protocolo.

**El vínculo con MCP** es más cercano que una complementariedad arquitectónica: ACP *« re-uses the JSON representations used in MCP where possible »*, añadiendo a la vez tipos específicos a la UX de codificación agéntica — la visualización de **diff** es el ejemplo dado. El formato por defecto para texto legible es **Markdown**, elegido precisamente para que el editor no esté obligado a renderizar HTML.

**Dos observaciones sobre la propia fuente.** La navegación expone **v1 (Latest)** y **v2 (Draft)** — no el "ACP 1.2" que circula en otros lugares. Y enlaza **Zed Industries y JetBrains al mismo nivel**, junto a un **ACP Registry**, **RFD**, una sección Community, Publications, Updates y una página Brand: la estructura de un proyecto cogobernado con un proceso. Bibliotecas oficiales en Kotlin, Java, Python, Rust y TypeScript.

## GrapheDeConnaissance

- Agent Client Protocol —permet→ de standardiser la communication entre éditeurs de code et agents de codage (AFFIRMATION, 0.98)
- Agent Client Protocol —s_inspire_de→ Language Server Protocol (TECHNOLOGIE, 0.96)
- Agent Client Protocol —résout→ le couplage étroit entre agents de codage et éditeurs (AFFIRMATION, 0.95)
- couplage agent-éditeur —s_oppose_à→ l'interopérabilité par défaut (AFFIRMATION, 0.93)
- Agent Client Protocol —réduit→ l'integration overhead, la compatibilité limitée et le verrouillage développeur (AFFIRMATION, 0.94)
- Agent Client Protocol —utilise→ JSON-RPC sur stdio (TECHNOLOGIE, 0.95)
- Agent Client Protocol —utilise→ HTTP ou WebSocket pour les agents distants (TECHNOLOGIE, 0.9)
- Agent Client Protocol —est_basé_sur→ les représentations JSON de Model Context Protocol (AFFIRMATION, 0.93)
- Agent Client Protocol —utilise→ Markdown (TECHNOLOGIE, 0.92)
- Agent Client Protocol —permet→ l'affichage de diffs et autres éléments d'UX propres au codage agentique (AFFIRMATION, 0.9)
- Zed Industries —a_créé→ Agent Client Protocol (TECHNOLOGIE, 0.9)
- JetBrains —collabore_avec→ Zed Industries (ORGANISATION, 0.88)
- Agent Client Protocol —publie→ une spécification versionnée v1 (Latest) et v2 (Draft) (AFFIRMATION, 0.9)
- ACP Registry —fait_partie_de→ Agent Client Protocol (TECHNOLOGIE, 0.88)
- Agent Client Protocol —affirme_que→ le support complet des agents distants est encore un travail en cours (AFFIRMATION, 0.93)

---
Canonical: https://www.thekb.eu/es/fiches/agentclientprotocol-introduction-2026-08-02/