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”)

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.

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).

  • 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

• 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.