CCDV-F · Agentes y flujos de trabajo
Workflow o agente, si los pasos son fijos el camino va en código
Un equipo armó un agente para dar de alta reclamos: validar los datos, consultar la póliza, calcular el monto y generar la carta. Son siempre los mismos cuatro pasos, en el mismo orden. Aun así, de vez en cuando el agente saltea la validación o calcula antes de consultar. Le agregaron “SIEMPRE EN ESTE ORDEN” al prompt y siguió pasando. El problema no es el prompt: le dieron al modelo una decisión que nunca tuvo que tomar.
La diferencia en una línea
- En un flujo fijo (workflow), tu código decide el camino: qué paso va, en qué orden y con qué controles entre uno y otro. Claude resuelve las partes que necesitan lenguaje.
- En un agente (agent), el modelo decide el camino: elige la próxima herramienta según lo que fue apareciendo, hasta cumplir el objetivo.
El agente gana flexibilidad y paga en costo, latencia, previsibilidad y facilidad para auditar. Por eso la regla es empezar por lo más simple que funcione: una sola llamada bien armada, después un workflow, y un agente recién cuando el problema lo pide.
Cómo elegir
| Pregunta | Si la respuesta es sí |
|---|---|
| ¿Los pasos y su orden se conocen de antemano? | Workflow |
| ¿Hace falta garantizar un orden o un control (validar antes de calcular)? | Workflow, con el control en código |
| ¿La cantidad y el orden de los pasos dependen de lo que revelan los pasos anteriores? | Agente |
| ¿El modelo tiene que elegir la próxima herramienta según resultados intermedios? | Agente |
| ¿Hay que auditar exactamente qué se hizo y por qué? | Workflow, o un agente con hooks que registran todo |
Un caso mixto es muy común: un workflow fijo donde uno de los pasos es un agente acotado. Por ejemplo, el alta del reclamo es fija, pero “buscar antecedentes del asegurado” puede ser un pequeño agente con dos herramientas de solo lectura y un tope de iteraciones.
Los patrones de workflow
Conviene reconocerlos por nombre, porque las opciones del examen los describen:
- Encadenamiento de prompts (prompt chaining): la tarea se parte en llamadas sucesivas y cada una usa la salida de la anterior, con chequeos en código entre medio. Sirve cuando la tarea se divide limpio en subtareas fijas (extraer, después resumir, después traducir).
- Enrutamiento (routing): una primera llamada clasifica la entrada y el código la manda a un camino especializado. Sirve para categorías distintas que se atienden mejor por separado, incluso con modelos distintos (las consultas simples a Haiku, las difíciles a un modelo más capaz).
- Paralelización (parallelization): varias llamadas a la vez, ya sea partes independientes de la tarea o la misma tarea varias veces para comparar resultados.
- Evaluador-optimizador (evaluator-optimizer): una llamada genera, otra evalúa contra criterios claros y devuelve correcciones, en un ciclo con tope. Sirve cuando hay criterios explícitos y la iteración mejora el resultado de forma medible.
- Orquestador y trabajadores (orchestrator-workers): un modelo decide en el momento cómo partir la tarea y delega las partes. Ya está a mitad de camino hacia un agente; lo vemos en la lección de supervisor y subagentes.
Las trampas típicas
- Armar un agente autónomo para un proceso de pasos fijos “porque es más moderno”.
- Corregir un agente que saltea pasos con mayúsculas en el prompt, en lugar de llevar el orden al código.
- Pensar que un workflow no usa Claude: lo usa en cada paso, solo que no le deja elegir el camino.
- Descartar el agente cuando el camino realmente no se puede prever, como en una investigación abierta o en un arreglo de código que toca archivos desconocidos.
- Agregar un framework o más agentes sin un problema concreto que lo justifique.
En el examen
Buscá en el escenario si los pasos son siempre los mismos. Si lo son y algo “a veces se saltea o se desordena”, la respuesta es pasar a un workflow en código con controles entre pasos, no reforzar el prompt ni cambiar de modelo. Si la pregunta pide señales que justifican un agente, elegí las que hablan de pasos imprevisibles y de elegir la próxima herramienta según resultados intermedios. Si el escenario describe una tarea que se divide en partes fijas, buscá el patrón de workflow que encaja por nombre.
Pregunta rápida
Una pregunta del simulacro sobre este dominio. Cuenta para tu progreso.
A logistics team built its own tool loop on the Messages API for a warehouse assistant. It has four read-only tools, such as get_stock_level and get_inbound_shipments, and it often answers questions that need several lookups at once.
The harness takes only the first tool_use block from each response, runs it and sends back its tool_result. On questions that trigger several calls, the next request fails with a 400 error saying that tool_use ids were found without tool_result blocks. When it does work, users complain that multi-warehouse questions are slow, because each lookup takes about two seconds.
A teammate proposes retrying the 400 errors with backoff.
Which TWO changes should the team make? Select two.
Elegí todas las que correspondan.