Tu agente de IA no puede recordar un conocimiento que nunca tuvo

Un agente de soporte recibe un aviso: el conector CRM de Lumenara Logistics, una empresa ficticia, lleva dos horas sin sincronizar datos.

El agente busca en el conocimiento de la empresa y encuentra dos respuestas.

El runbook oficial indica que hay que reiniciar el conector. Sin embargo, en un hilo reciente de mensajería interna un ingeniero advierte que reiniciar conectores con sincronización incremental puede volver a procesar registros y crear duplicados.

Las dos fuentes son reales. Las dos son relevantes. Solo una puede representar la política vigente.

¿Qué debería hacer el agente?

Podría seguir el runbook y reiniciar el conector. Podría confiar en el hilo más reciente y no tocarlo. Podría buscar qué se hizo con otro cliente. O podría escoger la solución estadísticamente más habitual y ejecutarla antes de que alguien perciba la duda.

Ninguna de estas opciones resuelve el problema central: la empresa todavía no ha proporcionado al agente una respuesta suficientemente clara y autorizada para actuar.

No estamos ante un simple problema de context window. Tampoco es únicamente un problema de retrieval. Añadir memoria persistente podría incluso empeorarlo: el agente conservaría una conclusión cuya validez nunca llegó a comprobarse.

Este tipo de situación revela una confusión cada vez más frecuente en la arquitectura de agentes empresariales. Estamos utilizando palabras como memory, context, RAG, knowledge graph y Company Brain como si fueran distintas versiones de una misma cosa.

No lo son.

Una categoría, varias arquitecturas

“Company Brain” se ha convertido en una etiqueta extraordinariamente amplia.

A veces significa una memoria compartida que pueden consultar distintos agentes. Otras veces describe un buscador sobre documentos y conversaciones internas. También puede referirse a un grafo que conecta personas, proyectos y decisiones; a una wiki mantenida automáticamente; a una capa de contexto para agentes; o a un sistema capaz de convertir conocimiento en procedimientos ejecutables.

El problema no es que una de estas definiciones sea correcta y las demás estén equivocadas. El problema es que describen capas diferentes de un mismo sistema y, por tanto, resuelven problemas distintos.

Antes de discutir qué debería ser un Company Brain, conviene separar esas capas.

Contexto no es una sola cosa

Context window: lo que el modelo puede ver ahora

La context window contiene la información disponible para el modelo durante una inferencia concreta:

• └instrucciones
• └conversación reciente
• └archivos
• └resultados de herramientas
• └fragmentos recuperados
• └memorias seleccionadas
• └estado de la tarea

En nuestro ejemplo, podría contener algo parecido a esto:

Cliente: Lumenara Logistics
Conector: CRM Sync
Modo: incremental
Estado: sin sincronizar desde hace dos horas
Runbook: reiniciar el conector
Mensajería interna: un reinicio puede duplicar registros en modo incremental

El modelo puede razonar sobre esa información, pero la ventana no sabe cuál de las dos políticas tiene autoridad. Únicamente contiene la contradicción.

Una ventana mayor podría incluir más documentos, más mensajes y más histórico. Eso no garantiza que la información adecuada esté presente, que siga vigente o que sea suficiente para tomar una decisión.

La context window es el lugar donde termina llegando el contexto. No es el sistema que lo obtiene, mantiene o gobierna.

Agent memory: lo que el agente ha visto antes

La memoria permite que un agente conserve información entre interacciones y sesiones:

• └preferencias de un usuario
• └decisiones anteriores
• └resultados de herramientas
• └feedback recibido
• └estado de trabajos prolongados
• └intentos que funcionaron o fracasaron

La diferencia con retrieval es importante: RAG recupera conocimiento desde fuentes externas; la memoria mantiene continuidad a partir de la experiencia previa del agente.

Aplicada a nuestro caso, la memoria podría aportar algo como:

La última vez que un conector dejó de sincronizar,
reiniciarlo solucionó el problema.

Es información útil, pero no demuestra que el mismo procedimiento sea seguro ahora.

Tal vez aquel conector no utilizaba sincronización incremental. Tal vez no tenía escrituras pendientes. Tal vez el reinicio funcionó, pero también creó duplicados que se detectaron días después. Recordar que algo ocurrió no demuestra que deba repetirse.

