La forma más rápida de tirar a la basura un trimestre de ingeniería es construir un agente cuando hubiera bastado con un workflow. La forma más lenta de entregar algo útil es construir un workflow cuando el trabajo realmente pide un agente.
Hemos hecho los dos, y hemos hecho el equivocado. Esta es la forma de la pregunta que ahora hacemos antes de tocar una sola línea de código.
Los workflows son la opción por defecto
Un workflow es una serie de pasos con ramificación explícita. Tú escribes la lógica. El sistema la ejecuta igual cada vez. Cuando algo se rompe, puedes señalar la línea.
Si puedes describir el trabajo como un diagrama de flujo y el diagrama no es vergonzosamente grande, construye un workflow. Son más baratos de escribir, más baratos de debugear, y las personas que te reemplacen dentro de tres años te lo agradecerán.
La trampa es que "describible como diagrama de flujo" requiere honestidad real. Un diagrama con 47 ramas y cuatro casos por defecto que en realidad significan "preguntar a Sarah" no es un workflow — es un workflow intentando escaparse de su propia piel.
Los agentes son para juicio irreducible
Recurres a un agente cuando el trabajo tiene dos propiedades:
- El espacio de inputs es demasiado grande para enumerarlo de antemano.
- Hay una decisión de juicio dentro del bucle que no se comprime en reglas.
El soporte al cliente es el ejemplo clásico. Puedes escribir reglas para los noventa casos obvios. El otro diez por ciento es por lo que tu equipo está agotado. Un agente se gana su sitio en ese diez por ciento — y en el noventa aburrido, lo envuelves en un workflow.
El término medio que la gente se pierde
La mayoría de lo que construimos no es ni un workflow puro ni un agente puro. Es un workflow con un agente pequeño dentro de un paso: el paso que requiere juicio, recuperación, o reformulación.
Esa forma híbrida tiene dos ventajas enormes:
- La observabilidad sigue siendo razonable. Aún puedes señalar la línea donde se rompieron las cosas. El agente no está decidiendo qué hacer a continuación — está decidiendo una cosa específica dentro de un paso conocido.
- Puedes reemplazar el agente más tarde. Cuando el modelo mejore, o cuando tu juicio se comprima en reglas, intercambias el paso.
Si puedes partir el trabajo en un workflow donde el agente solo maneje uno o dos pasos, hazlo. El bucle de agente puro raramente es la respuesta correcta.
Las preguntas que hacemos primero
Cuando un equipo llega a nosotros, antes de sugerir cualquier cosa, repasamos:
- ¿Me puedes dar las reglas? Si sí, es un workflow. Si "bueno, depende de la situación" — estamos más cerca de necesitar un agente.
- ¿Cuál es el coste de una respuesta equivocada? Costes más altos significan más guardrails, más human-in-the-loop, forma más determinista.
- ¿Cada cuánto cambia el trabajo? Reglas volátiles → agentes (generalizan). Reglas estables → workflows (son baratos de mantener).
- ¿Quién es el dueño cuando nos vayamos? Si el equipo no puede mantener un servicio en Python, no deberíamos construirles uno. La herramienta correcta es la que pueden hacer correr un martes por la mañana.
Una heurística útil
Si puedes imaginar un Notion que describa el proceso entero en menos de una página, es un workflow.
Si el proceso se sale constantemente del documento — si cada trimestre el equipo pregunta "espera, ¿seguimos haciéndolo así?" — hay un problema con forma de agente escondido dentro. Encuéntralo.