Ya tienes una ontología

Circula un diagrama titulado “Technical Semantic Architecture for AI Agents”. Aquí está, redibujado:

Mi primera reacción fue la que sospecho que tiene casi todo el que construye agentes. He montado agentes que investigan, que rellenan formularios en navegadores reales, que revisan código, que clasifican riesgo de cumplimiento — y ninguno necesitó un knowledge graph. Un agente de código es un modelo más un sistema de ficheros, grep, una terminal y git. Un agente de soporte es un modelo más un almacén vectorial y dos APIs. El diagrama parecía sofisticación buscando un problema.

Lo sigo pensando en buena medida, pero lo estaba leyendo mal. El diagrama se presenta como una arquitectura que adoptas. Es mucho más útil como diagnóstico de algo que ya tienes — y para comprobarlo, hice la auditoría sobre mi propio código. El resultado fue peor de lo que esperaba, que es justo lo que lo hace digno de un artículo.

Las cuatro cajas, rápido

La distinción que sostiene todo el diagrama es ontología frente a knowledge graph: qué tipos de cosas pueden existir, frente a qué existe ahora mismo.

Si vienes de bases de datos, la correspondencia es casi exacta: la ontología es el esquema, los tipos de entidad son tablas, las propiedades son columnas, las relaciones son claves foráneas y el knowledge graph son las filas. En filosofía, la ontología pregunta qué categorías de cosas hay y cómo pueden relacionarse — la versión de software es la misma pregunta con las ambiciones rebajadas de la realidad a nuestro sistema.

Las dos cajas laterales son entradas. Una taxonomía no es más que una jerarquía is-a: BackendEngineer es un Engineer es un Employee. Clasificación, nada más. Una semantic layer es la idea que viene de analytics: la definición canónica y única de ARR, churn o cliente activo, para que el agente no se invente su propia aritmética.

Context graph es la caja que más me gusta, y la de pedigrí más débil — no es terminología estándar y no la vas a encontrar en un manual. Sigue siendo el nombre correcto para algo que todos hacemos sin nombrarlo. Tu knowledge graph puede tener diez millones de entidades; tu ventana de contexto tiene unos cientos de miles de tokens. Así que para cada decisión ensamblas una rebanada pequeña y específica de esa decisión — este cliente, su proyecto bloqueado, la revisión que lo frena, quién es dueño de esa revisión, el hecho de que está de vacaciones hasta el día 7. Ese subgrafo es lo que el modelo ve de verdad. Ponerle nombre lo convierte en algo que diseñas deliberadamente en lugar de en lo que salga de lo que tu recuperador haya devuelto esta vez.

Un dato de contexto que el diagrama no da: esta forma tiene procedencia. Es el discurso de ontología de Palantir cruzado con la semantic layer de analytics (dbt, Cube, AtScale). No es una crítica — es una pista sobre el cliente al que va dirigido. Esta es una arquitectura para organizaciones con muchos sistemas, muchos equipos y definiciones genuinamente en disputa. Leerla como “la arquitectura para agentes de IA” es un error de categoría que el título fomenta activamente.

La ontología que ya escribiste

Esta es la afirmación que quiero poner a prueba: no puedes decidir si tienes una ontología. Solo puedes decidir si vive en un sitio. En la mayoría de los sistemas ya está ahí, embadurnada por el esquema de la base de datos, los tipos de la API, los enums, los modelos del ORM, la documentación y los prompts. La propuesta real del diagrama no es “añade una capa”. Es “ya tienes una; consolídala”.

Para ver si eso aguanta fuera de una diapositiva, audité un proyecto mío: una herramienta de automatización de candidaturas, API en Python más un dashboard en Next.js. Es un proyecto personal, de un solo autor, sin comités y sin sistemas heredados — lo cual lo convierte en el caso más débil posible para el argumento, y por eso mismo es interesante.

