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.
#Agent Client Protocol#ACP#protocolo abierto
**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.
Artículo de estilo manifiesto de **Thariq Shihipar** (Ingeniero y emprendedor serial, equipo de Claude Code en Anthropic) que anuncia un **cambio en el formato de salida por defecto para agentes**: sustituir **Markdown por HTML**. Tesis: Markdown ha sido el formato dominante entre humanos y agentes (simple, portátil, editable, legible), pero se ha convertido en **un cuello de botella** a medida que los agentes producen artefactos más largos y ricos (specs, planes, informes, revisión de código). Más allá de ~100 líneas, nadie vuelve a leer ya un archivo Markdown. HTML resuelve seis limitaciones a la vez: **densidad de información** (tablas, CSS, SVG, scripts, canvas, imágenes), **claridad visual** (diseño navegable, responsive para móvil), **facilidad para compartir** (un enlace S3 abrible directamente en un navegador), **interactividad bidireccional** (sliders, mandos, botones "copy as JSON/prompt" para reinyectar en Claude Code), **ingesta contextual nativa** (Claude Code lee el codebase + MCP Slack/Linear + historial git + Chrome) y **disfrute** (el autor afirma explícitamente que *"es placentero"*). Se detallan cinco usos canónicos: (1) **specs/planes/exploración** en una cuadrícula comparativa, (2) **revisión de PR** con diff anotado en línea, (3) **diseño y prototipos** con sliders de animación, (4) **informes/investigación/aprendizaje** (el autor generó un explicador sobre prompt-caching a partir del historial git), (5) **editores desechables a medida** (drag-and-drop de tickets de Linear, editores de feature flags, prompt-tuner lado a lado) que producen una exportación reinyectable "copy as markdown/diff/JSON". Antipatrón explícito: *"me da un poco de miedo que la gente lea este artículo y lo convierta en una skill /html"* — el autor **rechaza la skill-ificación prematura**, y recomienda partir de un prompt desde cero ("haz un archivo HTML"). FAQ pragmática: coste en tokens absorbido por el contexto de 1MM de **Opus 4.7**, generación 2-4× más lenta, diffs HTML ruidosos (un inconveniente real), estilo mantenido bajo control mediante un design system HTML de referencia.
#HTML#Markdown#formato de salida
Thariq Shihipar (Engineer & serial entrepreneur, équipe Claude Code chez Anthropic — site : thariqs.github.io/html-effectiveness ; X : @trq212)