Esta es la limitación fundamental: la memoria solo puede conservar aquello que el agente ha visto o que alguien ha decidido escribir en ella.

Un agente no puede recordar una decisión tomada en una reunión a la que nunca tuvo acceso. Tampoco puede recordar el criterio que una persona aplica intuitivamente si nadie llegó a expresarlo.

Enterprise search y RAG: lo que ya podemos encontrar

Enterprise search y RAG permiten recuperar información desde un corpus externo: documentos, tickets, repositorios, mensajes, transcripciones o bases de conocimiento.

En nuestro ejemplo, el sistema ha encontrado correctamente:

Runbook de conectores:
Si un conector deja de sincronizar,
reiniciar el proceso.

Hilo interno de Integraciones:
No reiniciar conectores en modo incremental sin revisar el cursor.
El proceso puede volver a ingerir registros y crear duplicados.

El retrieval ha hecho su trabajo. Ha localizado las fuentes relevantes.

Pero encontrar dos afirmaciones contradictorias no determina cuál debe gobernar la siguiente acción. La similitud semántica no sabe si una conversación reemplazó formalmente una política, si solo recogía una propuesta o si quien habló tenía autoridad para decidir.

RAG puede recuperar una decisión que alguien documentó. No puede recuperar una decisión que nunca llegó a producirse.

Una respuesta que nunca se documentó no es un fallo de retrieval. Es una carencia de conocimiento accesible.

Knowledge graph: cómo se relaciona lo que sabemos

Un knowledge graph puede representar entidades y relaciones explícitas:

Lumenara Logistics → utiliza → CRM Sync
CRM Sync → funciona en → modo incremental
runbook de conectores → recomienda → reinicio
reinicio incremental → puede provocar → registros duplicados
Nora → owner de → Connector Platform

Esto permite razonar mejor sobre personas, proyectos, clientes, decisiones y cambios temporales. También permite conservar señales como procedencia, vigencia y control de acceso.

Memoria, RAG y knowledge graphs no son tecnologías entre las que haya que escoger una ganadora. Son capas complementarias de un mismo context stack.

El grafo puede ayudarnos a descubrir que Nora es la responsable de Connector Platform y que el cliente utiliza sincronización incremental. Pero todavía no puede concluir si la advertencia del hilo se convirtió en procedimiento oficial o cuál es la alternativa segura al reinicio.

Cada capa ha aportado contexto valioso. Ninguna ha completado la respuesta.

El supuesto oculto del context stack

Context windows, memoria, retrieval y grafos parten normalmente de una suposición común:

El conocimiento que necesita el agente ya existe en algún lugar al que podemos acceder.

En las organizaciones, esta suposición falla continuamente.

Una parte importante del conocimiento real vive en:

• └decisiones verbales
• └excepciones negociadas caso por caso
• └razonamientos que nunca entraron en el documento final
• └criterios informales
• └relaciones de responsabilidad implícitas
• └experiencia acumulada por especialistas
• └cambios que aún no se han propagado
• └conversaciones privadas que no pueden convertirse sin más en conocimiento compartido

Conviene distinguir dos situaciones.

Missing information: la respuesta existe, pero todavía no la hemos recuperado.

Missing knowledge: la organización aún no ha producido una respuesta utilizable, autorizada o suficientemente explícita.

“¿Dónde está el runbook del conector?” es un problema de retrieval.

“El runbook ordena reiniciar, pero el hilo de Integraciones dice que puede duplicar datos. ¿Qué instrucción está vigente?” es un problema de resolución.

“No existe un procedimiento aprobado para recuperar un conector incremental bloqueado. ¿Quién puede decidir qué hacer?” es un problema de adquisición de conocimiento.

Seguir buscando puede funcionar en el primer caso. En los otros dos, probablemente necesitamos involucrar a la organización.

De recuperar contexto a resolverlo

Podemos llamar organizational context resolution al proceso de:

