# Jev vs KCP: no es un versus **En corto:** no elijas uno. Hacen trabajos distintos. **Jev** —o un modelo de decisión similar— puede tomar un input y producir una decisión estructurada: una categoría, un score, una probabilidad o una opción de un conjunto cerrado. **KCP** no clasifica ese texto. Su función está más cerca de declarar qué conocimiento, habilidades, procedimientos y reglas son válidos, cuáles están vigentes y bajo qué condiciones pueden utilizarse. Y hay una tercera pieza que no conviene olvidar: > **Una decisión no es lo mismo que una autorización, y una confianza no es lo mismo que una evidencia.** Si los ponemos al mismo nivel, parece que la IA aprueba un crédito o una póliza. No necesariamente. Primero están las reglas y el contexto autorizado. Después puede venir una decisión estructurada. Luego una política puede determinar qué hacer con ella. Y finalmente debe quedar evidencia de lo ocurrido. **Un** `0.82` **no es una firma.** Jev: [https://jevai.net/es/](https://jevai.net/es/) KCP: [https://github.com/Cantara/knowledge-context-protocol](https://github.com/Cantara/knowledge-context-protocol) ## 1\. Cuatro preguntas, no cuatro productos que se pelean Cuando hablamos de AI Agents aparecen cada vez más siglas: LLM, RAG, MCP, KCP, A2A, Skills, Playbooks, Jev... Es fácil pensar: > ¿Cuál reemplaza a cuál? Creo que es una pregunta equivocada. Es mejor preguntar: > **¿Qué problema resuelve cada pieza?** | Pieza | En cristiano | En una clínica | | --- | --- | --- | | LLM | ¿Cómo razono o genero una respuesta? | La médica piensa y explica | | RAG | ¿Qué documentos parecen relevantes? | Revisar el archivo | | KCP | ¿Qué conocimiento manda, está vigente y puedo utilizar? | El protocolo de este año, no el de 2024 | | MCP | ¿A qué sistemas y herramientas puedo acceder? | Historia clínica, laboratorio, kardex | | A2A | ¿Se lo paso a otro agente? | Interconsulta a farmacia | | Skills / Playbooks | ¿Cómo se ejecuta este procedimiento? | La guía para tratar un caso específico | | Jev / modelo de decisión | Dado este input permitido, ¿qué decisión estructurada corresponde? | ¿Farmacia, calidad o revisión humana? | Una forma todavía más sencilla: ```plaintext MCP → ¿A qué puedo acceder? KCP → ¿Qué conocimiento/regla es válido? Skills → ¿Qué sé hacer? Playbooks → ¿Cómo se ejecuta un procedimiento? A2A → ¿Con qué otro agente colaboro? Jev → ¿Qué decisión estructurada corresponde? Audit → ¿Qué ocurrió y puedo demostrarlo? ``` No son necesariamente competidores. Son piezas diferentes de una arquitectura de agentes. ## 2\. El dibujo fácil — y por qué puede engañar Cuando alguien pide: > "Dibújame el stack de Agentic AI" es tentador hacer esto: ```plaintext AGENT │ ┌───────────┼───────────┐ │ │ │ KCP MCP A2A │ │ │ └───────────┼───────────┘ │ Jev │ ACTION ``` Se ve bonito. Pero tiene un problema: **parece que Jev está debajo de KCP, MCP y A2A como si fuera otra capa del mismo tipo.** No necesariamente. Una arquitectura más útil conceptualmente sería: ```plaintext AGENT │ ┌─────────────┼─────────────┐ │ │ │ KCP MCP A2A │ │ │ conocimiento tools agentes y gobierno y datos externos │ ▼ contexto autorizado │ ▼ MODELO DE DECISIÓN Jev / LLM / otro │ ▼ decisión estructurada choice + score + etc. │ ▼ POLICY / GATE │ ┌────┴────┐ ▼ ▼ ACTION HUMAN │ ▼ AUDIT │ ▼ EVIDENCE ``` La idea importante es: > **El modelo puede proponer una decisión. La política determina qué se puede hacer con esa decisión.** ## 3\. ¿Qué es cada uno, sin folleto? ## MCP — ¿a qué puedo entrar? MCP es la capa de conexión con herramientas y recursos. Por ejemplo: ```plaintext Agent │ ├── MCP → PostgreSQL ├── MCP → GitHub ├── MCP → SAP ├── MCP → REST API └── MCP → filesystem ``` Pregunta: > **¿Qué herramientas y recursos tengo disponibles?** Yo lo veo como el **enchufe**. ## KCP — ¿qué conocimiento manda? KCP entra en otro problema. Supongamos que RAG encuentra: ```plaintext Política de crédito 2024 Política de crédito 2025 Política de crédito 2026 ``` Encontrar documentos no significa saber cuál tiene autoridad. KCP introduce una capa para declarar conocimiento y contexto gobernado: ```plaintext Documento │ ├── versión ├── vigencia ├── alcance ├── audiencia ├── autoridad └── relación con otros documentos ``` Y el ecosistema ha ido más allá del documento: ```plaintext Knowledge ↓ Skills ↓ Playbooks ``` Por eso no lo describiría simplemente como "un inventario de documentos". Es más preciso decir: > **KCP es una capa de conocimiento y gobernanza para declarar qué conocimiento, capacidades y procedimientos están disponibles y bajo qué condiciones.** ## A2A — ¿se lo paso a otro agente? A2A responde otra pregunta: > **¿Cómo colaboro con otro agente?** Por ejemplo: ```plaintext Customer Agent │ ├──→ Credit Agent │ ├──→ Fraud Agent │ └──→ Shipping Agent ``` MCP: ```plaintext Agent ↔ Tool ``` A2A: ```plaintext Agent ↔ Agent ``` Son complementarios. ## Skills y Playbooks — ¿cómo hago el trabajo? Una cosa es saber que puedes acceder a una herramienta. Otra es saber cómo utilizarla correctamente. Por ejemplo: Skill: "Analizar una solicitud de crédito" Playbook: 1. Obtener datos 2. Validar identidad 3. Consultar política vigente 4. Evaluar riesgo 5. Solicitar revisión si corresponde 6. Registrar evidencia Aquí empieza a aparecer una arquitectura mucho más interesante que simplemente: "Tengo un chatbot conectado a una API." ## Jev — ¿qué decisión estructurada corresponde? Aquí está la diferencia fundamental. Un LLM tradicional puede responder: > "Creo que este caso debería ser revisado por el área de fraude porque..." Un modelo de decisión puede producir algo más cercano a: ```plaintext { "decision": "fraud-review", "confidence": 0.82 } ``` O: ```plaintext { "category": "A", "score": 82, "probability": 0.91 } ``` La idea de Jev es precisamente llevar el modelo hacia **decisiones tipadas/probabilísticas en lugar de generación abierta**. Eso puede ser muy útil cuando el espacio de respuestas está controlado. Pero aquí aparece una distinción fundamental. ## 4\. "0% de alucinaciones" no significa "0% de errores" Este punto merece mucha atención. Una salida estructurada puede garantizar que el modelo solamente devuelva: ```plaintext APPROVE REFUSE ESCALATE ``` Eso evita que el modelo invente una cuarta opción: ```plaintext MAYBE-PERHAPS-APPROVE ``` Pero no significa que: ```plaintext APPROVE ``` sea necesariamente la decisión correcta. El propio análisis de Thor sobre Jev señala precisamente esta diferencia: la afirmación de "0% hallucination" se refiere a la garantía del esquema de salida, no a una garantía empírica de corrección. Dicho de otra manera: ```plaintext Schema correctness ≠ Decision correctness ``` Si las únicas opciones son: ```plaintext APPROVE REFUSE ``` el modelo siempre devolverá una de ellas. Pero todavía puede equivocarse. ## 5\. Y aquí aparece una palabra importante: calibración Supongamos que el modelo responde: ```plaintext decision = APPROVE confidence = 0.82 ``` La pregunta importante es: > **¿Ese 0.82 significa realmente algo?** ¿Significa que acertará aproximadamente el 82% de las veces? ¿O simplemente es un número que el modelo produce con mucha seguridad? Para responderlo necesitamos datos. Por ejemplo: ```plaintext Confidence Resultado real 0.50 – 0.59 58% correctas 0.60 – 0.69 67% correctas 0.70 – 0.79 75% correctas 0.80 – 0.89 84% correctas 0.90 – 0.99 92% correctas ``` Entonces podríamos empezar a hablar de una confianza calibrada. Pero si todas nuestras decisiones son: ```plaintext 0.85 0.87 0.91 0.89 0.90 0.88 ``` y nunca tenemos suficientes casos con otros niveles de confianza, **no podemos saber realmente si el número está calibrado**. Eso es exactamente una de las cosas interesantes que descubrió Thor al auditar su propio sistema. Su gateway llevaba meses produciendo decisiones tipadas, `confidence` y referencias a reglas. Pero cuando intentaron comprobar si el `confidence` realmente predecía la corrección, descubrieron que sus propios datos todavía no permitían responderlo. Y esa es una lección que me parece mucho más importante que cualquier benchmark: > **Un número de confianza necesita evidencia.** ## 6\. Un `0.82` no es una firma Esta frase merece su propia sección. Podemos tener: ```plaintext decision = APPROVE confidence = 0.82 ``` Incluso podemos firmarlo criptográficamente. Eso nos permite demostrar: > "El sistema produjo esta decisión con este valor." Pero no demuestra: > "La decisión era correcta." Son cosas diferentes. ```plaintext Firma │ ▼ Prueba de lo que ocurrió Calibración │ ▼ Evidencia sobre qué tan confiable es el número Política │ ▼ Qué podemos hacer con esa decisión ``` Por eso una arquitectura de agentes empresarial necesita algo más que modelos. Necesita **gobernanza y evidencia**. ## 7\. El caso de Ana López Imaginemos que tenemos una clínica. Ana López está hospitalizada y llega este texto: > "Paciente presenta potasio elevado y está tomando medicación X." Nuestro sistema podría tener: ### RAG Encuentra: ```plaintext Protocolo 2024 Protocolo 2025 Protocolo 2026 ``` ### KCP Determina: ```plaintext Protocolo 2026 vigente aplicable a este tipo de caso ``` ### MCP Permite consultar: ```plaintext Historia clínica Laboratorio Medicamentos ``` ### Skill / Playbook Define: ```plaintext Analizar hiperpotasemia ``` ### A2A Puede delegar: ```plaintext Medical Agent │ └──→ Pharmacy Agent ``` ### Modelo de decisión Recibe el contexto autorizado: ```plaintext decision = "pharmacy-review" confidence = 0.82 ``` Pero todavía falta una pregunta: > **¿Qué hacemos con ese 0.82?** La política podría decir: ```plaintext if confidence < 0.75 → human review if medication == high-risk → human review if policy requires physician → human review ``` Entonces: ```plaintext KCP │ ▼ contexto autorizado │ ▼ modelo de decisión │ ▼ pharmacy-review 0.82 │ ▼ POLICY │ ▼ HUMAN REVIEW │ ▼ AUDIT ``` Ahora sí tenemos una arquitectura defendible. ## 8\. Lo más interesante: la auditoría también puede equivocarse Y aquí el artículo de Thor tiene una segunda lección todavía más interesante. Al auditar sus decisiones, inicialmente encontraron: ```plaintext 21 decisiones escaladas 21 aparentemente pendientes ``` Parecía un problema importante. Pero el script de auditoría estaba utilizando mal un identificador de correlación. Al corregir la relación entre eventos, el resultado cambió. Y posteriormente encontraron otro problema: algunas de las decisiones que parecían pendientes pertenecían a ejecuciones que ya habían terminado o sido abortadas. La conclusión es brutalmente sencilla: > **Un sistema de auditoría también necesita ser auditado.** Podemos tener: ```plaintext Agent ↓ Decision ↓ Audit ``` y aun así equivocarnos. Por eso no basta con: > "Tengo logs." Hay que poder responder: * ¿Qué versión de la política estaba vigente? * ¿Qué conocimiento se utilizó? * ¿Qué modelo produjo la decisión? * ¿Qué input recibió? * ¿Qué decisión propuso? * ¿Qué confidence produjo? * ¿Qué regla la justificó? * ¿Quién autorizó la acción? * ¿Qué ocurrió después? * ¿Podemos reconstruir el proceso? Eso es **evidence**. ## 9\. Entonces, ¿Jev reemplaza a KCP? No. Pero tampoco diría simplemente: > "KCP y Jev son complementarios." Eso es demasiado superficial. La relación más interesante es: ```plaintext KNOWLEDGE │ KCP │ ▼ CONTEXTO AUTORIZADO │ ▼ DECISION MODEL Jev / LLM / otro │ ▼ DECISIÓN PROPUESTA │ ▼ POLICY / GATE │ ┌──────┴──────┐ ▼ ▼ ACTION HUMAN │ ▼ AUDIT │ ▼ EVIDENCE ``` Por eso el título sigue siendo: # **Jev vs KCP: no es un versus** Pero ahora agregaría: > **En realidad, tampoco es solamente Jev + KCP. Hay una tercera dimensión: gobernar y demostrar qué ocurrió.** # 10\. Si tu equipo programa — Java u otra cosa Todo esto no depende de Java. Pero para un equipo Java podría verse perfectamente así: ```plaintext Spring AI / LangChain4j / Quarkus │ ▼ AI Agent │ ┌──────┼──────┐ │ │ │ KCP MCP A2A │ │ │ │ │ └── Agent B │ │ │ └──────── APIs / DB / Tools │ └────────────── Knowledge / Policies │ ▼ Decision Model │ ▼ Structured Output │ ▼ Policy Gate │ ┌───┴───┐ ▼ ▼ Action Human │ ▼ Audit Trail ``` Y aquí está la parte que más me interesa como arquitecto: **no estamos construyendo simplemente un chatbot.** Estamos construyendo un sistema donde: ```plaintext Knowledge + Tools + Agents + Decision + Governance + Evidence ``` forman una unidad. # 11\. Cómo lo contaría en diez minutos Si tuviera que explicar todo esto rápidamente, usaría solamente estas preguntas: ### 1\. ¿Qué puedo usar? **MCP** ```plaintext Agent → Tools / Data ``` ### 2\. ¿Qué conocimiento es válido? **KCP** ```plaintext Agent → Governed Knowledge ``` ### 3\. ¿Cómo hago el trabajo? **Skills / Playbooks** ```plaintext Agent → Procedure ``` ### 4\. ¿Con qué otro agente colaboro? **A2A** ```plaintext Agent ↔ Agent ``` ### 5\. ¿Qué decisión corresponde? **Jev / modelo de decisión** ```plaintext Input → Decision + Score ``` ### 6\. ¿Qué puedo hacer con esa decisión? **Policy / Governance** ```plaintext Decision → Action / Human ``` ### 7\. ¿Cómo demuestro lo que pasó? **Audit / Evidence** ```plaintext Action → Trace → Evidence ``` Y ahí aparece una arquitectura mucho más completa: ![](https://cdn.hashnode.com/uploads/covers/64a79aba336591d2a1481aae/b223755a-eead-4c07-bd5b-ac2f8ff819c7.png align="center") # Cierre Mi conclusión después de mirar Jev y KCP es que la pregunta: > **"¿Jev o KCP?"** no es la pregunta que deberíamos hacernos. La pregunta interesante es: > **"¿Qué necesita un agente para conocer, decidir, actuar y poder defender después lo que hizo?"** Ahí cada pieza tiene un papel diferente. **MCP** conecta al agente con herramientas y datos. **KCP** ayuda a gobernar el conocimiento, las capacidades y los procedimientos que puede utilizar. **Skills y Playbooks** describen cómo realizar determinados trabajos. **A2A** permite colaborar con otros agentes. **Jev**, o cualquier modelo de decisión estructurada, puede ayudar a convertir un input en una decisión tipada, un score o una probabilidad. Pero hay una advertencia importante: > **Un** `confidence: 0.82` **no demuestra que la decisión sea correcta.** Para eso necesitamos datos, calibración y evidencia. Y tampoco basta con tener un audit log. El propio proceso de auditoría puede equivocarse. Por eso, para mí, la arquitectura de agentes empresariales empieza a verse así: ```plaintext KNOWLEDGE ↓ GOVERNANCE ↓ DECISION ↓ ACTION ↓ EVIDENCE ``` O, en una frase: > **KCP ayuda a establecer qué vale y qué está permitido. Un modelo como Jev puede proponer qué decisión corresponde. La política determina qué puede ocurrir después. Y la evidencia permite demostrar qué ocurrió realmente.** **No es un versus. Es un sistema.** ### **Referencias** * Thor Henning Hetland — [***We Already Run Jev. We Just Never Checked***](https://wiki.totto.org/blog/2026/09/18/we-already-run-jev-we-just-never-checked/)*.* * JoeDayz — [***Jev vs KCP: no es un versus***](https://blog.joedayz.pe/jev-vs-kcp-no-es-un-versus) * KCP — [**Knowledge Context Protocol**](https://github.com/Cantara/knowledge-context-protocol) * Jev AI — [**TypeSafe AI**](https://jevai.net/es/) Enjoy! Joe