Su entidad central es el blocker: aquello que impide que una candidatura se envíe automáticamente. Un CAPTCHA, un muro de login, un formulario de varios pasos. El producto entero existe para detectar blockers y pasárselos a un humano. Si algo está bien definido en ese código, debería ser esto.

Está definido en tres sitios — un enum de SQLAlchemy en el backend, un enum de TypeScript en el frontend y un Record de etiquetas dentro de un componente de React — y no coinciden:

El frontend cree en form_too_complex y unsupported_ats, que el backend no puede producir. El componente pinta custom_question y review_before_submit, que no existen en ningún enum de ninguna capa. Y file_upload sigue en el modelo de datos, debidamente migrado, mientras el detector que debería emitirlo no lo emite nunca.

Con el vocabulario de estados pasa lo mismo. ApplicationStatus tiene siete valores en Python y cinco en TypeScript. Los dos que faltan son cancelled y — este es el que escuece — needs_intervention, el estado cuyo propósito entero es decir aquí hace falta un humano. El backend lo emite en tres sitios distintos. El dashboard lo maneja como una cadena suelta dentro de un switch, porque su propio enum no lo tiene.

Nadie decidió no modelar el dominio. Se modeló cuatro veces, en cuatro días distintos, y derivó. Ese es el punto. Si un único desarrollador trabajando solo sobre un código pequeño produce cuatro definiciones incompatibles del concepto que da nombre al producto, entonces la ontología repartida no es un problema de escala organizativa que evitas siendo pequeño y disciplinado. Es estructural.

Por qué deriva, y por qué ningún compilador lo impide

El mecanismo es aburrido y conviene decirlo claro. Un concepto del dominio tiene que cruzar dos fronteras que ninguna herramienta vigila.

Cruza una frontera de lenguaje: Python a JSON a TypeScript. Los tipos se comprueban a cada lado de ese cable y en ningún punto a través de él. Un blocker_type con valor "location_mismatch" se deserializa en una variable tipada como JobBlockerType sin la menor queja, porque en tiempo de ejecución un enum de TypeScript no es más que una cadena. El valor es inválido; el sistema de tipos está mirando a otro lado.

Y cruza una frontera temporal. El enum del backend se amplió cuando el detector aprendió un modo de fallo nuevo. El enum del frontend se escribió antes y no tuvo motivo para cambiar — no se rompió nada. La deriva no se anuncia: la interfaz pinta calladamente una etiqueta gris de reserva y todo el mundo sigue con lo suyo.

Este es exactamente el problema que el mundo de analytics resolvió primero, y por eso la semantic layer llegó a ser una categoría de producto. El propio argumento de venta de dbt es que cinco personas pueden lanzar lo que creen que es el mismo informe y obtener cinco números distintos, porque cada equipo escribió un SQL diferente para “revenue”. El mismo fallo, un nivel de abstracción más arriba. Mis once valores de blocker son ese problema en miniatura — y yo tenía la ventaja de ser la única persona en la sala.

Con agentes, esto sube de precio

Aquí está el motivo por el que un problema viejo merece revisarse ahora.

Cuando una interfaz se encuentra un valor que no conoce, se degrada de forma visible. Una etiqueta gris, un icono que falta, una columna vacía. Un humano ve el hueco y da un rodeo.

Cuando un agente se encuentra un valor que no conoce, no se degrada: interpreta. Tiene que producir una decisión, así que echa mano del único modelo del mundo que tiene, la ontología implícita y probabilística que lleva en los pesos. Ha leído suficiente software como para tener opiniones sobre qué significa probablemente location_mismatch y cómo de grave es probablemente. Esas opiniones son plausibles, no quedan registradas, y no son las de tu empresa.

Ese es el argumento real para hacer explícita la ontología, y es más estrecho de lo que el diagrama sugiere. No es que un knowledge graph haga al modelo más listo. Es que mueve conocimiento desde “estadísticamente probable” hacia “definido por este sistema”, de modo que cuando el agente duda consulta algo con autoridad en vez de confabular algo razonable.

