Una arquitectura contra la acumulación de alucinaciones en grafos de agentes.

La solución instintiva es añadir otro agente crítico. Eso es exactamente cómo se amplía el engaño en lugar de corregirlo.

Si alguna vez ha puesto en producción un chatbot RAG con un solo agente, ya reconoce el fallo: el modelo responde algo que los documentos recuperados nunca dijeron, y presenta esa fabricación con el mismo tono de certeza que utiliza cuando la cita es genuina.

En una tubería de múltiples agentes, este mismo fallo se amplifica, porque ya no se trata de la salida de un solo modelo, sino de todo un grafo de ellos. Un planificador idea un subobjetivo. Un investigador inventa una fuente para respaldarlo. Un analista obtiene un número de esa fuente inventada. Un escritor convierte ese número en una recomendación. Luego, un agente que llama a herramientas ejecuta esa recomendación contra su sistema de facturación. En cada transferencia, existe la posibilidad de que una suposición se presente como si fuera un hecho verificado.

Los equipos que desarrollan sistemas multiagente al estilo LangGraph para casos de uso en áreas legales, financieras y operativas se enfrentan a un patrón recurrente. El problema no radica en que el modelo subyacente sea poco inteligente, sino en que el flujo de trabajo en sí no cuenta con un contrato epistémico. Nada en el grafo obliga a ningún agente a revelar de dónde proviene una reclamación, qué pruebas podrían refutarla o qué debería suceder si simplemente no existen esas pruebas. Por lo tanto, el sistema hace lo que siempre hacen los modelos de lenguaje cuando hay una laguna: genera algo plausible para llenarla.

A continuación se presenta la arquitectura que merece ser utilizada cuando la salida puede mover dinero, afectar un trámite legal o llegar a la bandeja de entrada de un cliente. No se trata de un tutorial rápido, y si esperas encontrar una única instalación que haga que tus agentes sean fiables, no la encontrarás aquí.

El problema compuesto para el que nadie hace presupuestos

Cada llamada individual a un LLM presenta una tasa base de afirmaciones no respaldadas; llámemosla p. Si se conectan cinco etapas de agentes, y cada una de ellas puede introducir o amplificar afirmaciones no respaldadas, la tasa efectiva de errores ya no es p. Se convierte en el producto de probabilidades condicionales, a lo que se suma un segundo problema propio de los grafos multiagente: la transferencia de autoridad entre agentes.

El Agente B trata los resultados del Agente A como hechos establecidos simplemente porque llegan en forma de un objeto JSON estructurado etiquetado como research_findings. El esquema se valida y los tipos de campos son correctos, pero el contenido real es inventado. Superar la validación del esquema no equivale a que sea cierto, sin embargo, la mayoría de los equipos solo se molestan en hacer cumplir lo primero.

Tres patrones específicos de fallo aparecen con mayor frecuencia en implementaciones reales de lo que reconocen la mayoría de los documentos técnicos:

1. Llamadas a herramientas fabricadas. El modelo emite una invocación de función que parece sintácticamente correcta — algo como search_matters(client_id=…) — pero apunta a una herramienta que no existe, o proporciona argumentos que fallarían si realmente se aplicara el esquema de dicha herramienta. Las capas de orquestación que silenciosamente forzan tipos incompatibles, o que permiten al modelo intentarlo de nuevo con argumentos ligeramente redactados de otra manera, en realidad entrenan al sistema para ignorar las deficiencias en los datos en lugar de exponerlas.
2. Lavado de información entre agentes. El investigador se echa atrás diciendo “según el archivo del caso”. El analista posteriormente nunca abre ese archivo en realidad. Luego, el redactor cita al analista como fuente. Para cuando una persona revisa el resumen final, la aclaración original ha desaparecido por completo. Así es precisamente como una suposición incierta se convierte en un hecho afirmado con confianza y susceptible de facturación.

