Por qué Glean y los context graphs por fin me hicieron entender la IA empresarial

Hace unos meses, un director me pidió automatizar cómo respondemos a las solicitudes de descuento de flotillas. Una petición simple. Excepto que el “proceso” vivía en cinco lugares distintos: una cadena de correos con el gerente de cuentas de flotillas, un hilo de Slack donde un amigo mío en finanzas compartía preocupaciones de margen, una hoja de cálculo con las aprobaciones del trimestre pasado, una nota en el CRM sobre el riesgo de churn del cliente, y la memoria de alguien sobre lo que hicimos con una cuenta similar el año anterior.

¿Hacia dónde apunto siquiera un agente con eso?

Me senté con la solicitud un buen rato. Mapeé las fuentes de datos. Bosquejé árboles de decisión. Y seguía chocando con el mismo muro: no había un solo lugar donde viviera la lógica. El “proceso” no estaba documentado; estaba distribuido entre personas, herramientas y memoria institucional.

Los datos existían. Lo que faltaba era el contexto, y yo no sabía cómo construirlo.

Para lo que mi experiencia en IA no me preparó

He tenido la oportunidad de trabajar de cerca con sistemas de IA durante un par de años — construyendo pipelines de datos, modelos de ML, sistemas RAG que sí llegaron a producción — pero la mayor parte de ese trabajo era contenido. Construye un sistema de recuperación sobre estos documentos. Entrena un modelo con este dataset. Crea un pipeline de ingestión de esta fuente a ese destino.

Los flujos de trabajo entre sistemas son otra cosa. La pregunta del descuento de flotillas no la responde un solo sistema: requiere jalar datos de margen de finanzas, señales de churn de customer success, precedente histórico de una conversación con el director de flotillas anterior… y luego sintetizar todo eso en una recomendación que corresponda a cómo la organización realmente toma estas decisiones.

Intenté coser automatizaciones, scripts a la medida, cadenas de prompts con lógica de relevos. Algunas funcionaron para tareas estrechas, pero ninguna escaló a cómo se mueve el trabajo a través de una organización.

Perdí más tiempo del que me gustaría admitir en enfoques que se sentían ingeniosos pero no aguantaban el desorden del trabajo empresarial real.

El momento en que hizo clic

A finales de diciembre me encontré un artículo en X de Jaya Gupta que traía una cantidad extraña de guardados y estaba haciendo mucho (buen) ruido. El título — llamar a los context graphs “la oportunidad del billón de dólares de la IA” — me llamó la atención, y algo se movió.

La tesis de Jaya era simple: la última generación de software empresarial se volvió valiosa por ser sistemas de registro. Salesforce es dueño de los datos de clientes. Workday, de los datos de empleados. SAP, de las operaciones. Estos sistemas son excelentes capturando lo que existe: el estado actual del negocio.

Pero no capturan por qué, ni siquiera cómo, se tomaron las decisiones. La excepción que se aprobó. La regla de negocio que la justificó. El contexto interfuncional que la informó. Ese razonamiento vive en hilos de Slack, cadenas de correo, conversaciones de juntas y, por supuesto, en la cabeza de la gente. Nunca se ha tratado como datos.

Un context graph captura esa capa: las trazas de decisión, las excepciones, los patrones de cómo se hace el trabajo. Hace que el precedente sea buscable. Le da a los agentes el playbook que los humanos cargan en la cabeza.

Leí eso y pensé: esto es exactamente con lo que he estado batallando. Por fin tenía nombre.

Qué es un context graph

Un context graph es un modelo que conecta las entidades de tu empresa — personas, documentos, tickets, sistemas — con las acciones y eventos que ocurren entre ellas. Captura no solo lo que existe, sino cómo fluye el trabajo: quién hizo qué, en qué orden y con qué resultado.

Sigo con el ejemplo de antes.

