# agentclientprotocol-introduction-2026-08-02

## Veille

Página de destino 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 planteado** 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 APIs específicas de cada editor. Tres consecuencias nombradas: **sobrecarga de integración** (cada par agente-editor requiere trabajo específico), **compatibilidad limitada** (un agente solo alcanza un subconjunto de editores), **dependencia del desarrollador** (*"choosing an agent often means accepting their available interfaces"*). **La solución se modela explícitamente sobre LSP** — *"similar to how the Language Server Protocol (LSP) standardized language server integration"* — con un beneficio recíproco: un agente que habla ACP funciona con **cualquier** editor compatible, un editor que soporta ACP obtiene acceso a **todo** el 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 mediante **JSON-RPC sobre stdio**, pero los agentes **remotos** están previstos sobre **HTTP o WebSocket** — soporte indicado como *"work in progress"*, con colaboración en curso con plataformas agénticas. **Filiación técnica 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 propias de la codificación agéntica (la visualización de **diffs** 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** señaladas en la página y ausentes 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**, **RFDs**, una sección **Community**, **Publications**, **Updates**, y una página **Brand**. Bibliotecas oficiales anunciadas: **Kotlin, Java, Python, Rust, TypeScript**, además de 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 diffs, 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 de protocolo, v1 latest, v2 draft, versionado de 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 normalización* más que de marketing de producto. Muy breve — dos secciones (`Why ACP?`, `Overview`) — y construida íntegramente para ser citada.

**Estilo**: la forma canónica del discurso de venta del protocolo abierto, en tres movimientos mecánicos: (1) **nombrar el acoplamiento existente**, (2) **enumerar sus costes** en tres puntos simétricos, (3) **enunciar la analogía legitimadora**. La analogía con LSP hace todo el trabajo retórico: traslada 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 — ninguna promesa cuantificada, ningún beneficio de negocio, ninguna mención de 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 **por restricción** de 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, 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 reutilizable tal cual en presentaciones): **sobrecarga de integración** — cada combinación agente×editor requiere trabajo a medida; **compatibilidad limitada** — un agente solo alcanza un subconjunto de editores; **dependencia del desarrollador** — elegir un agente implica aceptar sus interfaces. Los tres son costes **distintos** (producción, distribución, libertad), no tres formulaciones del mismo coste.
- **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 es también **donde se impone 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 circula por él no lo es. La página no discute 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**. Este es el modo conocido, el que todos citan.
- **Agentes remotos**: alojados en la nube o en infraestructura separada, **HTTP o WebSocket**. Indicado como *"work in progress,"* con colaboración activa con plataformas agénticas. → **Consecuencia**: ACP no es estructuralmente un protocolo de "estación 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 una filiación, 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 términos arquitectónicos, pero **incompleto**: ACP **toma prestadas las estructuras de datos de MCP**. Los dos protocolos no son meramente vecinos, comparten un vocabulario de serialización. Ver [[girard-acp-deux-protocoles-un-sigle-2026-08-02]] para la distinción funcional.
- **Las 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 la existencia de ACP **junto a** MCP: un diff que aprobar no es una llamada a una 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 indicada**: *"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. A tener en cuenta para quien diseñe un protocolo: reducir el coste de entrada del 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." Este número, que circula en la cobertura secundaria (y que se registró como no verificado en [[girard-acp-deux-protocoles-un-sigle-2026-08-02]]), **no está corroborado 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**, **RFDs**, **Community**, **Publications**, **Updates**, **Brand**) es la de un **proyecto co-gobernado y con un proceso**, no la de un protocolo huérfano o documentación de producto. El encuadre correcto: **apertura real y co-gobernanza, no abandono**.
- **Señal de ecosistema**: bibliotecas oficiales en **Kotlin, Java, Python, Rust, TypeScript** + una vía comunitaria. El emparejamiento **Kotlin/Java** es el marcador de JetBrains — la presencia de ambos indica que la implementación para IDE de la JVM es de primera clase, no un puerto tardío.
- **Un detalle revelador**: la página abre con un puntero hacia **`/llms.txt`** — *"Use this file to discover all available pages before exploring further."* La documentación de un protocolo para agentes está ella misma **instrumentada 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 a menudo citada para ACP proviene del repositorio, **no de esta página**.
- **Meta / referencias cruzadas**: 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 cuánto vale la opcionalidad prometida aquí el día en que un proveedor cambia su tarificación; el desacoplamiento descrito aquí se 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**: "ACP" aquí se refiere únicamente a **Agent Client Protocol**. No introducir nunca el acrónimo como 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 quiera soportar, y cada agente debe implementar las APIs 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 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 recíproco, y eso es lo que mantiene unido al ecosistema: un agente que implementa ACP funciona con cualquier editor compatible; un editor que soporta ACP obtiene acceso a todo el 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 a un agente para una tarea específica. Dos modos de despliegue: los agentes **locales** se ejecutan como subproceso del editor y se comunican mediante **JSON-RPC sobre stdio**; los agentes **remotos**, alojados en la nube o en infraestructura separada, se comunican mediante **HTTP o WebSocket** — soporte indicado como *"a work in progress,"* con colaboración activa con plataformas agénticas. Este segundo modo se omite sistemáticamente en la cobertura secundaria, aunque traza la trayectoria empresarial del protocolo.

**El vínculo con MCP** es más estrecho que una complementariedad arquitectónica: ACP *"re-uses the JSON representations used in MCP where possible,"* añadiendo tipos específicos para la UX de la codificación agéntica — la **visualización de diffs** 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**, **RFDs**, una sección Community, Publications, Updates y una página Brand: la estructura de un proyecto co-gobernado y 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/