Verificador de teatro. Los equipos suelen responder agregando un agente “crítico” o “verificador” cuya única tarea es detectar alucinaciones. El problema es que este verificador también es un LLM, condicionado por el mismo contexto —con frecuencia proveniente de la misma familia de modelos— y recompensado implícitamente, a través del diseño de la solicitud, por ser conciliador y útil. Un verificador optimizado para ser útil tenderá a confirmar en lugar de cuestionar. Un verificador verdaderamente independiente necesita una fuente de información separada, una función objetivo distinta y un camino para rechazar que sea menos costoso que simplemente estar de acuerdo. Muy pocas arquitecturas ofrecen realmente eso.

La generación reforzada con recuperación de información no te salva de esto. La recuperación solo proporciona un contexto previo. Si el agente de planificación nunca formula la consulta adecuada, o si el proceso de fragmentación divide un párrafo que podría refutar la afirmación en dos embeddings separados, el agente investigador seguirá recuperando algo que suene fluido y esté temáticamente relacionado. Estar relacionado con la respuesta correcta no es lo mismo que estar lógicamente implícito en ella.

Qué debe significar “basado en hechos”, o no significa nada

“Basado en hechos” no debería ser un descriptor vago del ambiente o tono. Una afirmación dentro de un sistema multiagente solo se considera basada en hechos si se cumplen todas estas condiciones:

1. La afirmación tiene un tipo explícito. Está etiquetada como Assertion, Conjecture, Quote o ActionIntent. Combinar estas categorías en un único campo de texto sin tipificación es precisamente cómo se desintegran los registros de auditoría.
2. Cada Assertion hace referencia a un registro de origen: un pasaje recuperado, el resultado de una herramienta o un hecho proporcionado directamente por un humano. Esa referencia es un hash de contenido, nunca una URL creada por el modelo por sí mismo.
3. Una verificación determinística que no utiliza modelos de lenguaje ha confirmado que el registro de origen al que se hace referencia realmente existe en los registros del proceso. Confirmar la existencia es económico; confirmar la implicación lógica no lo es. Ambas verificaciones son necesarias, y en ese orden específico.

Cuando una verificación falla, el sistema se abstiene o pide aclaraciones. No reescribe silenciosamente la solicitud hasta que su redacción parezca lo suficientemente convincente como para ser aceptada.

Una arquitectura incapaz de negar una respuesta es incapaz de ser fiablemente veraz. Por defecto, la generación es el camino de menor resistencia; la abstención debe implementarse explícitamente como un estado de primera clase en el grafo, y debe ser más económica de alcanzar que simplemente intentarlo de nuevo con un prompt diferente.

Esa es toda la premisa. Todo lo demás son los aspectos técnicos necesarios para que estas cuatro reglas se mantengan una vez que se introduce LangGraph, las llamadas a herramientas reales y un gerente de producto que insiste en que la demostración siempre genere una respuesta.

El plano de control, no el prompt

Trate a sus agentes como un entorno en ejecución en el que no se puede confiar, y envuélvalos en un plano de control. Ese plano consta de seis componentes; si se omite uno, el resto funciona deficientemente.

1. Bus de herramientas tipadas

Cada herramienta cuenta con un esquema JSON versionado tanto para la entrada como para la salida, almacenado en un registro al que el modelo no tiene permiso para modificar. El modelo puede proponer una llamada, pero un validador determinista debe aceptarla o rechazarla *antes* de que ocurra cualquier resultado. No hay coerción de tipos, ni mapeos “suficientemente buenos” entre un valor de enumeración y lo que genere el modelo. Si una llamada es inválida, se devuelve al planificador como un error estructurado, nunca como una reprimenda verbal.

Parece un requisito obvio, pero es precisamente esa parte la que la mayoría de las demostraciones de CrewAI o AutoGen omiten, ya que nunca se encuentran con herramientas que realmente escriban en un registro permanente.

Para cualquier herramienta con consecuencias irreversibles —enviar algo, escribir un archivo, desplegar, actualizar un sistema de registro— el bus debe exigir un control dual: un ClaimSet que ya haya pasado la verificación, además de una aprobación humana o una autorización explícita basada en políticas. Con este diseño, el agente operador nunca tiene acceso directo a esas herramientas.

2. Registro de citas de solo inserción

Cada resultado de búsqueda, cada salida de herramienta y cada dato proporcionado por un humano se escribe en un almacenamiento de solo inserción, indexado mediante run_id y un hash de contenido. A los agentes no se les permite simplemente “recordar” una fuente en su propio espacio de trabajo; en su lugar, deben citar los IDs del registro.

Si un agente de escritores genera una oración sin ningún identificador de registro asociado, esa oración no constituye en absoluto una afirmación. Se trata de texto sin etiquetar, y nunca debería permitírsele pasar por la puerta de control del esquema. Este es, sin duda, el remedio más efectivo que se puede aplicar a un grafo de agentes existente: dejar de permitir que el texto en prosa sin estructura salga del sistema disfrazado de datos.

El hashing también es importante aquí. Un modelo puede citar doc:matter-4421#p3 y aun así citar erróneamente lo que realmente está escrito en la página 3. El registro debe almacenar el texto exacto — o, como mínimo, un puntero a un almacén de objetos inmutables — para que el verificador compare esos bytes exactos, y no lo que el modelo recuerde al respecto.

3. Puerta de control del esquema (no basada en LLM)

Antes de que cualquier resultado se envíe al siguiente agente —un resumen de investigación, una cifra calculada, una acción sugerida— debe pasar por una validación según un esquema que incluya:

• un array claims[], donde cada elemento contiene type, text, ledger_ids[] y un valor confidence que se calibra posteriormente en lugar de ser simplemente marcado como “alto” por el modelo
• un array open_questions[] que el planificador debe resolver o elevar explícitamente a un nivel superior
• un array action_intents[] que hace referencia a una herramienta específica, nunca a un párrafo vago que sugiera “probablemente deberíamos...”

Este componente debe ser código ordinario: Pydantic, JSON Schema, una política CEL o Rego, elige lo que prefieras. No puede tratarse de un LLM. Si colocas un modelo de lenguaje aquí, simplemente estarás reinstalando el mecanismo critic-agent en un nivel inferior.

4. Verificador de afirmaciones con un tipo diferente de información

Aquí radica el verdadero costo. Toma cada Assertion y divídela en sus partes más pequeñas que se puedan verificar, de modo que cada parte nombre un sujeto, una relación o propiedad, y un punto o período en el tiempo. Para cada una de esas partes, obtén las pruebas que la respalden solo del registro, nunca de una búsqueda en la web en tiempo real ni de los propios parámetros del modelo.

Luego realiza una verificación de implicación: ¿el fragmento obtenido respalda la proposición, la contradice o no dice nada al respecto? Puedes implementar esto con un modelo pequeño de NLI, un decodificador restringido a copiar del fragmento, o un revisor humano. Lo que no puedes hacer es asignar esta tarea al mismo modelo de chat grande, utilizando el mismo prompt del sistema, y preguntarle si la afirmación “parece correcta”.

Cuando una reclamación es rechazada, nadie modifica discretamente la redacción para que pase en el siguiente intento. Vuelve a aparecer como Unsupported{proposition, missing_evidence}, y la tarea del planificador a partir de ese momento es buscar más pruebas, no reformular el problema para que desaparezca.

Este paso también detecta un fallo más sutil: sustituir una afirmación vaga e infalsificable por otra que solo parece rigurosa. Decir que una factura parece sobreestimada no constituye por sí mismo una reclamación verificable. Establecer un monto específico —indicar el ítem de la factura, el límite contractual que se supera, la cantidad en dólares por encima de ese límite y las entradas contables que respaldan todo ello— es lo que convierte esa afirmación en algo que un verificador pueda confirmar o rechazar realmente. Un esquema que acepte la forma inicial y más vaga terminará validando el tono en lugar de los hechos.

5. Evaluar el arnés en rastros reales, no en impresiones

Se necesita un conjunto de referencia congelado: entradas, instantáneas del registro, las afirmaciones que se esperan y las abstenciones que también se anticipan. Cada cambio en el gráfico —una edición de prompt, un cambio de modelo, un chunker diferente, una herramienta nueva— se evalúa según los siguientes criterios:

• Fidelidad: qué fracción de las afirmaciones emitidas está realmente implícita en el registro
• Cobertura: qué fracción de las afirmaciones esperadas produce realmente el gráfico, ya que permanecer en silencio también puede considerarse un fallo
• Precisión de la abstención: cuando el sistema se niega a responder, ¿esa negativa está realmente justificada?
• Higiene de efectos secundarios: cero llamadas a herramientas irreversibles ejecutadas sin una autorización válida

Si una disminución de dos puntos en la fidelidad no puede impedir una implementación, entonces no se cuenta con un plano de control; solo se tiene un panel de control que da una apariencia tranquilizadora.

Sea lo que sea que haga, no construya este conjunto de evaluación a partir de las salidas anteriores del propio modelo. Eso simplemente codifica el patrón actual de alucinaciones como verdad objetiva. Las huellas de referencia deben provenir de los documentos originales subyacentes y del sistema real de registro, para luego ejecutar el grafo de forma independiente contra ellos. Es más lento hacerlo de esta manera, pero es la única versión de la métrica que realmente tiene sentido.

6. HITL en el límite irreversible

Un revisor humano no está allí para hacer que los agentes sean más inteligentes. Su tarea es estar justo en el momento en que el sistema está a punto de enviar un correo electrónico, archivar un documento o escribir en un registro. La interfaz de revisión debe mostrar el conjunto de afirmaciones, los intervalos relevantes del libro mayor y la llamada a herramienta pendiente, no un muro de historial de chat. Si alguien tiene que hacer ingeniería inversa para entender por qué el agente creyó en un hecho determinado, el diseño ya ha fallado en su función.

En los procesos de alto rendimiento —la revisión de facturas es un buen ejemplo— la revisión humana debe realizarse de forma selectiva y solo cuando haya excepciones, en lugar de aplicarse a todo. Deje que el sistema apruebe automáticamente cuando cada afirmación esté completamente respaldada y la variación financiera se encuentre dentro del rango aceptable según las políticas. Todo lo demás se marca como sospechoso, y solo se muestran las afirmaciones específicas que no están respaldadas, no todo el documento.

Un esbozo del contrato, no su implementación

Así es como debería verse aproximadamente el objeto que se transmite entre los agentes. La lógica de orquestación, la capa de verificación NLI, la capa de almacenamiento del registro contable y el componente que emite las autorizaciones se dejan intencionadamente fuera: son específicos de la implementación y pertenecen al código en producción, no a un artículo de blog.

{
  "run_id": "run_7f3c",
  "from_agent": "analyst",
  "claims": [
    {
      "id": "c_19",
      "type": "Assertion",
      "text": "Line item 14 exceeds the engagement-letter hourly cap.",
      "propositions": [
        {
          "id": "p_19a",
          "pred": "exceeds_cap",
          "args": {"line_id": "14", "cap_source": "engagement_letter"},
          "ledger_ids": ["led_aa12", "led_bb90"],
          "entailment": null
        }
      ]
    }
  ],
  "open_questions": [],
  "action_intents": [
    {
      "tool": "flag_invoice_line",
      "args": {"invoice_id": "INV-4421", "line_id": "14"},
      "requires_grant": true,
      "depends_on": ["c_19"]
    }
  ]
}

Observe lo que falta: no existe un campo summary al que el siguiente agente pueda recurrir directamente. Los resúmenes son precisamente donde se pierden los calificadores y las reservas. Si un agente posterior necesita texto en prosa, debe construir esa narrativa únicamente a partir de afirmaciones verificadas, y hasta que un humano lo apruebe como texto dirigido al cliente, se le asigna la etiqueta Conjecture.

