# KCP: La pieza que falta para escalar el “agentic web” *(Resumen y comentario sobre el artículo de Thor Henning Hetland:* [*“The Autonomous Agentic Web Needs a Foundation Layer”*](https://wiki.totto.org/blog/2026/03/13/the-autonomous-agentic-web-needs-a-foundation-layer/#what-needs-to-happen)*)* Este artículo **no es una idea mía**: es un intento de **amplificar y hacer ruido** sobre el trabajo de **Thor Henning Hetland** alrededor de **KCP – Knowledge Context Protocol** y la capa de infraestructura que el “agentic web” necesita para escalar de verdad. Si trabajas con agentes, multi‑agente o infraestructura de IA, te recomiendo leer el post original de Thor completo aquí: 👉 [The Autonomous Agentic Web Needs a Foundation Layer](https://wiki.totto.org/blog/2026/03/13/the-autonomous-agentic-web-needs-a-foundation-layer/#what-needs-to-happen). Lo que sigue es una **síntesis en español**, con mis propias palabras, de las ideas clave de ese artículo, más un ejemplo práctico de cómo ya me estoy beneficiando de esta visión en un proyecto real. * * * ## **¿Qué se ha construido ya?** Thor parte de algo muy concreto: **las piezas del agentic web ya existen**. * **Capa de modelo** Tenemos modelos capaces de razonar, planificar, escribir código y manejar contextos largos. Para muchos usos prácticos, esto está “suficientemente resuelto”. * **Capa de integración de herramientas (MCP)** El **Model Context Protocol (MCP)** se ha convertido en el estándar dominante para conectar agentes con APIs, bases de datos y servicios externos. Un agente que habla MCP puede usar GitHub, Slack, bases de datos, etc., a través de una interfaz consistente. Es el equivalente “agentic” de la economía de APIs: interfaces bien definidas que los agentes pueden invocar. * **Capa de flujo de trabajo de desarrollo** Herramientas como **Claude Code** permiten que los agentes trabajen **dentro de los repositorios**, con contexto de estructura, historia y convenciones del proyecto. De esta realidad de “agentes trabajando en código real” es de donde acaba emergiendo **KCP**. * **Capa de orquestación** Frameworks de **multi‑agente** que: * crean sub‑agentes especializados, * encadenan tareas entre modelos, * escalan decisiones a humanos cuando la confianza es baja. Cada capa, por separado, funciona. **El hueco está entre ellas.** * * * ## **Tres requisitos para un agentic web componible** Thor identifica tres problemas que se repiten cuando pensamos en un web de agentes realmente componible. ### **1\. Descubrimiento** **Pregunta**: ¿Cómo sabe un agente qué capacidades existen sin que un humano le pegue la documentación delante? Hoy la respuesta es: **no lo sabe**. * Un humano hace el wiring: * integra herramientas, * escribe prompts de sistema, * configura el entorno. * El agente opera dentro de ese conjunto cerrado de herramientas preconfiguradas. Esto sirve para un sistema aislado, pero **no** para un web de agentes donde: * deberían **descubrir** capacidades nuevas, * y **componerlas** aunque nadie se las haya configurado explícitamente. La web resolvió esto con **hipervínculos y buscadores**: un navegador no necesita conocer todos los recursos por adelantado. En el agentic web **todavía no hay equivalente para capacidades**. * * * ### **2\. Declaración de restricciones** **Pregunta**: ¿Cómo sabe un agente qué está realmente autorizado a hacer? Hoy el mecanismo habitual son los **prompts de sistema**: > “Eres un asistente útil. No borres archivos. Pide confirmación antes de enviar correos…” Esto falla por dos motivos: 1. **Fragilidad en los handoffs** * Cuando el **Agente A** delega al **Agente B**, las restricciones se resumen, se parafrasean o se pierden. * El agente delegado no tiene forma fiable de saber qué límites estaban en vigor en la invocación original. 2. **Falta de verificabilidad** * No hay forma de **inspeccionar** qué restricciones aplican a una capacidad **antes** de llamarla. * Todo se basa en confianza implícita y lectura de lenguaje natural. * En un grafo de agentes que cruzan fronteras organizacionales, **esa confianza implícita no escala**. * * * ### **3\. Delegación con integridad** **Pregunta**: ¿Cómo viaja la autoridad a través de las cadenas de delegación entre agentes? En equipos humanos, una buena delegación incluye: * tarea, * contexto, * decisiones ya tomadas, * lo que está fuera de límites, * lo que necesita escalamiento. En agentes hoy, la delegación suele ser **solo transferencia de tarea**: * El sub‑agente recibe instrucciones, * pero **no recibe** de forma estructurada: * el contexto original del solicitante, * qué aprobaciones se obtuvieron, * bajo qué autoridad está actuando. Cada handoff implica un **reset de confianza**: * O das demasiados permisos (riesgo alto), * o tan pocos que el agente no puede acabar el trabajo. * * * ## **Por qué las soluciones obvias no escalan** Thor revisa las respuestas “clásicas” y explica por qué **no sirven a escala web**. ### **Documentación** Publicar **README, OpenAPI, docs** parece una solución razonable al problema de descubrimiento. Pero tiene dos problemas estructurales para agentes: 1. **No viaja** * Vive en URLs que pueden no estar accesibles justo en el momento de la decisión. 2. **No es tipada ni verificable** * El agente lee lenguaje natural e **infiere**: * qué hace la herramienta, * qué límites tiene, * qué requiere aprobación. * La documentación se desincroniza de la realidad y el agente **no puede detectar la deriva**. * * * ### **SDKs de proveedor** Los SDKs resuelven la integración **para un proveedor concreto**, pero: * crean **lock‑in** y **fragmentación**, * cada SDK define su propio modelo de: * capacidades, * restricciones, * delegación. Un agente pensado para el modelo mental de un SDK **no compone nativamente** con otro. Acabamos con **islas de capacidades**. * * * ### **MCP** MCP es **excelente** conectando agentes con herramientas externas. * Define **cómo** llamar a una capacidad, * pero no define de forma estructurada: * para **qué** es óptima, * qué **contexto** necesita, * qué **restricciones** tiene, * qué pasa con el **contexto de delegación** cuando se encadena con otros agentes. MCP resuelve la **capa de ejecución**, **no** la de **conocimiento y restricciones**. * * * ## **La capa que falta: Capability Declaration** La propuesta de Thor es clara: necesitamos una **capa de declaración de capacidades**: > Un estándar que permita a cualquier capacidad (CLI, API, agente, servicio) **declararse a sí misma** de modo que otros agentes puedan consumirla sin: > > * leer documentación, > > * depender de SDKs propietarios, > > * ni fiarse de prompts que se puedan perder o reinterpretar. > Las propiedades que esta capa debe tener: * **Tipada y machine‑readable** Datos estructurados, validados por esquema. Nada de “a ver qué entiende el modelo del texto”. * **Portable entre clientes y modelos** Una declaración válida para una herramienta hoy debería seguir siéndolo para clientes futuros. El valor del estándar es que **sobrevive a las implementaciones**. * **Discoverable** Los agentes deben poder **encontrar** capacidades: * ubicaciones conocidas, * registros, * interfaces de búsqueda. * **Constraint‑carrying** No solo “qué hace”, sino: * qué requiere aprobación, * qué está prohibido, * qué contexto espera, * cómo se maneja la autoridad cuando se invoca desde otro agente. * * * ## **Qué es KCP (Knowledge Context Protocol)** Ahí entra **KCP**. * Un **manifest KCP** es un archivo YAML tipado que describe una capacidad: * qué hace, * con qué contexto trabaja mejor, * qué requiere aprobación humana, * qué restricciones aplican, * cómo debe viajar la autoridad en una cadena de delegación. Con un manifest KCP, un agente puede: * **inspeccionar** una capacidad sin ejecutarla, * decidir si es apropiado usarla, * y saber **bajo qué condiciones y límites** hacerlo. ### **Propiedades clave según la propuesta de Thor** * **Portable** * Un manifest sirve para cualquier cliente que entienda el spec. * No depende de un SDK concreto. * **Abierto** * Especificación pública ([artículo original](https://wiki.totto.org/blog/2026/03/13/the-autonomous-agentic-web-needs-a-foundation-layer/#what-needs-to-happen)). * Implementaciones de referencia bajo **Apache 2.0**. * Enviado a la **AI Alliance Foundation** como companion spec de MCP. * **Motivado por la práctica** * Nació del propio “rig” interno de desarrollo de Thor: más CLI tools, más agentes, más delegaciones. * El cuello de botella dejó de ser lo que los agentes podían hacer, y pasó a ser **cómo describirlo de forma consistente**. * * * ## **Implementaciones actuales (y cómo ya me estoy beneficiando)** Thor detalla varios elementos ya en marcha: * **kcp-commands** * 289 manifests para herramientas CLI comunes. * Cada manifest describe: * capacidades, * contexto típico, * comportamiento de delegación recomendado. * Se usan para construir contexto estructurado para agentes: * **menos tokens** para discovery, * contexto **más rico y fiable**. * **Tooling** * Validadores en **TypeScript** y **Java**. * Bridge en **Python**. * Servidor **MCP** que permite a cualquier agente con soporte MCP **consultar el índice de manifests**. * **Validación independiente** * Primer implementación externa: **kcp‑basis‑oppsett**, desarrollada en el sector público noruego, que llegó al mismo patrón de forma independiente. Además de lo que cuenta Thor, yo ya estoy aprovechando esta infraestructura en un proyecto concreto: * Estoy utilizando **Synthesis-Little-Brother**, un “hermano pequeño” del proyecto Synthesis de Thor, pensado para **explorar proyectos legados** y aplicar estos principios de contexto estructurado y capacidades declaradas: 👉 `https://github.com/Cantara/Synthesis-Little-Brother` Este tipo de herramientas muestran muy bien el valor de tener: * plantillas y estándares declarados, * manifests que describen capacidades, * y un agente que puede razonar sobre todo ello sin depender solo de texto suelto en un README. * * * ## **Cómo encaja en la pila de estándares agentic** Thor sitúa KCP dentro de una **pila de estándares complementarios**: * **llms.txt (Answer.AI)** * Resuelve el descubrimiento plano: ubicación estándar para documentación que los agentes pueden encontrar. * Es una **tabla de contenidos**. * **KCP** * Añade una capa de **declaración tipada de capacidades**: * qué existe, * qué hace, * qué restricciones y reglas de delegación tiene. * **MCP (Anthropic → AAIF/Linux Foundation)** * Define cómo **invocar** herramientas y servicios externos. * Es la capa de ejecución. * **Permission Manifests (LAS‑WG)** * Capa de gobernanza: cómo se declaran y aplican permisos a nivel de plataforma. * Diseñados para ser **complementarios** a KCP: * KCP → restricciones a nivel de **capacidad**, * Permission Manifests → restricciones a nivel de **plataforma**. La visión final: 1. **Descubrimiento**: llms.txt + KCP permiten saber **qué capacidades existen**. 2. **Declaración y contexto**: KCP define **qué hacen** y **bajo qué límites**. 3. **Ejecución**: MCP define **cómo llamarlas**. 4. **Gobernanza**: Permission Manifests definen **qué está permitido** en la plataforma. * * * ## **Estado actual (v0.8) y señales** Thor es honesto: **KCP está en fase temprana**. * Especificación en versión **v0.8**. * Enviada a la **AI Alliance Foundation** como estándar compañero de MCP. * Registro de URI “well‑known” en proceso con **IANA**. * 289 manifests publicados, tooling en varios lenguajes, integración con MCP, exploraciones con **NIST NCCoE**. No es un producto cerrado, es una **apuesta de infraestructura**. La tesis de fondo es fuerte: > Esta capa va a existir, de una forma u otra. > Sin ella, el agentic web se queda en un conjunto de piezas capaces pero aisladas. * * * ## **Qué tiene que pasar (y cómo podemos apoyar)** Thor cierra su artículo con un paralelismo histórico: * La web se volvió componible cuando suficientes desarrolladores decidieron que: * el coste de **acordar protocolos abiertos** era menor que * el coste de integrar cada cosa con cada cosa de forma ad‑hoc. Ese momento no fue obvio en su día. Hoy lo damos por hecho. El **agentic web está justo en ese punto**: * Podemos seguir montando soluciones propietarias y específicas para cada stack. * O podemos **empujar estándares abiertos** que: * hagan que las capacidades sean descubribles, * lleven sus restricciones consigo, * y permitan delegación segura entre agentes. **KCP es una de las propuestas más serias que he visto para esa capa.** Por eso escribo este resumen: para que más gente en nuestra comunidad la conozca y, si les resuena, se sumen a la conversación y a las implementaciones, igual que yo estoy haciendo con Synthesis-Little-Brother. * * * ## **Enlaces y cómo involucrarte** Si estás construyendo: * **sistemas multi‑agente**, * infraestructura para agentes, * o te preocupa cómo se van a componer capacidades entre organizaciones, te invito a: * Leer el artículo original de Thor (mucho más completo que este resumen): 👉 [The Autonomous Agentic Web Needs a Foundation Layer](https://wiki.totto.org/blog/2026/03/13/the-autonomous-agentic-web-needs-a-foundation-layer/#what-needs-to-happen) * Explorar los repos de KCP: * Especificación y referencias: `https://github.com/Cantara/knowledge-context-protocol` * Manifests de herramientas CLI (kcp‑commands, Apache 2.0): `https://github.com/Cantara/kcp-commands` * Ver cómo se está llevando esta visión a tooling concreto, por ejemplo: * **Synthesis-Little-Brother**, scaffolding KCP‑nativo para proyectos estándar y exploración de código legado: `https://github.com/Cantara/Synthesis-Little-Brother` Cuantas más voces técnicas participen ahora, mejor será la infraestructura que terminemos usando todos. > De nuevo: todo el mérito conceptual aquí es de **Thor Henning Hetland** y su equipo. > Yo solo estoy ayudando a que su propuesta llegue a más gente hispanohablante y compartiendo cómo ya me estoy apoyando en ella en mi propio trabajo.