spinny:~/writing $ cat agentic-infrastructure-stack.md

La infraestructura agente y el nuevo backend.

2026-06-30 · 11 min read · Filippo Spinella · AI, Agents, Infrastructure, Developer Tools

A menudo hemos hablado de marcos agentes. LangGraph, CrewAI, AutoGen, varios SDK, bucle, llamada de herramientas, memoria, planificador, crítico, supervisor. Todas palabras útiles, por el amor de Dios. Pero cuanto más miro los agentes realmente utilizados, más me parece que la parte interesante se ha movido por debajo del nivel del marco.

La pregunta ya no es sólo: ¿qué biblioteca uso para hacer pensar un modelo de pasos?

La verdadera pregunta es: ¿dónde vivirá este agente cuando deje de ser demo?

Porque un agente serio no es una función que llama a un modelo y devuelve texto. Es un pequeño sistema distribuido. Debe leer el contexto, usar herramientas, ejecutar código, tocar archivos, recordar decisiones, pedir permiso, fallar bien, reiniciar, dejar registros, no quemar el presupuesto y no convertirse en una excavadora dentro del repositorio de producción.

El marco es el volante. La infraestructura es la carretera, los frenos, el garaje, el seguro y la persona que sabe dónde están las llaves.

Porque ahora se habla mucho de ello.

En 2023 y 2024 la conversación estuvo muy centrada en los modelos. ¿Qué LLM? ¿Cuánto contexto? ¿Cuánto cuesta? ¿Qué tan bueno es en programación?

En 2025 y 2026 la conversación ha cambiado. Los modelos son lo suficientemente buenos para hacer un trabajo real, pero es por eso que las partes aburridas se vuelven visibles: tiempo de ejecución, seguridad, conectores, identidad, observabilidad, ejecución de código, implementación, reversión.

Es la transición natural de la magia a la ingeniería.

Cuando un agente sólo necesita generar una respuesta, un chat es suficiente. Cuando necesita abrir una solicitud de extracción, consultar una base de datos, llamar a un CRM, iniciar un trabajo, navegar por un sitio, leer Slack, compilar código y actualizar un documento, necesita un sistema operativo a su alrededor.

No en un sentido literal. En un sentido organizativo.

La primera pieza: un tiempo de ejecución donde el agente puede durar

Un agente suele trabajar por pasos. Mira el estado, elige una acción, usa una herramienta, observa el resultado, actualiza el plan, repite.

Si este bucle se encuentra dentro de una única solicitud HTTP, inmediatamente tienes un problema. Algunas acciones son lentas. Algunos esperan la aportación humana. Algunas fracasan y deben intentarse nuevamente. Algunos deben sobrevivir a un despliegue o a un tiempo de espera.

Aquí es donde entran en juego flujos de trabajo duraderos, colas, antecedentes laborales y máquinas de estado. No son glamorosos, pero marcan la diferencia entre un agente que parece inteligente en la demostración y uno al que puedes dejar trabajando mientras vas a tomar un café.

Para mí, el tiempo de ejecución agente debe responder preguntas muy concretas:

¿Dónde guardo el estado entre un paso y otro?
¿Qué pasa si el proceso muere a la mitad?
can I pause and ask for approval?
¿Puedo repetir una carrera para entender por qué tomó esa decisión?
¿Puedo limitar la duración, la memoria, las herramientas y el costo?

Vercel está presionando mucho en este frente con SDK, funciones, flujos de trabajo y herramientas de IA para crear agentes dentro de aplicaciones web. Pero la cuestión no es sólo Vercel. La cuestión es que el agente necesita un hogar operativo, no un único punto final.

La segunda pieza: sandbox, porque el agente debe poder ensuciarse sin romperse

Tan pronto como un agente escribe código o ejecuta comandos, se necesita un entorno limitado.

Parece una palabra técnica, pero la idea es doméstica: le das un banco de trabajo. Puede abrir archivos, instalar dependencias, ejecutar pruebas, realizar experimentos y generar resultados. Si se equivoca, habrás contenido el daño. Si funciona, promociona el resultado.

Un sandbox agente debería tener algunas propiedades:

sistema de archivos aislado;
CPU, memoria y límites de tiempo;
red controlada;
secretos montados sólo cuando sea necesario;
registros completos;
posibilidad de exportar artefactos;
reinicio limpio entre ejecuciones, cuando sea necesario.

Vercel Sandbox va exactamente en esta dirección: entornos aislados para ejecutar código, instalar dependencias, trabajar con archivos y producir artefactos sin ejecutar todo en el tiempo de ejecución de la aplicación principal.

