BookinglyTech News
Inteligencia artificial

Los agentes de IA siguen fallando en producción y la solución es construir sistemas deterministas

Los fallos de los agentes de IA provienen de su arquitectura no determinista; la propuesta es usar LLMs solo para resolver ambigüedades dentro de flujos controlados.

3 min de lecturaDev.to0 vistas

Los demos de agentes de IA pueden parecer mágicos, pero al intentar desplegarlos en producción aparecen problemas habituales: alucinaciones, pérdida de contexto, fallos impredecibles y falta de reproducibilidad. Los ingenieros terminan dedicando semanas a corregir casos límite que nunca aparecían en los notebooks. El origen no es el modelo de lenguaje, sino la arquitectura del agente. Cada decisión no determinista encadena modos de fallo y, cuando un planificador interpreta mal un objetivo o una herramienta devuelve datos ligeramente erróneos, el flujo entero se derrumba.

Por qué los agentes colapsan bajo restricciones reales

  • No hay una ruta de contingencia determinista. Cuando el LLM devuelve basura, el agente sigue procesando y los errores se acumulan.
  • El espacio de estado es ilimitado. Cada prompt es una tirada nueva de dados, por lo que no se pueden reproducir entradas y esperar el mismo resultado. Depurar se vuelve imposible; no existen puntos de interrupción en un prompt y rastrear la cadena de razonamiento requiere reconstruir una secuencia probabilística.
  • La integración con herramientas es frágil. Los agentes asumen que las APIs externas funcionan perfectamente, pero en producción los tiempos de espera, respuestas parciales o cambios de esquema son la norma.

Qué funciona en producción

En lugar de construir agentes autónomos, el artículo propone sistemas deterministas que usan LLMs como co‑procesadores para la capa de ambigüedad. Tres patrones básicos son suficientes:

  1. Clasificación de intención, no planificación. Se sustituye la planificación libre por una lista cerrada de intenciones. Un LLM solo clasifica la solicitud del usuario y el sistema dirige a un manejador determinista.

    INTENTS = ["transfer_money", "check_balance", "dispute_transaction"]
response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "system", "content": f"Classify into one of: {INTENTS}. Return only the intent."},
              {"role": "user", "content": user_input}],
)
intent = response.choices[0].message.content.strip()
result = HANDLERS[intent](user_input)

    El flujo es predecible, testeable y los fallos son claros.

  2. Ejecución estructurada de herramientas. Los workflows se definen como grafos acíclicos dirigidos (DAG) y el LLM únicamente extrae parámetros. Cada paso del DAG es una función determinista.

    class Workflow:
    def __init__(self, name, steps):
        self.name = name
        self.steps = steps
    def run(self, params):
        for step in self.steps:
            result = step.execute(params)
            params.update(result)
        return params

    De esta forma el LLM no orquesta la ejecución, solo suministra datos.

  3. Guardrails. Se valida la entrada y la salida del LLM como si fuera una respuesta de API externa. Nunca se confía ciegamente en el modelo.

    if not validate_user_id(user_id):
    raise ValueError("Invalid user ID")
result = llm_call(prompt)
if not validate_output(result, schema):
    raise RuntimeError("LLM returned invalid structure")

Al combinar clasificación + enrutamiento, extracción + validación y generación + plantillas, se cubren el 95 % de los casos y el resto se gestiona mediante logs y derivaciones manuales. La clave está en tratar al LLM como un co‑procesador especializado, no como un agente autónomo.

En definitiva, la estrategia que funciona en producción es abandonar la idea de agentes totalmente autónomos y construir sistemas deterministas donde el LLM interviene sólo donde la ambigüedad humana lo exige. Queda por ver cómo evolucionan los frameworks que faciliten este enfoque y si la comunidad adopta patrones similares a gran escala.

Historias Relacionadas