4 min de lecturaParte 3

Los frameworks de agentes no bastan para ejecución en producción

Las cadenas de prompts, los grafos sintácticos y los bucles while resuelven la orquestación básica, pero fallan en la ingeniería de sistemas reales.

J

José Vásquez

Fundador e Ingeniero Principal @ Invariant

#AI Agents#Architecture#Production#Infrastructure
Serie de ArtículosArquitectura de Agentes Confiables
Parte 3Los frameworks de agentes no bastan para ejecución en producción

En los últimos dos años, el ecosistema de IA ha visto nacer docenas de frameworks de agentes. La mayoría se enfoca en plantillas de prompts, grafos de conversación multi-agente y abstracciones de enrutamiento de alto nivel.

Estos frameworks son atractivos para prototipar. Sin embargo, cuando los equipos de ingeniería los despliegan en entornos de producción de alto volumen, se topan con una realidad implacable: los wrappers de lógica de aplicación no pueden compensar la ausencia de infraestructura de sistemas.

Tesis Principal

El prompt engineering y la orquestación en grafos describen qué quieres que haga un agente. La infraestructura de sistemas—transacciones, idempotencia, registros de eventos y durabilidad—garantiza que realmente suceda de forma confiable.


Dónde se quedan cortos los frameworks de agentes

Cuando un agente sale de un notebook y entra a la arquitectura empresarial, los problemas difíciles no son de plantillas de texto. Son problemas clásicos de sistemas distribuidos:

1. La trampa del estado en memoria

La mayoría de librerías de agentes guardan el estado de la sesión en la memoria volátil del proceso de Node.js o Python. Si el pod se reinicia, sufre un auto-scaling o despliega una nueva versión, todas las sesiones de agentes activas se pierden irremediablemente.

2. La ilusión de la colaboración multi-agente

Hacer que 5 agentes virtuales conversen entre sí en un chat consume tokens exponencialmente sin resolver la sincronización. Sin consenso transaccional de estado, los sistemas multi-agente sufren de condiciones de carrera, mutaciones contradictorias y alucinaciones en cascada.

3. Falta de idempotencia real

Envolver una llamada a Stripe o SendGrid dentro de una función de herramienta no la hace resiliente. Si la red se corta después de que la API externa cobró al usuario pero antes de que el agente reciba la respuesta HTTP, ¿cómo se recupera el framework? Un bucle de agentes tradicional reintentará el paso y duplicará el cobro.

El flujo de Transactional Outbox en InvariantInvariant Architecture
STEP 1

Action Proposed

LLM emits intent payload

STEP 2

Validation Gate

Schema, permissions & policy

STEP 3

Transactional Outbox

Atomically recorded in DB

STEP 4

Durable Execution

Idempotent side effect execution

Figura 1: Confirmación de la intención antes del despacho y control del riesgo de duplicados mediante claves estables de idempotencia.

Primitivas de infraestructura sobre wrappers sintácticos

La ingeniería de agentes confiables exige construir sobre primitivas sólidas de sistemas distribuidos:

1. Event Sourcing relacional sobre historiales de chat

En lugar de guardar transcripciones de chat como texto crudo, cada cambio de estado se registra como un evento inmutable en una base de datos relacional como PostgreSQL. Esto proporciona:

  • Auditoría completa para cumplimiento y seguridad
  • Reconstrucción de contexto durable de Session (Sessions)
  • Ramificación determinista mediante fragmentos explícitos de workflow

2. Transactional Outbox sobre llamadas HTTP directas

Los efectos secundarios externos se desacoplan del bucle de inferencia. La intención se confirma atómicamente con las actualizaciones de estado y el dispatcher actual la ejecuta en proceso. El proveedor externo aún debe respetar claves estables de idempotencia. La Beta pública no incluye un worker portable de claim de comandos ni un loop cross-process de reintentos.

3. Suspensiones nativas sobre bucles de espera (polling)

Cuando un flujo requiere validación humana o espera un webhook asíncrono, no debe consumir ciclos de cómputo. Invariant persiste la frontera de espera y el estado; la Session viva puede recibir la entrada correspondiente. Adjuntar un proceso nuevo a esa ejecución aún requiere código de recuperación propiedad de la aplicación en la Beta pública.


El enfoque de Invariant: Infraestructura primero

Invariant está diseñado como un Plano de Control Durable para TypeScript y Node.js. No intenta reemplazar tu proveedor de LLM favorito ni tus estrategias de prompting; provee el sustrato determinista sobre el cual los agentes se ejecutan en producción.

import { invariant } from '@invariant-tech/sdk';
import { sqlite } from '@invariant-tech/sqlite';
import { z } from 'zod';

const app = invariant({ storage: sqlite('./data/onboarding.db') });

export const onboardingCliente = app.workflow('customer-onboarding', {
  description: 'Aprovisiona cuentas empresariales con cumplimiento normativo',
})
  .capability('provision-tenant', provisionDatabaseTenant)
  .wait('await-compliance-signoff', {
    schema: z.object({ complianceApproved: z.boolean(), officerId: z.string() }),
  })
  .capability('send-welcome-credentials', sendCredentialsEmail);

// El modelo razona sobre el contexto; el runtime vigila la frontera de ejecución
export const agenteOnboarding = app.agent('onboarding-coordinator', {
  workflows: [onboardingCliente],
});

Al proporcionar primitivas durables de estado, eventos, intención de outbox, leases y espera, Invariant te permite concentrarte en la lógica de negocio. El claim portable de comandos, el attach de ejecución y la orquestación de recuperación en segundo plano siguen siendo trabajo explícito de Beta a v1.


Conclusión de la serie

Con esto completamos nuestra serie de 4 partes sobre Arquitectura de Agentes Confiables:

  1. Parte 1: El contexto no es memoria — Desacoplando el contexto efímero de la infraestructura persistente.
  2. Parte 2: Por qué los agentes necesitan un runtime determinista — Estableciendo la frontera validada entre razonamiento probabilístico y ejecución determinista.
  3. Parte 3: Los frameworks de agentes no bastan para ejecución en producción — Construyendo sobre infraestructura de sistemas durable.
  4. Parte 4: Por qué la IA debería proponer, no ejecutar — La frontera ausente entre razonamiento probabilístico y ejecución autoritativa.

Para conocer cómo implementar estos patrones en tus aplicaciones TypeScript, visita nuestra Documentación Canónica o comienza con nuestra guía rápida.

J

José Vásquez

Fundador e Ingeniero Principal @ Invariant

Construyendo el motor de ejecución durable para agentes de IA en TypeScript. Mantén el razonamiento probabilístico, haz la ejecución predecible.