Esto es más importante de lo que parece. Muchos prototipos agentes saltan directamente del modelo al sistema real. El modelo puede llamar a la herramienta. Las herramientas pueden hacer cosas. Todo parece elegante hasta el primer comando incorrecto, la primera dependencia instalada en el lugar equivocado, el primer token que termina en un registro.

El arenero es la forma adulta de decir: adelante, pero aquí dentro.

La tercera pieza: MCP y el problema del conector

El Protocolo de Contexto Modelo se ha convertido en una de las partes más interesantes del ecosistema porque intenta estandarizar algo que de otro modo rápidamente se vuelve inmanejable: cómo un modelo descubre y utiliza herramientas externas.

Sin un estándar, cada integración es una pequeña isla. Un conector para GitHub hecho de una manera, uno para Slack hecho de otra, uno para bases de datos con semántica diferente, uno para la automatización del navegador que parece nada.

MCP propone un lenguaje común entre cliente y servidor: herramientas, recursos, avisos, autorizaciones, transporte, descubrimiento. No resuelve mágicamente la gobernanza y la seguridad, pero proporciona una gramática.

Y la gramática importa. Cuando un agente puede conectarse a muchas herramientas, la pregunta no es simplemente "¿puede hacerlo?". El problema es "¿entiende qué puede hacer, con qué límites, en nombre de quién y dejando qué huella?".

Para mí, MCP no es una exageración porque "hace llamadas a herramientas". Eso ya lo hicimos. Es una exageración porque cambia el centro de gravedad de la integración única al catálogo operativo de herramientas.

En una buena arquitectura agentic, MCP se convierte en una especie de panel de conexiones:

GitHub para código y problemas;
Slack para contexto conversacional;
Linear o Jira para trabajos planificados;
base de datos de sólo lectura para análisis;
navegador o raspador controlado para sitios externos;
almacenamiento de documentos;
entornos de ejecución aislados;
sistemas internos expuestos con permisos estrictos.

La parte complicada es que un catálogo de herramientas sin políticas es simplemente una forma más elegante de crear caos.

La cuarta pieza: identidad y permisos

Esta es el área donde muchas demostraciones hacen la vista gorda.

Un agente actúa en nombre de alguien. Por eso debe quedar claro quién es el sujeto de la acción.

¿Está utilizando permisos de usuario? ¿De una cuenta de servicio? ¿De un espacio de trabajo? ¿Tiene acceso temporal o permanente? ¿Puedes leer todo o solo algunos recursos? ¿Puedes escribir? ¿Puedes cancelar? ¿Puede enviar mensajes de texto a personas reales?

Si no respondes bien a estas preguntas, tarde o temprano te construirás un asistente con las llaves de la casa y sin recordar quién se las dio.

La regla general que me gusta es la siguiente: el agente debe poder hacer menos que el humano, no más que el humano. Y cuando tiene que hacer algo más arriesgado, tiene que pararse y preguntar.

Esto significa OAuth, ámbito de token, gestión de secretos, registro de auditoría, política de herramientas, lista de permitidos y paso de aprobación. Cosas no muy románticas. Cosas necesarias.

La quinta pieza: memoria y contexto, pero sin acumular basura

Los agentes necesitan memoria, pero la memoria es peligrosa cuando se convierte en un ático.

Existen al menos tres tipos de memoria:

memoria de ejecución: qué pasó en esta ejecución;
memoria del proyecto: convenciones, decisiones, limitaciones;
memoria personal o de equipo: preferencias, tono, rituales, procesos.

Poner todo en el mensaje es el atajo. Funciona hasta que ya no funciona. Hay que cuidar la memoria útil: indexarla, actualizarla, caducarla, verificarla, hacerla citable.

Un agente que recuerda mal es peor que un agente que no recuerda. Porque habla con confianza.

Por lo tanto, la infraestructura debe incluir recuperación, archivos de instrucciones, base de conocimientos, incrustación cuando sea necesario, pero también limpieza. Necesitamos una cultura de la memoria: qué entra, quién lo aprueba, cuándo decae, cómo lo corrijo.

La sexta pieza: observabilidad, evaluación y repetición.

Si un agente comete un error, el registro "llamado modelo" no es suficiente.

Quieres ver la ruta. ¿Qué contexto recibió? ¿Qué herramientas estaban disponibles? ¿Qué herramienta elegiste? ¿Con qué argumentos? ¿Qué respuesta obtuviste? ¿Cuánto costó? ¿Dónde se quedó atascado? ¿El humano aprobó algo? ¿Es el modelo de error, la herramienta, el mensaje, los datos o el error de permiso?

Aquí los agentes se parecen más a sistemas distribuidos que a chatbots.

Necesita rastros legibles, no sólo registros de texto. Necesitas poder repetir una carrera. Es necesario comparar dos versiones del mismo agente en tareas conocidas. Necesitamos medir las regresiones: no sólo "responde mejor", sino que "cierra el ticket correcto sin tocar archivos no solicitados".

Las evaluaciones agentes son más difíciles que las evaluaciones de texto porque incluyen acciones. No basta con comparar una cadena esperada. Hay que tener en cuenta las secuencias, los efectos secundarios, la calidad del artefacto, el tiempo, el coste y el número de intervenciones humanas.

Lo curioso es que siempre volvemos a eso: la ingeniería de software. Pruebas, entornos, rastreos, rollbacks. Excepto que el código ahora también decide qué hacer a continuación.

La séptima pieza: interfaces humanas

El agente no tiene por qué vivir simplemente en un chat.

Algunos agentes necesitan una junta. Otros una página con estado y registro. Otros de un botón de “aprobar”. Más comentarios en línea. Otros más de una CLI.

La interfaz de usuario cambia de comportamiento. Si la única forma de controlar a un agente es escribir un mensaje largo, el usuario le dará instrucciones vagas al agente. Sin embargo, si ve el plan, las diferencias, las fuentes, los riesgos y las próximas acciones, podrá intervenir con precisión.

Una infraestructura de agente decente incluye superficies de control:

estado actual;
plano editable;
artefactos producidos;
diferencia;
solicitudes de aprobación;
cronología;
botón de parada;
botón de reintento;
permisos visibles.

Parece trivial, pero no lo es. La diferencia entre una "IA espeluznante" y un "asistente confiable" suele ser que este último te muestra dónde tiene sus manos.

La pila mental

Si lo sacara hoy, la pila mínima de agentes sería la siguiente:

Modelo: razonamiento, generación, llamada de herramientas, multimodal si es necesario.
Orquestación: bucle, paso, planificador, política, ser humano en el circuito.
Tiempo de ejecución duradero: flujo de trabajo, cola, reintento, pausa, reanudación.
Sandbox: ejecución de código, sistema de archivos aislado, limitaciones, artefactos.
Capa de herramientas: MCP, API interna, navegador, base de datos, repositorio.
Capa de identidad: OAuth, alcance, secreto, auditoría, política.
Capa de memoria: contexto del proyecto, recuperación, instrucciones, caducidad.
Observabilidad: métricas de seguimiento, reproducción, evaluación, costes y calidad.
Superficie del producto: chatee cuando sea suficiente, panel cuando sea necesario, revise cuando sea importante.

El marco agente cubre principalmente el punto 2 y una parte del punto 1. El resto es el trabajo real.

Lo que haría en la práctica

Si un equipo me dijera "queremos agentes en producción", no comenzaría con diez agentes.

Comenzaría con un flujo de trabajo pequeño, repetitivo y observable. Por ejemplo: abrir relaciones públicas de mantenimiento, actualizar la documentación de problemas cerrados, preparar una revisión semanal, clasificar errores duplicados, generar pruebas para los archivos afectados.

Entonces yo pondría límites muy claros:

no se puede escribir sin ramas o sandbox;
no hay secretos en el mensaje;
herramientas en la lista de permitidos;
aprobación humana de acciones externas;
registro y seguimiento obligatorios;
presupuesto por ejecución;
salida siempre inspeccionable.

Sólo entonces me expandiría.

Los agentes no fracasan sólo porque los modelos se equivocan. Fracasan porque los ponemos en ambientes vagos, con permisos confusos y expectativas teatrales.

Mi lectura

La infraestructura agente es aburrida en el mejor de los sentidos.

No es la parte que te hace aplaudir en la demostración. Es la parte que te permite usar la demostración el lunes por la mañana, con personas reales, datos reales y consecuencias reales.

El futuro de los agentes no lo decidirá únicamente quién tenga el mejor modelo a seguir. Lo decidirá quien construya el mejor lugar para hacerlo trabajar: aislado cuando experimente, conectado cuando sea necesario, siempre observable, autorizado con criterio y humilde para detenerse cuando no sabe.

Ahí es donde los agentes dejan de ser un juguete y se convierten en infraestructura.

Fuentes