Las cuatro cajas se separan

Antes de preguntarte si necesitas la arquitectura, conviene notar que casi nunca la necesitas entera. El diagrama dibuja cuatro cajas como una sola pila, pero se adoptan de forma independiente, y la mayoría de los sistemas necesitan exactamente una. Coge los agentes que he construido:

• Un agente de código que pregunta ¿dónde se define esta función y quién la llama? Eso es un grafo — aristas de llamada, imports, definiciones. Pero grep, un servidor LSP y un runner de tests ya lo recorren, y el índice lo mantiene un tooling que nadie llama knowledge graph. Las relaciones son reales y la caja sobra, porque el recorrido ya viene con el lenguaje.
• Un agente de soporte que pregunta ¿cuál es la política de reembolso de este plan? La similitud de texto es exactamente la primitiva de recuperación correcta. Aquí no encadena nada. Este es el caso del almacén vectorial, y añadir un grafo sería estrictamente peor.
• Un clasificador de cumplimiento que pregunta ¿en qué categoría de riesgo cae este sistema? Aquí una caja sí se gana su sitio, y es la más pequeña: una taxonomía. El trabajo entero consiste en colocar una instancia dentro de una jerarquía de categorías con fronteras defendibles. No hace falta grafo de instancias — el valor está en que la clasificación sea explícita, versionada y la misma que lee el auditor.
• Un agente de informes que pregunta ¿cuánto ARR renovó este trimestre? La caja que importa es la semantic layer, y solo esa. El modo de fallo no es una relación que falta, son cuatro equipos con cuatro definiciones de ARR.

Así que “¿necesito esta arquitectura?” es la pregunta equivocada. La buena es cuál de estos cuatro modos de fallo tengo de verdad: clasificación inestable, definiciones en disputa, relaciones ilimitadas, o una ventana de contexto que no puede sostener la respuesta. Tienen arreglos distintos y precios distintos.

El criterio: la forma de la pregunta, no el tamaño de los datos

Para el knowledge graph en concreto, el test equivocado es el volumen. Hay muchos equipos con conjuntos de datos enormes que no necesitan más que Postgres y buenos tipos.

El test que yo usaría es la forma de tus consultas:

¿Qué facturas vencen esta semana? ¿Cuántos tickets abrió este cliente el mes pasado? ¿Qué cuentas del plan Pro llevan treinta días sin entrar? Cada una de esas es una tabla, un filtro y un par de joins que ya conoces cuando te sientas a escribir la consulta. Esa es la forma de la izquierda, y ahí una API tipada sobre una base de datos relacional gana en todos los ejes.

¿Por qué está bloqueado este cliente? ¿Qué se rompe si retiramos este endpoint? ¿Quién aprobó la versión que está ahora mismo en producción? Nadie puede decir de antemano cuántos saltos hacen falta: depende de la respuesta. Esa es la forma de la derecha: recorridos de profundidad desconocida sobre dependencias, propiedad, procedencia, causalidad o permisos. Es la única cosa que SQL hace genuinamente mal, porque cada join hay que escribirlo antes de saber cuántos vas a necesitar.

La señal práctica es justo esa: si no puedes escribir la consulta sin saber ya la respuesta, tu pregunta tiene forma de grafo. Cuenta cuántas de las preguntas que recibe tu agente de verdad fallan ese test. Si son un puñado entre cientos, tienes una herramienta de informes con un caso raro interesante, no un problema de grafos.

La evidencia respalda la lectura conservadora. GraphRAG-Bench, un benchmark de ICLR 2026 construido para responder exactamente a esta pregunta, arranca señalando que “GraphRAG frecuentemente rinde peor que el RAG convencional en muchas tareas del mundo real”, y se propone identificar las condiciones en las que el grafo gana de verdad — separando recuperación de hechos de razonamiento complejo y de resumen, porque se comportan distinto. El coste cuenta la misma historia: LazyGraphRAG, de la propia Microsoft, existe porque la indexación inicial de GraphRAG completo resultaba prohibitiva, y su resultado de titular es igualar la calidad al 0,1% del coste de indexación. Cuando el producto siguiente del fabricante es sobre todo una forma de no pagar el anterior, conviene captar la indirecta.