También fíjese que entailment está establecido en null. El agente que formuló la afirmación no tiene permiso para completar ese campo por sí mismo; solo el verificador puede hacerlo. Permitir que un agente evalúe sus propias afirmaciones es como dejar que una empresa realice su propia auditoría de cumplimiento y llamarla supervisión independiente.

Por qué “solo añadir citas” sigue fallando

La medida de protección falsa más común es una salida que solo parece estar citada. El modelo agrega [1] o [2], a veces incluso haciendo referencia a un fragmento real recuperado. Luego se abre ese fragmento y se descubre que en realidad no respalda la afirmación.

Una mera cita por sí sola no demuestra nada. La prueba real se ve así: este fragmento específico de texto, este conjunto exacto de bytes, asociado a una proposición concreta, que lleva una etiqueta de implicación y está regido por una política explícita sobre qué ocurre cuando dicha etiqueta es neutral. Sin toda esa cadena, una “cita” no es más que una elección de formato disfrazada de evidencia.

La segunda medida de protección falsa es establecer la temperatura en 0. Eso no hace que la salida sea más veraz; solo hace que una respuesta incorrecta sea coherente. Una alucinación estable superará siempre las pruebas de captura instantánea, pero no sobrevivirá a un registro debidamente mantenido.

Lo que realmente cuesta, honestamente

Hacer funcionar un pipeline de demostración en algo como LangGraph lleva unos días. Construir el plano de control real que está detrás de él —un registro de herramientas, un libro de citaciones, filtros basados en esquemas, un verificador basado en NLI, evaluaciones con seguimiento de referencia, revisión humana en cada ruta que permita escritura, y registros lo suficientemente detallados como para que un abogado pueda seguirlos— es lo que diferencia un prototipo funcional de un sistema en el que se pueda confiar para tomar decisiones empresariales reales.

No existe un número único que sea aplicable en todos los casos. El costo real depende de cuántas de sus herramientas generen efectos secundarios, de si su fuente de información ya está estructurada y permite realizar búsquedas, y de cuán costoso resulta en su área específica un reclamo sin soporte. La facturación legal y la elaboración de informes financieros se encuentran en el extremo del alto costo y las altas consecuencias de ese espectro. Una herramienta de lluvia de ideas desarrollada a partir de un grupo de agentes está en el extremo opuesto, y forzarla a contar con tanta infraestructura sería un exceso.

La pregunta que merece hacerse primero no es sobre qué framework utilizar para desarrollarla, sino determinar dónde se sitúa su propio flujo de trabajo dentro de ese espectro.

Si este es el problema que realmente tiene

Este tipo de plano de control es especialmente importante para los equipos que no pueden permitirse respuestas que suenen seguras pero estén equivocadas: generalmente, en trabajos legales, financieros y operaciones con muchos documentos. Esto implica gráficos de agentes creados con herramientas como LangGraph, pipelines de recuperación que se evalúan realmente en lugar de dar por sentado que funcionan, y sistemas de extracción que deben resistir una auditoría.

Si su propio gráfico funciona de manera convincente en una demostración pero comienza a generar afirmaciones falsas una vez está en producción, la causa suele atribuirse a uno de los seis componentes mencionados aquí; determinar cuál es y si vale la pena invertir esfuerzos técnicos para solucionarlo constituye el verdadero punto de partida para delimitar el trabajo.

Lecturas relacionadas

• Diseñando grafos de agentes de IA resilientes: reintentos, fallbacks y GraphRAG — Aprenda cómo crear flujos de trabajo de agentes de IA tolerantes a fallos utilizando ramas de error explícitas, lógica de reintentos, LangGraph, y cuándo GraphRAG supera a RAG tradicional o a los bucles de agentes.
• Lo que revela la construcción de un agente en 10 minutos sobre la arquitectura real — Explora por qué las herramientas rápidas para crear agentes como TrueForge pueden ocultar decisiones arquitectónicas que los frameworks manuales como Deep Agents obligan a enfrentar.