Resumen de la publicación
La mayoría de las aplicaciones de LLM no necesitan un framework de agentes ni autonomía total: necesitan un flujo determinista bien hecho, donde el camino lo manda el código y el modelo razona solo dentro de cada paso. El hype empuja para el otro lado, pero la confiabilidad vive en lo aburrido.
Comparto cuándo alcanza con tool calling y structured outputs, cuándo conviene un agente de verdad y cómo no sobreingenierizar, con la regla simple que aplico antes de empezar cualquier proyecto: ¿el problema es abierto o ya sé más o menos cómo se resuelve?
Cada vez que arranca un curso o me siento a revisar un proyecto, aparece la misma pregunta con cara de obviedad: «¿qué framework de agentes usamos?». Y casi siempre mi respuesta arranca con otra pregunta: «¿estás seguro de que necesitás un agente?». No lo digo para hacerme el difícil. Lo digo porque vengo viendo, proyecto tras proyecto, que la mayoría de las apps de LLM se resuelven mejor con un flujo determinista bien armado que con autonomía total. El hype tira para el lado del agente que decide solo. La realidad, al menos la que toco todos los días con los alumnos del AI-First Builders Lab, tira para el lado de lo aburrido y confiable.
Agente no es lo mismo que app de IA
Primero pongamos las cosas en su lugar, porque el marketing mezcla todo. Un flujo determinista (workflow) es cuando vos, en código, definís los pasos y el orden: paso 1, paso 2, paso 3, y en cada uno el LLM hace su trabajo de razonar. Un agente de verdad es otra cosa: le das un objetivo y herramientas, y el modelo decide solo qué hacer, en qué orden y cuándo parar. La diferencia no es de tamaño, es de quién maneja el volante. En el workflow lo maneja tu código. En el agente lo maneja el modelo.
Shuai Guo lo planteó muy bien en un artículo de Towards Data Science que recomiendo leer entero. Su punto, que comparto al cien, es que la mayoría de los problemas del mundo real no son tan abiertos: en general ya sabemos más o menos cómo se resuelven. Y si ya sabés cómo se resuelve, ¿para qué le pedís a un modelo que lo descubra solo cada vez, con el costo, la latencia y la impredecibilidad que eso trae? Mejor le escribís el camino vos.
Lo que más valoro del flujo determinista
Cuando el camino lo maneja el código, ganás tres cosas que en producción valen oro. Transparencia: cada paso tiene un contrato claro de qué entra y qué sale, así que cuando algo falla sabés exactamente dónde. Modularidad: tocás un paso sin reescribir todo el sistema. Y control del flujo: el modelo sigue razonando libre adentro de cada nodo, pero el recorrido general lo manda tu código, no el azar de una decisión del LLM. Guo lo resume bien: el razonamiento puede variar dentro de un paso, pero el camino lo posee el código.
Te lo bajo a tierra con un caso típico. Pensá en una app que clasifica un mail entrante, extrae datos del cliente y arma una respuesta. Eso no necesita un agente que «decida qué hacer». Necesita tres pasos fijos: clasificar, extraer, redactar. Si lo armás como agente autónomo, le estás dando libertad para equivocarse en el orden, para llamar herramientas de más, para entrar en loops. Si lo armás como workflow, hacés cada paso con el LLM adentro y listo: predecible, debuggeable, barato. El agente, ahí, es sobreingeniería con onda.
Tool calling y structured outputs: el 80% de lo que creés que es «un agente»
Acá está la clave que pocos cuentan en criollo. Dos piezas te resuelven la enorme mayoría de los casos sin necesidad de autonomía total. La primera es el tool calling: el modelo no ejecuta nada, solo decide qué función llamar y con qué argumentos, y devuelve esa decisión como dato estructurado. La ejecución la hace tu código. Eso es importantísimo: el modelo propone, vos disponés. Esa separación entre «decidir» y «ejecutar» es lo que te deja meter validaciones, aprobaciones humanas y límites en el medio.
La segunda son los structured outputs, que también vienen en sabores según cuánta garantía necesités. El JSON mode te devuelve JSON válido pero sin garantía de esquema: sirve para prototipar o para cosas que va a leer un humano. El function calling te fija nombres y tipos de campos, ideal cuando vas a procesar la salida en un sistema más grande. Y los structured outputs estrictos (con decodificación restringida) te garantizan que cada campo del esquema aparece exactamente como lo definiste: eso es lo que querés cuando el dato alimenta un proceso crítico. La regla mental que uso: cuanta menos variabilidad podés tolerar, más rígido elegís.
Si combinás tool calling con structured outputs dentro de un flujo que vos controlás, ya tenés algo que parece un agente, se comporta de forma confiable y no se te va de las manos. Para el 80% de los proyectos que veo, ahí se termina la historia. No hace falta más.
¿Y cuándo sí conviene un agente de verdad?
No soy talibán anti-agentes, ojo. Hay casos donde la autonomía se justifica, y son los que cumplen una condición clara: el problema es genuinamente abierto. Cuando no existe un procedimiento conocido para resolverlo, cuando enumerar todos los caminos posibles es inviable, ahí sí tiene sentido darle libertad al modelo para que explore, planifique y decida. Una investigación profunda sobre un tema desconocido, un asistente que tiene que navegar situaciones que no podés anticipar de antemano: ese es territorio de agente.
Pero hasta ahí pagás un precio, y conviene saberlo antes: sacrificás confiabilidad y capacidad de debuggear. Por eso, cuando un proyecto sí necesita agentes, la confiabilidad no sale gratis. En un artículo muy bueno publicado en el sitio de Martin Fowler, Sarang Sanjay Kulkarni cuenta cómo un sistema agéntico de verdad confiable (el caso PRINCE, de un equipo de Bayer) se sostiene sobre dos disciplinas: context engineering —controlar qué información ve cada agente en cada etapa, en vez de tirarle todo junto— y harness engineering —el andamiaje de orquestación, reintentos, persistencia de estado y observabilidad alrededor del modelo—. Hablan de reintentos en varios niveles, de fallbacks de proveedor, de loops de reflexión explícitos. O sea: hacer agentes confiables es un laburo de ingeniería serio. No es bajar un framework y soltar el objetivo.
Mi receta para no sobreingenierizar
Lo que recomiendo, y lo que enseño, es empezar por lo más simple y subir de escalón solo cuando el problema te lo pide. Primer escalón: ¿lo resolvés con un prompt y structured output? Listo. Segundo: ¿necesitás que llame algunas herramientas en pasos que vos ordenás? Tool calling dentro de un workflow. Tercer escalón, recién ahí: ¿el problema es tan abierto que no podés escribir el camino? Bueno, ahora sí, agente, y preparate para invertir en harness y context engineering. Saltar directo al tercer escalón «porque está de moda» es la forma más rápida de terminar con un sistema caro, lento e impredecible que hace lo mismo que tres funciones en orden.
Un detalle más sobre frameworks, porque la pregunta del título es justo esa. Guo sugiere algo que me cierra: para prototipar, armá el workflow a mano y validá la idea rápido; adoptá un framework cuando pasás a producción y necesitás manejo de fallas, observabilidad y persistencia. El framework es una herramienta para cuando ya sabés qué estás construyendo, no un atajo para evitar pensar la arquitectura.
Si tuviera que dejarte una sola idea: la autonomía es una herramienta, no un trofeo. El mérito no es que tu sistema «sea un agente»; el mérito es que resuelva el problema de forma confiable, barata y mantenible. Y para la mayoría de los problemas, eso es un flujo determinista bien hecho. ¿Vos venís armando agentes autónomos o flujos deterministas? ¿Te pasó alguna vez tener que volver un agente para atrás porque era imposible de debuggear? Me encantaría leer tu experiencia en los comentarios.
Fuentes
- Towards Data Science — You Probably Don’t Need an Agent Framework (Shuai Guo)
- Towards Data Science — Tool Calling Explained: How AI Agents Decide What to Do Next
- Towards Data Science — Structured Outputs with LLMs: JSON Mode, Function Calling, and When to Use Each
- martinfowler.com — Building Reliable Agentic AI Systems (Sarang Sanjay Kulkarni)