Aquí hay una escalera, y el diagrama salta directamente al último peldaño:

1. Una definición compartida del vocabulario de tu dominio, generada desde una única fuente en lugar de copiada a mano por lenguaje. Barato. Arregla lo que encontró mi auditoría.
2. Una API tipada sobre los datos relacionales, expuesta al agente como herramientas en vez de como SQL en crudo. Aquí es donde deberían parar la mayoría de los agentes.
3. Un grafo, cuando los recorridos son genuinamente ilimitados.

Casi todo el valor de ese diagrama está disponible en el primer peldaño. Saber cuándo no seguir subiendo es parte de la disciplina, igual que lo es saber cuándo no enrutar.

Lo que el diagrama esconde

Mira otra vez la primera figura: es todo cajas y flechas, y ninguna de esas flechas está etiquetada como y quién mantiene esto verdadero.

Modelar es la parte divertida. La parte que mata estos proyectos es poblar y mantener fresco: la ingesta, la resolución de entidades (¿es Acme Corp del CRM el mismo nodo que ACME S.L. del sistema de facturación?) y la pregunta de quién garantiza que Task 381 blocked_by SecurityReview siga siendo un hecho mañana. Un knowledge graph es una vista materializada y desnormalizada de media docena de sistemas, y las vistas materializadas se quedan rancias.

Rancio es peor que ausente, y peor de forma específica para los agentes. Cuando medí cómo manejan los agentes lo que ya ha ocurrido — 572 respuestas, seis modelos — el hallazgo fue que planifican alrededor de eventos que nunca sucedieron e inventan dependencias entre cosas que no dependen entre sí, y que darles la fecha no cambia nada. Un calendario le dice al modelo dónde está el ahora; no le dice nada sobre cuáles de sus hechos ya están fijados y qué relaciones siguen valiendo. Un knowledge graph le entrega al agente exactamente ese tipo de información: relaciones afirmadas en plano, en presente, sin indicación de cuándo fue verdad cada una por última vez. Cada arista está bien formada, cada tipo cuadra, el esquema valida, y el contenido lleva tres semanas por detrás de la realidad — y, a diferencia de un documento en crudo, el grafo es la fuente autorizada, así que el agente no tiene motivo para matizar.

La única intervención que sí ayudó en aquel experimento fue hacer la procedencia inseparable del valor, de modo que un hecho no pueda viajar sin su salvedad. Traducido a un grafo, eso es un requisito de diseño que el diagrama no menciona nunca: la frescura y el origen pertenecen a la arista, no a los logs de un trabajo de sincronización.

Por dónde empezaría de verdad

No por una base de datos de grafos. Por la auditoría.

Elige la entidad que da nombre a tu producto. Busca con grep todos los sitios donde se define su vocabulario: el enum, el tipo, el mapa de constantes, la cadena suelta dentro de un switch, la frase del prompt que le explica el dominio al modelo. Cuenta las definiciones. Cuenta los valores en los que coinciden.

Si sale una definición, tienes una ontología y está centralizada; el diagrama no tiene nada que venderte hasta que tus consultas adopten forma de grafo. Si salen cuatro, como me salieron a mí, entonces ya tienes una ontología — solo que repartida por el código en una forma que ninguna herramienta puede comprobar, y a punto de entregársela a algo que interpretará con total seguridad lo que no reconozca.

Esa es la lectura útil del diagrama. No una arquitectura que adoptar. Una pregunta que lanzar contra el código que ya tienes.

---

Relacionados: Lleva tu aplicación al agente, sobre exponer tu sistema a los agentes como herramientas, y Tu agente no sabe qué ha pasado ya, sobre por qué la fecha no arregla los hechos rancios.