Para responder si deberíamos aprobar un descuento de flotillas, necesito datos de margen de finanzas y la bandera de riesgo de churn de customer success. Viven en sistemas distintos, propiedad de equipos distintos, sin lógica compartida que los conecte.

Un sistema tradicional puede decirme: “Este cliente tiene un score de riesgo de churn del 15%”. No puede decirme: “Las últimas tres veces que vimos este perfil de riesgo aprobamos un descuento del 8%, y este es el razonamiento que lo justificó.”

Esa es la diferencia entre una base de datos y un playbook. Un agente no necesita saber “hay una solicitud de descuento”. Necesita saber: “Cuando llegan solicitudes como esta, estos son los pasos que típicamente llevan a la resolución, aquí es donde se desvían, y este es el porqué.”

Cuando conviertes las acciones en entidades de primera clase, con timestamps y relaciones causales, ya no estás describiendo lo que existe. Estás describiendo cómo ocurre el cambio. Y eso es exactamente lo que un agente necesita para operar con autonomía.

El trabajo real es complejo

La gente cambia de contexto constantemente. Reutiliza el mismo documento en varios esfuerzos. Empieza un documento, lo abandona, y lo retoma tres días después. Un solo evento de “editar documento” puede pertenecer a varios flujos de trabajo paralelos.

El proceso para manejar un descuento de flotillas no está escrito en ninguna parte. Existe como reconocimiento de patrones en la cabeza de quienes ya lo han hecho. Cuando alguien nuevo llega, aprende viendo, preguntando y equivocándose.

Conocimiento tribal, le dicen. Pero esa es solo una forma educada de decir: el contexto más importante de tu organización no está capturado en ningún lugar al que un sistema pueda acceder.

Y esta es la brecha que mantiene a la IA empresarial atorada en modo piloto. Los agentes se ven muy bien en demos con tareas limpias y acotadas. Sufren en producción, porque producción significa ambigüedad, excepciones y contexto que vive fuera de cualquier sistema individual.

Encontrar Glean

Mi primera reacción honesta ante Glean fue escepticismo.

He visto muchas “plataformas de IA empresarial” que prometen todo y entregan un chatbot con una interfaz bonita y, a veces, un LLM afinado. Asumí que esto era más de lo mismo.

Empecé a usarlo. La interfaz era buena. Los conectores eran impresionantes. Realmente jalaba de los sistemas donde ocurre el trabajo (y con datos desordenados), no solo de los sistemas donde el trabajo se documenta. Pero no entendía qué había debajo del cofre.

Entonces Arvind Jain, el CEO de Glean, publicó una respuesta al artículo de Jaya respaldando los context graphs. Y unas semanas después, un desglose técnico más profundo de cómo los construyen. No esperaba aprender tanto de su arquitectura (y su visión), pero lo explicó con detalle.

Arvind hizo una distinción que me parece crítica: no puedes capturar de forma confiable el “porqué” detrás de las decisiones. El “porqué” es un paso de pensamiento que vive en la cabeza de alguien (como en el ejemplo que compartí antes). A veces se insinúa en una junta de Teams o en un mensaje de Slack, pero la mayor parte nunca se escribe.

Lo que sí puedes capturar es el “cómo”. La secuencia de acciones. Las herramientas usadas. El orden de los eventos. Los patrones que se repiten entre personas y situaciones.

A lo largo de muchos ciclos, el “cómo” aproxima el “porqué”. Puedes inferir razones a partir de los patrones de cómo se hace el trabajo repetidamente, no intentando almacenar cada pensamiento humano sino observando el comportamiento a escala.

Varias cosas me llamaron la atención del desglose técnico de Arvind:

Cuatro capas, cada una apoyada en la de abajo

