Una llamada individual a un LLM tiene una carga operativa relativamente pequeña. La aplicación envía un prompt, espera la respuesta y usa el resultado o reintenta la solicitud. La mayor parte del estado y del manejo de fallos sigue estando en el código alrededor del modelo, no en la llamada en sí.
En un flujo de trabajo agéntico, la dinámica cambia. En lugar de una única solicitud y respuesta, el modelo evalúa qué hacer, llama a una herramienta, lee el resultado y decide el siguiente paso. A veces repite este proceso varias veces antes de llegar a una respuesta final. Cada paso puede fallar de forma independiente y necesita registrar lo que ya sucedió.
Muchos equipos no se preparan para esa transición. Crean un prototipo basado en una API, todo funciona, hasta que alguien pregunta: ¿también puede consultar la base de datos, llamar a otras dos APIs y recordar lo que pasó en la última interacción? Es en ese momento cuando un chatbot deja de ser solo una demostración y se convierte en un problema de sistemas distribuidos.
Esta guía explica qué cambia en la infraestructura al pasar de llamadas individuales a LLM a flujos de trabajo agénticos y cómo diseñar esa arquitectura para producción.
Qué cambia cuando un flujo de trabajo se vuelve agéntico
Un flujo de trabajo agéntico generalmente agrega requisitos que una llamada individual no tiene:
- Estado entre pasos: el agente necesita saber qué ya hizo y qué resultados recibió antes de decidir la siguiente acción.
- Orquestación en múltiples pasos: en lugar de una única solicitud y respuesta, hay un ciclo que evalúa, actúa, observa y repite hasta alcanzar una condición de parada.
- Llamadas a herramientas y acceso a datos: el agente consulta APIs, bases de datos o vector stores durante la ejecución, y cada llamada es un nuevo punto de fallo.
- Ejecuciones más largas: un flujo de trabajo puede durar segundos o minutos y atravesar varias solicitudes, en lugar de terminar después de una única llamada.
Las aplicaciones distribuidas han lidiado con estos problemas durante años, independientemente de la AI: dónde mantener el estado, cómo reducir la latencia entre servicios y cómo responder cuando un paso falla. La AI agéntica agrega un LLM como un componente más de esa cadena.
Por qué los prototipos de agentes fallan en producción
Un prototipo que llama a un solo endpoint de modelo puede parecer rápido. Pero la latencia empieza a acumularse cuando el agente llama al modelo, luego a una herramienta, vuelve al modelo y consulta una base de datos, especialmente si cada paso necesita acceder a una región centralizada.
El contexto de la sesión, el historial de la conversación y los resultados intermedios frecuentemente terminan dispersos entre variables globales, cachés locales o componentes improvisados. En algunos casos, ni siquiera se persisten, haciendo que el agente pierda el contexto entre llamadas.
Ejecutar inferencia de forma confiable y a escala también exige aprovisionar, escalar y monitorear capacidad de GPU, lo que crea un segundo proyecto para equipos que deberían estar enfocados en la aplicación.
Al mismo tiempo, las consultas de RAG, la recuperación de memoria y los datos de la aplicación suelen estar en servicios distintos, con perfiles de latencia diferentes. Al final, todo el flujo de trabajo opera a la velocidad de su paso más lento.
Estos problemas rara vez aparecen en una demostración con un solo usuario y sin carga. Surgen cuando el flujo de trabajo empieza a recibir tráfico real.
Las cinco capas de infraestructura de un flujo de trabajo agéntico
Un agente en producción normalmente depende de cinco capas:
- Orquestación: el flujo de control que decide el siguiente paso, como llamar al modelo, ejecutar una herramienta, consultar la memoria o finalizar el flujo de trabajo.
- Inferencia: las llamadas a los modelos, incluyendo chat completions, embeddings y reranking.
- Estado de trabajo: datos temporales usados entre los pasos, como el turno actual de la conversación, contadores, flags y resultados intermedios.
- Memoria persistente y semántica: datos estructurados de mayor duración y contexto consultable por vectores, usados en recuperación de información y RAG.
- Políticas y control de acceso: reglas que determinan qué puede hacer el agente, qué herramientas puede llamar y con qué permisos.
Los problemas en producción suelen surgir en los límites entre estas capas: estado desactualizado, recuperación lenta, fallos en tool calls, permisos faltantes o ciclos de orquestación que nunca alcanzan una condición de parada.
Cómo funcionan estas capas en Azion
En Azion Platform, estas capas pueden operar en el mismo modelo distribuido, sin necesitar cinco sistemas gestionados por separado.
Azion Functions ejecuta la orquestación: el ciclo que determina el siguiente paso del agente. Los pasos se procesan dentro de una única invocación, sin cold start, y la siguiente llamada tampoco paga un nuevo costo de inicialización.
Azion AI Inference ejecuta la capa de modelos. El servicio ofrece soporte para LLMs, VLMs, embeddings, reranking y flujos de trabajo agénticos mediante una API compatible con OpenAI, con escalado automático desde la primera solicitud hasta los picos de tráfico, sin que el equipo necesite aprovisionar clústeres de GPU.
Azion KV Store mantiene el estado de trabajo, incluyendo contexto de sesión, contadores, flags y resultados intermedios que el ciclo necesita acceder entre pasos, con baja latencia cerca de donde se ejecutan las Functions.
Azion SQL Database almacena la memoria persistente y semántica. Con búsqueda vectorial basada en SQLite y libSQL, las consultas de RAG y la memoria de largo plazo pueden usar la misma capa de datos que el resto de la aplicación. Las réplicas globales de lectura mantienen esas consultas más cerca de los usuarios.
Las políticas y el control de acceso quedan en la capa de orquestación. La siguiente sección detalla cómo funciona esto en la práctica. Mantener orquestación, inferencia y estado en la misma plataforma distribuida reduce la latencia adicional y el esfuerzo operativo de coordinar servicios gestionados por separado.
Ejemplo de ciclo para un agente de AI
El siguiente pseudocódigo representa un ciclo simplificado en una Azion Function. El endpoint, el ID del modelo y los métodos de KV Store son ilustrativos; consulta la documentación actual de Azion antes de usar el ejemplo en producción.
Se omitieron detalles de carga de secrets, reintentos y manejo completo de errores para dejar más claro el flujo de control.
// Pseudocódigo ilustrativo. El endpoint, el ID del modelo y los métodos de// KV Store son placeholders. Consulta la documentación para la sintaxis actual.export default async function handler(request) { const { sessionId, message } = await request.json();
// Historial de la conversación: persiste entre interacciones. const history = JSON.parse((await KV.get(`session:${sessionId}`)) || "[]"); history.push({ role: "user", content: message });
// Memoria semántica: recuperada en cada interacción mediante búsqueda vectorial. const memory = await queryVectorMemory(message);
// Mensajes de trabajo: historial y contexto recuperado para esta ejecución. // Las tool calls quedan en `messages`, pero no se guardan en `history`, evitando // que la memoria persistente crezca con cada paso intermedio. const messages = [{ role: "system", content: memory }, ...history];
const MAX_STEPS = 4; let finalMessage = null;
for (let step = 0; step < MAX_STEPS; step++) { const completion = await fetch( "https://<tu-endpoint-de-ai-inference>/v1/chat/completions", { method: "POST", headers: { "Content-Type": "application/json", Authorization: `Bearer ${AI_INFERENCE_TOKEN}`, }, body: JSON.stringify({ model: "<id-de-tu-modelo>", messages, tools: [checkOrderStatusTool, searchDocsTool], }), } ).then((response) => response.json());
const assistantMessage = completion.choices[0].message; messages.push(assistantMessage);
if (!assistantMessage.tool_calls?.length) { finalMessage = assistantMessage; break; }
// Las tool calls devueltas en el mismo mensaje pueden ejecutarse en paralelo. const results = await Promise.all( assistantMessage.tool_calls.map((call) => runAuthorizedTool(call, sessionId) ) );
assistantMessage.tool_calls.forEach((call, index) => { messages.push({ role: "tool", tool_call_id: call.id, content: typeof results[index] === "string" ? results[index] : JSON.stringify(results[index]), }); }); }
// Si el agente alcanza el límite de pasos, finaliza de forma segura. if (!finalMessage) { finalMessage = { role: "assistant", content: "No fue posible completar la solicitud. Intenta de nuevo.", }; }
history.push(finalMessage); await KV.put(`session:${sessionId}`, JSON.stringify(history), { ttl: 3600 });
return new Response(JSON.stringify(finalMessage));}El ciclo sigue llamando al modelo hasta recibir un mensaje sin nuevas tool calls o hasta alcanzar el límite de pasos, lo que evita que el agente se ejecute indefinidamente. La función runAuthorizedTool no solo reenvía la llamada: es donde deben verificarse los permisos antes de la ejecución.
Mantener el historial de la sesión, la memoria recuperada y los resultados de las herramientas en la misma arquitectura distribuida reduce el overhead de red y de I/O entre los pasos. Esto no hace que cuatro llamadas al modelo sean tan rápidas como una, pero evita que el acceso al estado se convierta en otro cuello de botella del flujo de trabajo.
Permisos de herramientas y controles en tiempo de solicitud
La protección de entrada y la autorización de tool calls resuelven problemas distintos. Azion Firewall y su Rules Engine, junto con el módulo Web Application Firewall (WAF), inspeccionan las solicitudes antes de que lleguen al agente, pero no controlan automáticamente las herramientas que este llama durante la ejecución.
Esos controles pertenecen a la capa de orquestación. Los argumentos, los permisos del usuario y los límites de ejecución deben validarse antes de cada acción, como lo representa runAuthorizedTool en el ejemplo. Una decisión incorrecta dentro de un flujo de trabajo puede activar una acción real, por lo que cada tool call necesita límites explícitos.
Siguiente paso: descubre cómo Azion Functions, AI Inference, KV Store y SQL Database funcionan juntos en flujos de trabajo agénticos en la documentación de Azion o habla con un especialista sobre cómo llevar un agente del prototipo a producción.
Preguntas frecuentes
**¿Cuál es la diferencia entre una llamada individual a un LLM y un flujo de trabajo agéntico?**Una llamada individual a un LLM envía un prompt y recibe una respuesta en una única interacción. Un flujo de trabajo agéntico ejecuta un ciclo en el que el modelo decide una acción, llama a una herramienta o consulta datos, analiza el resultado y decide de nuevo hasta alcanzar una condición de parada. Ese ciclo es lo que introduce estado, orquestación en múltiples pasos y varios puntos de fallo que una llamada individual no tiene.
¿Qué tipos de estado necesita gestionar un flujo de trabajo agéntico? Como mínimo: historial de la conversación, memoria de trabajo, resultados de tool calls, estado persistente de la aplicación y memoria semántica. El historial y la memoria de trabajo suelen encajar en un almacenamiento key-value; el estado persistente y la memoria semántica generalmente requieren una base de datos con búsqueda vectorial.
¿Por qué un agente de AI necesita una capa de datos dedicada para la memoria? Cada acceso adicional por red agrega latencia, y un ciclo de agente puede realizar varias de estas operaciones durante una sola interacción. Mantener el estado de trabajo y la memoria persistente cerca de la orquestación evita acumular round trips hacia un servicio centralizado en cada paso.
**¿Es necesario gestionar infraestructura de GPU para ejecutar flujos de trabajo agénticos?**No, si la capa de inferencia ofrece escalado gestionado. Azion AI Inference ejecuta LLMs, VLMs, embeddings, reranking y flujos de trabajo agénticos mediante una API compatible con OpenAI, sin que el equipo necesite aprovisionar o monitorear clústeres de GPU directamente.
¿Un firewall impide que un agente ejecute acciones inseguras? Un WAF y un rules engine protegen la solicitud de entrada que activa la aplicación. No controlan automáticamente las tool calls que ejecuta el agente. La validación de argumentos y permisos debe aplicarse en el código de orquestación antes de cada acción.
¿Puedo usar esta arquitectura con un cliente compatible con la API de OpenAI? Sí. Azion AI Inference ofrece una API compatible con OpenAI, por lo que un cliente existente normalmente solo necesita el cambio de la URL base y las credenciales, sin requerir que se reescriba toda la integración.
