Dos Sandboxes para Agentes IA: Guía LangChain 2026
El problema que nadie te cuenta cuando empiezas con agentes IA
Los agentes de IA son potentes porque pueden ejecutar código, navegar por la web, leer archivos y llamar a APIs. Precisamente por eso son peligrosos si no se diseñan bien.
Harrison Chase, fundador de LangChain, lleva tiempo advirtiendo sobre este punto ciego: la mayoría de los equipos se centran en la inteligencia del agente y olvidan el entorno donde ese agente opera. Y el entorno lo es todo cuando el agente tiene capacidad de acción real.
En su análisis sobre arquitecturas para agentes en producción, Chase identifica dos grandes familias de sandbox que todo equipo debería conocer antes de desplegar. Aquí las explicamos con ejemplos concretos y código aplicado a proyectos React/Next.js.
¿Qué es un sandbox para agentes IA?
Un sandbox es un entorno de ejecución aislado donde el agente puede operar sin afectar al sistema anfitrión. Piensa en él como una caja de arena virtual: el agente juega dentro, pero no puede salir a romper nada de tu infraestructura real.
Sin sandbox, un agente que ejecuta código Python podría, por accidente o por un prompt malicioso, eliminar archivos, hacer peticiones a APIs externas sin control o consumir recursos de CPU sin límite.
La pregunta no es si necesitas un sandbox. La pregunta es qué tipo de sandbox necesitas según tu caso de uso.
Arquitectura 1: El sandbox efímero (stateless)
El sandbox efímero o stateless es el más simple y el más seguro. Funciona así:
- El agente recibe una tarea.
- Se levanta un entorno aislado nuevo (contenedor, microVM...).
- El agente ejecuta su lógica dentro de ese entorno.
- El entorno se destruye al terminar, sin dejar rastro.
Cuándo usarlo:
- Ejecución de código generado por el LLM (análisis de datos, transformaciones, cálculos)
- Scraping o acceso puntual a webs
- Tareas de un solo paso sin necesidad de contexto previo
Herramientas populares para este patrón: E2B Code Interpreter SDK, Modal, Daytona.
// Ejemplo simplificado con E2B en un API Route de Next.js
import { Sandbox } from "@e2b/code-interpreter";
export async function POST(req: Request) {
const { code } = await req.json();
// Cada llamada crea un sandbox nuevo y lo destruye al terminar
const sandbox = await Sandbox.create();
try {
const result = await sandbox.runCode(code);
return Response.json({ output: result.text });
} finally {
await sandbox.kill(); // entorno destruido — slate limpia
}
}
La clave de este patrón es el bloque finally: el sandbox se destruye siempre, haya error o no. Ningún estado persiste entre ejecuciones. Máxima seguridad, mínima superficie de ataque.
Limitación principal: si tu agente necesita recordar lo que hizo en el paso anterior (instalar una librería, guardar un archivo intermedio), este patrón no es suficiente.
Arquitectura 2: El sandbox persistente (stateful)
El sandbox persistente o stateful mantiene el entorno vivo entre varias interacciones del agente. El mismo entorno acumula contexto: archivos creados, paquetes instalados, variables de sesión.
Cuándo usarlo:
- Agentes que trabajan en proyectos de varios pasos (escribir código → instalar deps → ejecutar tests → iterar)
- Automatización de flujos de trabajo donde el estado importa
- Sesiones de usuario donde el agente actúa como asistente continuo
// Patrón sandbox persistente — el sandbox vive durante toda la sesión
import { Sandbox } from "@e2b/code-interpreter";
const activeSandboxes = new Map<string, Sandbox>();
async function getOrCreateSandbox(sessionId: string): Promise<Sandbox> {
if (activeSandboxes.has(sessionId)) {
return activeSandboxes.get(sessionId)!;
}
const sandbox = await Sandbox.create({ timeoutMs: 10 * 60 * 1000 }); // 10 min
activeSandboxes.set(sessionId, sandbox);
return sandbox;
}
// El agente puede instalar dependencias en el paso 1 y usarlas en el paso 3
export async function runAgentStep(sessionId: string, code: string) {
const sandbox = await getOrCreateSandbox(sessionId);
return sandbox.runCode(code);
}
En este modelo, el sandbox asociado a sessionId persiste mientras la sesión esté activa. Un agente puede instalar pandas en el primer turno y usarlo diez turnos después sin tener que reinstalarlo.
Limitación principal: mayor complejidad operativa. Hay que gestionar el ciclo de vida del sandbox (timeouts, limpieza), y la superficie de ataque aumenta porque el estado puede acumularse.
Cómo elegir entre las dos arquitecturas
| Criterio | Efímero (stateless) | Persistente (stateful) |
|---|---|---|
| Seguridad | Máxima | Media-alta (requiere gestión) |
| Complejidad | Baja | Media-alta |
| Rendimiento | Ligero penalizado por arranque | Más rápido en ejecuciones sucesivas |
| Casos de uso | Tareas únicas, análisis puntuales | Flujos multi-paso, asistentes de sesión |
| Coste | Por ejecución (barato en tareas cortas) | Por tiempo activo (cuidado con timeouts) |
En la práctica, los sistemas de agentes más robustos combinan ambos patrones: usan efímeros para subtareas de riesgo alto (ejecutar código desconocido) y persistentes para el flujo principal de trabajo del agente.
Aplicación real en proyectos React/Next.js
En nuestros proyectos de integración IA, aplicamos esta arquitectura en sistemas donde el agente ayuda a los usuarios a analizar datos o generar código a medida:
- Efímero para el módulo de análisis de ficheros CSV que el usuario sube: el código generado por el LLM se ejecuta en un sandbox nuevo cada vez, sin riesgo de contaminación entre usuarios.
- Persistente para el asistente de desarrollo que ayuda al equipo a iterar sobre código en sesiones largas.
La clave está en mapear el riesgo y el estado necesario antes de elegir la arquitectura. No es una decisión técnica: es una decisión de producto.
Conclusión
Las dos arquitecturas sandbox que describe Harrison Chase no son alternativas excluyentes, sino herramientas complementarias. Efímero = máxima seguridad para tareas aisladas. Persistente = mayor potencia para flujos con estado.
El error más común es omitir esta capa de diseño por completo y dejar al agente operar directamente sobre el sistema anfitrión. No hay atajos seguros aquí.
Si estás diseñando un sistema de agentes IA y quieres asegurarte de elegir la arquitectura correcta para tu caso de uso, podemos ayudarte a diseñarlo desde cero. Escríbenos directamente y lo vemos juntos: