Construyó un agente para procesar pedidos. Costó 100 veces más de lo necesario

Ana es desarrolladora en un e-commerce. Tenía un proceso que se repetía miles de veces al día: llega un pedido, hay que validar el pago, verificar el stock, reservar el producto, actualizar el inventario y notificar al cliente. Todo el mundo hablaba de agentes, así que construyó uno. Tres semanas después: costos disparados, comportamiento impredecible, debugging imposible. El problema no era el código, era que había usado un agente donde necesitaba un workflow. 👉🏽 Mira el video de youtube 💡 La señal estaba escrita en su propio prompt El prompt del agente de Ana decía, literalmente: “ Primero validá el pago. Después verificá el stock. Después reservá el producto. Después notificá al cliente .” Eso no es un agente. Es un workflow escrito en lenguaje natural. Cuando el prompt le dice al modelo exactamente qué hacer y en qué orden, el modelo no está tomando decisiones, está siguiendo instrucciones. Y para seguir instrucciones no necesitás un LLM, necesitás un motor de estados. La diferencia que importa ⚙️ Un workflow ejecuta pasos. Sabés de antemano qué va a pasar, en qué orden, y qué hacer si algo falla. Step Functions es el ejemplo perfecto: definís los estados y las transiciones, y AWS ejecuta eso con reintentos automáticos, timeouts e historial completo. 🤖 Un agente toma decisiones. No sabés de antemano qué va a hacer, evalúa la situación, elige herramientas, ajusta su comportamiento según los resultados. Y acá está la clave: el poder de un agente es su capacidad de razonar, y razonar tiene costo. Cada decisión llama a un LLM. Eso cuesta tokens, tarda, y puede comportarse distinto en cada ejecución. Si el proceso no necesita razonamiento, estás pagando ese costo sin ningún beneficio. 3 señales de que tenés un workflow disfrazado de agente 1️⃣ Siempre ejecuta los mismos pasos en el mismo orden. Si corrés el sistema diez veces con inputs similares y la secuencia nunca cambia, el modelo no está decidiendo nada. 2️⃣ El único trabajo del LLM es clasificar o extraer información en un paso. Eso es una función de Lambda que llama a Bedrock para una clasificación puntual, no un agente a cargo del flujo. 3️⃣ Podés escribir todos los pasos en un papel antes de ejecutar. Si el proceso ya está definido, no necesitás que el modelo lo descubra en tiempo de ejecución. El error contrario también existe Andrés tenía un chatbot de soporte técnico y armó un workflow con doce ramas de condiciones y los clientes seguían encontrando casos que no estaban mapeados. Estaba intentando resolver ambigüedad con un árbol de decisión, y la ambigüedad es exactamente el problema que resuelven los agentes. El patrón que uso en producción Los mejores sistemas no eligen entre uno u otro, usan los dos. Workflow como esqueleto, agente solo donde hay juicio real. En el caso de Ana bien resuelto: Step Functions sigue controlando todo el proceso: validar pago, verificar stock, reservar, notificar. Pero hay un paso específico, detectar fraude, que sí requiere interpretación y contexto. Ahí, y solo ahí, entra un agente. El workflow garantiza ejecución. El agente aporta inteligencia donde hace falta, no en todos lados. Resultado : costos -95%, 99.9% de ejecuciones exitosas, y trazabilidad completa de qué pasó en cada paso. 🚀 ¿Querés aprender a diseñar esto en AWS? Tengo un mini-curso gratuito de Agentes IA donde explico exactamente cuándo usar Bedrock Agents, cuándo usar Step Functions, y cómo combinar ambos con arquitecturas y código reales. 🎯 ACCEDER AL MINI-CURSO GRATUITO This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit desplegando.substack.com