Production Stack: Cómo construir sistemas de agentes confiables

La idea en 30 segundos

Production Stack no es un solo componente, sino un conjunto coordinado de capas arquitectónicas que, juntas, hacen que un sistema de agentes sea gobernable en producción.

Esto no es "más prompts". Son límites explícitos de responsabilidad:

• quién toma decisiones;
• quién permite o bloquea una acción;
• dónde se almacena el estado;
• cómo se controlan riesgos, presupuestos y fallos.

Cuándo se necesita: cuando el agente debe funcionar por largo tiempo, ejecutar acciones que cambian estado, atender muchos clientes y mantenerse predecible bajo carga.

El LLM propone el siguiente paso, pero Production Stack decide si ese paso se puede ejecutar, dónde se ejecuta y cómo detener el proceso de forma segura.

Problema

Si construyes un agente como "modelo + algunos tool calls", el sistema se vuelve frágil muy rápido.

Consecuencias típicas:

• no hay stop conditions claras, así que el agente se queda en bucles;
• no hay límites de policy, así que acciones riesgosas pasan sin control;
• no hay calidad de memoria, así que aparecen duplicados, ruido o personalización incorrecta;
• no hay aislamiento tenant, así que crece el riesgo de fugas cross-tenant;
• no hay disciplina operativa, así que rollout, rollback y respuesta a incidentes se vuelven caóticos;
• no hay auditoría end-to-end, así que tras un fallo es difícil explicar qué pasó.

En producción, esto normalmente significa incidentes de seguridad, sobrecostes y calidad inestable de respuestas.

Solución

Agregar Production Stack como un esquema arquitectónico explícito donde cada capa tiene un contrato claro y su propia zona de responsabilidad.

Composición típica del stack:

1. Ingress + Auth (resolver actor/tenant);
2. Orchestration Topology (route, handoff, stop);
3. Agent Runtime (steps, límites, reason_code);
4. Tool Execution Layer (validación y control de side effects, es decir cambios de estado);
5. Memory Layer (lectura/escritura de memoria gobernada);
6. Policy Boundaries + Human-in-the-Loop (permitir, bloquear, aprobar);
7. Containerization + Observability + Operations (ejecución reproducible, health checks, rollback);
8. Multi-Tenant Isolation (aislamiento de contexto, accesos y recursos).

Analogía: como un aeropuerto moderno.

Tiene check-in, control de seguridad, enrutamiento, despacho, registro de eventos y procedimientos de emergencia.

Production Stack convierte igual "un módulo inteligente" en un sistema gobernado con reglas de ejecución.

Cómo funciona Production Stack

Production Stack conecta todos los límites clave en un ciclo gobernado: desde la solicitud de entrada hasta la ejecución controlada, auditoría y recuperación.

Este ciclo elimina la "magia" del sistema de agentes y lo vuelve predecible bajo carga real.

En código se ve así

class ProductionStack:
    def __init__(self, ingress, topology, runtime, memory, policy, hitl, tools, audit):
        self.ingress = ingress
        self.topology = topology
        self.runtime = runtime
        self.memory = memory
        self.policy = policy
        self.hitl = hitl
        self.tools = tools
        self.audit = audit

    def run(self, request, auth_token):
        ctx = self.ingress.identify(request=request, auth_token=auth_token)
        if not ctx.get("ok", False):
            return {"ok": False, "reason_code": ctx.get("reason_code", "auth_failed")}

        state = self.runtime.start(
            request=request,
            tenant_id=ctx["tenant_id"],
            budgets=ctx["budgets"],
        )

        while not self.runtime.should_stop(state):
            route = self.topology.next_step(state=state)
            route_mode = route.get("mode")

            if route_mode == "finish":
                return {
                    "ok": True,
                    "result": route.get("final_answer", ""),
                    "reason_code": "completed",
                }
            if route_mode != "action":
                return {"ok": False, "reason_code": "unknown_route_mode"}

            memory_items = self.memory.retrieve(
                tenant_id=ctx["tenant_id"],
                query=route["query"],
                top_k=4,
                min_score=0.7,
                exclude_expired=True,
            )

            action = self.runtime.decide(route=route, memory_items=memory_items)
            decision = self.policy.check(action=action, context=ctx)
            mode = decision.get("mode")

            if mode == "deny":
                self.audit.log(context=ctx, action=action, outcome="blocked", reason_code=decision.get("reason_code", "policy_denied"))
                return {"ok": False, "reason_code": decision.get("reason_code", "policy_denied")}
            elif mode == "require_approval":
                approval = self.hitl.review(action=action, context=ctx)
                if not approval.get("approved", False):
                    reason = approval.get("reason_code", "approval_rejected")
                    self.audit.log(context=ctx, action=action, outcome="blocked", reason_code=reason)
                    return {"ok": False, "reason_code": reason}
                action = approval.get("action_override", action)
            elif mode != "allow":
                reason = decision.get("reason_code", "policy_mode_invalid")
                self.audit.log(context=ctx, action=action, outcome="blocked", reason_code=reason)
                return {"ok": False, "reason_code": reason}

            result = self.tools.execute(action=action, context=ctx)
            self.audit.log(
                context=ctx,
                action=action,
                outcome="executed" if result.get("ok", False) else "failed",
                reason_code=result.get("reason_code", "tool_unknown"),
            )

            self.runtime.observe(state=state, action=action, result=result)
            self.memory.write_if_useful(
                tenant_id=ctx["tenant_id"],
                state=state,
                result=result,
            )

        return {"ok": False, "reason_code": self.runtime.stop_reason(state)}