Primero, conectores profundos que capturan no solo documentos, sino eventos de cambio: quién editó qué, cuándo, en qué secuencia. Segundo, un knowledge graph que resuelve entidades entre sistemas (para que “Dunder Mifflin Inc” en tu CRM y “Dunder Mifflin” en los tickets de soporte sean el mismo cliente). Tercero, un grafo personal que rastrea patrones de trabajo individuales: tus tareas, tus proyectos, cómo te mueves entre herramientas. Cuarto, el context graph en sí, que agrega patrones anonimizados en playbooks de proceso. Cada capa depende de la de abajo. Sáltate una capa, y todo se rompe.

El sistema aprende el flujo observando

Esto fue lo que más me sorprendió. Glean no define “este es el proceso para manejar X”. En su lugar, observan patrones, asignan probabilidades a distintos caminos, y dejan que los agentes elijan el más probable para la situación. Cuando un agente corre, sus acciones se vuelven datos nuevos para el grafo. Las corridas exitosas refuerzan patrones. Las que fallan o necesitan intervención señalan huecos. Cada ejecución de un agente se vuelve retroalimentación que mejora la siguiente. Eso es un sistema que aprende.

El modelo de privacidad, y mi duda al respecto

Para construir modelos de proceso útiles necesitas agregar comportamiento entre personas. Jain describe su enfoque. Las trazas se abstraen en pasos anonimizados: tipo de acción, familia de herramienta, tiempos, resultados. Sin texto crudo, sin identificadores de usuario, sin contenido específico de clientes. Los patrones solo cuentan si aparecen en múltiples usuarios distintos. Suena correcto en principio. Pero no sé cómo se sostiene en la práctica: ¿qué tan anónimo es lo “anonimizado” cuando hablamos de equipos pequeños o flujos de trabajo únicos? Los empleados no van a adoptar herramientas que se sientan como vigilancia. Si el modelo de privacidad de Glean funciona como lo describen, es un diferenciador. Si no, es un problema de privacidad.

Qué significa esto

No sé si Glean se convierte en la empresa del billón de dólares que sugiere el artículo de Jaya Gupta.

Pero la dirección tiene sentido. Más que eso: es la primera arquitectura que he visto que realmente corresponde a cómo operan las empresas y las organizaciones grandes (muy grandes).

Las compañías pasaron décadas registrando y digitalizando transacciones. Construimos sistemas de registro para cada objeto del negocio: clientes, pedidos, empleados, tickets. Pero nunca capturamos el razonamiento que los conecta. El “cómo decidimos esto” y el “por qué hicimos una excepción” se quedaron en la cabeza de la gente, o enterrados en herramientas de comunicación que nunca se pensaron para consultarse.

Los context graphs son un intento de capturar esa capa. De hacer legible para la IA el “cómo” del trabajo, para que los agentes puedan hacer más que recuperar información: puedan participar en los procesos.

No creo que esto esté resuelto todavía. Construir estos sistemas es difícil. Mantenerlos precisos mientras las organizaciones cambian es más difícil. Pero para alguien que ha pasado años intentando automatizar trabajo que se niega a caber en cajitas limpias y brillantes, es el primer enfoque que he visto que no exige fingir que las empresas son más simples de lo que son.

Las compañías que lleguen temprano tendrán una ventaja construida sobre mejor contexto, no sobre mejores modelos de frontera. No creo que Glean ya lo tenga resuelto, pero están trabajando en el problema correcto: la mayoría de la IA empresarial sigue intentando hacer chatbots más listos, y esto intenta hacer a las organizaciones legibles para las máquinas. Ese es el problema en el que quiero trabajar.

---

Referencias

• “AI’s Trillion-Dollar Opportunity: Context Graphs” — Jaya Gupta & Ashu Garg, Foundation Capital (diciembre de 2025) — hilo en X
• “Context is the Next Data Platform” — Arvind Jain, Glean (enero de 2026) — glean.com/blog/context-data-platform
• “How Do You Build a Context Graph?” — Arvind Jain, Glean (febrero de 2026) — hilo en X

Publicado originalmente en LinkedIn (en inglés), febrero de 2026.