• └detectar que un agente no dispone de contexto suficiente
• └buscar el conocimiento existente
• └evaluar si las fuentes son actuales, suficientes y autorizadas
• └detectar contradicciones o preguntas abiertas
• └identificar a la persona que conoce la respuesta o tiene autoridad para decidirla
• └formular una pregunta con el contexto ya recopilado
• └capturar y verificar la respuesta
• └convertirla en conocimiento reutilizable cuando corresponda

El flujo deja de ser una simple consulta:

El agente intenta realizar una tarea
        ↓
Se detecta una carencia de contexto
        ↓
Se buscan fuentes existentes
        ↓
¿La evidencia es suficiente y autorizada?
        ├── Sí → entregar contexto
        └── No
             ↓
      Identificar al owner o experto
             ↓
      Formular una pregunta contextualizada
             ↓
      Capturar y verificar la respuesta
             ↓
      Hacerla reutilizable

Volvamos al conector bloqueado.

El sistema no debería enviar a Nora una pregunta genérica como “¿Qué hacemos con el conector?”. Ya ha encontrado parte de la respuesta. Puede preguntar:

El conector CRM de Lumenara Logistics lleva dos horas bloqueado y utiliza sincronización incremental. El runbook indica que debemos reiniciarlo, pero un hilo de Integraciones advierte que eso puede reingerir registros y crear duplicados. ¿Cuál es el procedimiento seguro en este caso?

La respuesta podría ser:

No reiniciéis el conector. Pausad la ingesta, ejecutad la reconciliación
y comprobad el último cursor confirmado. Si no hay diferencias,
reanudamos desde ese checkpoint. Si las hay, escaladlo antes de escribir.

Owner: Nora / Connector Platform
Aplicable a conectores con sincronización incremental
Fuentes: runbook + configuración del cliente + aclaración de Platform
Confianza: alta

El agente ya no recibe únicamente documentos relacionados. Recibe contexto resuelto.

Las personas son parte de la arquitectura de contexto

La narrativa habitual presenta la intervención humana como un fracaso de la automatización:

el agente falla → escalar a un humano

Pero dentro de una organización, una persona puede ser:

• └la única fuente disponible
• └la autoridad necesaria para validar una decisión
• └quien conoce las excepciones
• └quien puede resolver una contradicción
• └quien tiene permiso para crear una regla nueva

El humano no es solo el fallback del agente. Es una fuente de conocimiento y, en ocasiones, la única autoridad capaz de transformar una situación ambigua en una decisión organizacional.

La arquitectura real se parece más a esto:

agente
  ↓
sistema de contexto organizacional
  ↓
documentos · conversaciones · sistemas · personas

Preguntar bien también es una capacidad técnica. El sistema debe saber a quién acudir, qué información incluir, qué canal utilizar y cuándo la interrupción está justificada. Debe evitar que cada agente formule la misma pregunta y que los expertos se conviertan en una API humana saturada.

El objetivo no es eliminar a las personas del circuito. Es conseguir que cada intervención humana produzca conocimiento reutilizable en lugar de resolver únicamente una interacción efímera.

Una respuesta no debería convertirse silenciosamente en “verdad empresarial”

Supongamos que Nora responde en el canal interno. Guardar automáticamente “nunca reiniciar un conector incremental” en una memoria compartida también sería peligroso.

La respuesta necesita conservar más información:

• └fuente
• └owner
• └autoridad
• └alcance
• └fecha de entrada en vigor
• └confianza
• └estado de aprobación
• └política anterior a la que sustituye
• └permisos
• └restricciones de ejecución

También debemos distinguir entre evidencia, interpretación, decisión, excepción y procedimiento.

Si ingerimos todas las conversaciones indiscriminadamente, no obtenemos un Company Brain. Obtenemos una copia consultable de las contradicciones de la empresa.

Encontrar una solicitud antigua tampoco permite saber si el trabajo continúa pendiente. Para saberlo hay que relacionarla con la evidencia posterior de entrega, conservar el cambio de estado y no borrar la historia.

La gobernanza, por tanto, no es una capa de seguridad que se añade alrededor del conocimiento. Es parte del proceso que convierte información en conocimiento organizacional.

De una respuesta a una skill

Resolver una pregunta es útil. Conseguir que la organización no tenga que resolverla de nuevo es mejor.