Cómo se ve durante la ejecución

Solicitud: "Prepara una propuesta comercial, alinea los puntos de riesgo y envía la versión final al cliente"

Step 1
Ingress + Auth: resuelve actor, tenant, budgets y request_id
Orchestration Topology: divide la tarea en etapas "recopilar", "borrador", "finalizar"

Step 2
Agent Runtime: forma action
Policy + HITL: activa require_approval para el envío al cliente
Human aprueba la versión final

Step 3
Tool Execution Layer: ejecuta la acción aprobada
Memory Layer: guarda hechos importantes con TTL
Audit + Trace: registra decision, reason_code, outcome

Production Stack no reemplaza patrones individuales. Los conecta en un sistema de producción gobernado.

Cuándo encaja y cuándo no

Production Stack se necesita donde el agente debe funcionar como servicio, no como script demo de una sola vez.

Encaja

No encaja

Para un prototipo mínimo, a veces basta una ejecución simple:

result = runtime.run(task=request["text"], max_steps=8, max_seconds=20)

Problemas y fallos típicos

La mayoría de problemas de producción no ocurre por un único "error del modelo", sino por límites débiles entre capas arquitectónicas.

Cómo se combina con otros patrones

Production Stack no compite con otros patrones. Los integra en un sistema coherente.

• Agent Runtime — gestiona el ciclo de pasos y stop conditions.
• Tool Execution Layer — controla la ejecución de herramientas y side effects (cambios de estado).
• Memory Layer — recupera y escribe solo memoria útil según criterios de calidad.
• Policy Boundaries — define allow/deny/require_approval para acciones riesgosas.
• Orchestration Topologies — define la ruta de la tarea entre agentes.
• Hybrid Workflow Agent — separa workflow determinista y decisiones acotadas del agente.
• Human-in-the-Loop Architecture — añade control humano en puntos críticos.
• Containerizing Agents — aporta ejecución reproducible, health checks y control de rollout.
• Multi-Tenant — aísla contexto, recursos y accesos entre clientes.

En otras palabras:

• Production Stack define cómo todas estas capas trabajan juntas como un solo sistema
• Cada patrón individual cubre su tipo específico de riesgo

En resumen

FAQ

Q: ¿Por dónde empezar si no hay recursos para todo el stack de una vez?
A: Empieza por Runtime (límites + stop reasons), Tool Execution Layer (validación + timeout) y auditoría. Luego añade por fases policy/HITL, calidad de memoria y aislamiento multi-tenant.

Q: ¿Se puede tener Production Stack con un solo agente, sin topología multi-agent?
A: Sí. La topología puede ser simple, pero las demás capas siguen siendo necesarias si hay acciones riesgosas o carga de producción.

Q: ¿Production Stack reemplaza observability o prácticas SRE?
A: No. Las incluye como parte de la arquitectura, pero sigue requiriendo disciplina operativa: monitoreo, alertas, rollout e incident response.

Q: ¿Qué se rompe primero cuando el stack está incompleto?
A: Lo más frecuente es que se rompan los límites de ejecución: tool calls no controlados, memoria ruidosa o huecos de policy sin auditoría.

Qué sigue

Production Stack es el mapa de todo el sistema. Ahora puedes profundizar en las capas que más suelen romperse primero:

• Tool Execution Layer — control de herramientas, timeouts y side effects (efectos secundarios, es decir cambios de estado).
• Memory Layer — calidad de memoria, TTL y control de datos sensibles.
• Policy Boundaries — allow/deny/approval para acciones riesgosas.
• Multi-Tenant — aislamiento de contexto, recursos y presupuestos entre clientes.