La aclaración puede guardarse como una restricción operativa:

Un conector incremental bloqueado no debe reiniciarse
sin comprobar antes su cursor y reconciliar los registros pendientes.

Pero si la tarea se repite, puede convertirse en un procedimiento:

trigger:
  incremental_connector_stalled

conditions:
  - sync_mode == incremental

required_approval:
  - connector_owner_if_reconciliation_has_differences

steps:
  - pause_ingestion
  - read_last_confirmed_cursor
  - run_reconciliation
  - verify_no_duplicate_records
  - resume_from_confirmed_checkpoint

forbidden:
  - blind_restart

owner:
  connector_platform

Aquí pasamos de conocimiento declarativo —qué es cierto— a conocimiento procedimental —cómo debe actuar el agente—.

El trabajo sobre Knowledge Activation propone precisamente tratar las skills como unidades de conocimiento institucional preparadas para la acción, con procedimientos, herramientas, restricciones y metadatos de gobernanza.

Pero tampoco deberíamos convertir automáticamente cada respuesta en una skill. Una respuesta puede ser una excepción. Una skill necesita owner, condiciones explícitas, revisión, evidencia de funcionamiento, versionado y una forma de retirarla cuando deje de ser válida.

La progresión correcta sería:

conversación
→ respuesta verificada
→ conocimiento organizacional
→ procedimiento revisado
→ skill ejecutable

Un Company Brain es un sistema, no una base de datos

Después de separar estas capas, podemos recuperar el término Company Brain con una definición más precisa:

Un Company Brain es el sistema gobernado que adquiere, resuelve, mantiene y entrega contexto organizacional para que personas y agentes puedan actuar de forma consistente.

Puede utilizar:

• └context windows
• └agent memory
• └enterprise search
• └RAG
• └knowledge graphs
• └conectores
• └routing de expertos
• └aclaraciones humanas
• └procedencia y permisos
• └skills
• └feedback procedente de la ejecución

Pero ninguna de estas piezas aisladas es necesariamente el sistema completo.

La memoria recuerda. La búsqueda recupera. Los grafos conectan. Un Company Brain también debe reconocer cuándo la organización todavía no sabe algo con suficiente claridad como para actuar.

Construir para el contexto que aún falta

En Gurusup Brain estamos trabajando sobre una premisa sencilla: el contexto que le falta a un agente no siempre puede recuperarse; en ocasiones hay que adquirirlo.

El sistema busca primero en el conocimiento existente: conversaciones, correo, documentos y otras fuentes empresariales. Si encuentra información suficiente y autorizada, la entrega. Si detecta una contradicción o un vacío, identifica a la persona adecuada y solicita una aclaración mediante el canal disponible. La respuesta vuelve con fuente, fecha, owner y nivel de confianza, para que pueda ser utilizada por personas y agentes.

El objetivo no es almacenar todas las conversaciones de la empresa ni construir una memoria indiscriminada. Es cerrar el circuito que normalmente queda abierto:

carencia detectada
→ investigación
→ persona adecuada
→ respuesta verificada
→ contexto reutilizable
→ posible skill

Dar memoria a los agentes resuelve un problema importante: dejan de olvidar lo que ya han visto.

Conectarlos a enterprise search resuelve otro: pueden recuperar lo que la empresa ya ha documentado.

Pero las empresas no funcionan únicamente sobre interacciones recordadas y documentos indexados. Funcionan sobre decisiones, excepciones, responsabilidades y criterio humano. Gran parte de ese conocimiento nunca llegó a convertirse en una fuente que un agente pudiera consultar.

La siguiente capa de infraestructura empresarial no consistirá simplemente en almacenar más información. Tendrá que reconocer qué falta, encontrar quién o qué puede proporcionarlo y transformar la respuesta en conocimiento que el resto de la organización pueda reutilizar con seguridad.

La próxima vez que un agente no sepa algo, la pregunta no debería ser únicamente cuánto puede recordar o dónde puede buscar.

Debería ser:

¿Sabe nuestro sistema encontrar a quien sí lo sabe?

Fuentes

• └Knowledge Activation: AI Skills as the Institutional Knowledge Primitive
• └Gurusup Brain