Idea en 30 segundos
Single-Step Agents se vuelve un anti-pattern cuando un solo paso se usa para tareas con tools, side effects o ambigüedad.
Como resultado, no hay espacio para validación, recovery ni parada controlada. Para tareas con tools o side effects (cambios de estado), esto se vuelve frágil rápidamente en producción.
Para casos read-only seguros, single-step puede estar bien, pero para tareas con tools o side effects necesitas un bounded loop con stop_reason explícito.
Ejemplo del anti-pattern
El equipo construye un agente de soporte que debe buscar datos y ejecutar acciones en sistemas externos.
Pero la implementación hace solo un paso: una decisión de acción y una ejecución.
decision = agent.decide(user_message)
result = run_tool(decision.tool, decision.args)
return result
En este esquema no hay reevaluación después del tool-result:
# no hay validate_output(...)
# no hay no_progress(...)
# no hay stop_reason
Para este caso se necesita un loop controlado con límites:
for step in range(MAX_STEPS):
decision = agent.next_step(state)
...
En este caso, el enfoque single-step agrega:
- riesgo temprano de acción equivocada
- ausencia de recovery tras error de tool
- control débil de calidad de la respuesta final
Por qué aparece y qué sale mal
Este anti-pattern aparece cuando el equipo optimiza "para que sea más simple" y reduce el sistema de agentes a una sola llamada al modelo.
Causas típicas:
- deseo de bajar la latency a cualquier costo
- confusión entre "single LLM call" y un "agente completo"
- ausencia de requisitos para stop reasons y validación de output
- esperanza de que el prompt por sí solo cubra escenarios de recovery
Como resultado aparecen problemas:
- no hay recovery-loop - tras un error de tool, el agente no tiene cómo continuar
- riesgo de write prematuro - un side effect puede ocurrir antes de validar
- output frágil - no existe etapa para verificar "si la tarea realmente se cerró"
- debug difícil - el run termina sin razón transparente
- inestabilidad en producción - un paso fallido se convierte de inmediato en incidente
A diferencia de No Stop Conditions, aquí ni siquiera hay loop controlado: el problema empieza antes, en el diseño "un paso y terminar".
Señales típicas de producción de que single-step ya es peligroso:
- tareas con tools y side effects corren sin
max_steps/stop_reason - un tool-call fallido termina el run de inmediato sin intentos de recovery seguro
- un error de routing dispara una acción externa sin validación adicional
- el equipo no puede explicar por qué se eligió exactamente esa acción en ese run
Es importante que cada paso del agente forma parte de la LLM inference. En un diseño single-step, en la práctica dejas que una sola inference tome una decisión crítica sin verificación.
Enfoque correcto
Empieza con un bounded loop mínimo para todos los escenarios con tools o side effects. Deja single-step solo para casos read-only realmente seguros, low-risk y sin tool-call.
Marco práctico:
- separa rutas:
read_only_single_stepyloop_required - para la ruta loop define
max_steps,timeout,stop_reason - agrega verificaciones
validate_outputyno_progress - ejecuta acciones de write solo después de verificaciones policy explícitas
MAX_STEPS = 6
def run_support_flow(user_message: str):
route = classify_intent(user_message) # simple classifier or rules
if route == "read_only_faq":
return run_single_step_answer(user_message) # no tools, no side effects
state = init_state(user_message)
for step in range(MAX_STEPS): # hard limit for unsafe loops
decision = agent.next_step(state)
if decision.type == "final_answer":
if validate_output(decision.output): # format and required fields
return decision.output
return stop("invalid_output")
result = run_tool(decision.tool, decision.args)
if no_progress(state, result): # repeated pattern or no meaningful state change
return stop("no_progress")
state.append(result)
return stop("max_steps_exceeded")
En este esquema, los riesgos se vuelven manejables: el sistema cierra la tarea o se detiene con una razón transparente.
Prueba rápida
Si respondes "sí" a estas preguntas, tienes riesgo de anti-pattern Single-Step Agents:
- ¿Las tareas con tools y side effects se ejecutan en un solo model call?
- ¿Tras un tool-result fallido el run termina sin paso de recovery?
- ¿No hay
stop_reasonexplícito cuando el escenario no se cierra correctamente?
Cómo se diferencia de otros anti-patterns
Agent Everywhere Problem vs Single-Step Agents
| Agent Everywhere Problem | Single-Step Agents |
|---|---|
| Problema principal: se usa un agente incluso para tareas deterministas. | Problema principal: incluso cuando el agente sí se necesita, se ejecuta en un paso sin loop. |
| Cuándo aparece: cuando un workflow simple se reemplaza por agent reasoning. | Cuándo aparece: cuando tareas con tools/write se ejecutan sin recovery ni lógica de parada. |
En resumen: Agent Everywhere Problem trata de elegir agente sin necesidad, mientras que Single-Step Agents trata de una forma insegura de ejecutar el agente.
No Stop Conditions vs Single-Step Agents
| No Stop Conditions | Single-Step Agents |
|---|---|
| Problema principal: hay loop, pero no condiciones claras de finalización. | Problema principal: no hay loop como tal, por eso no hay espacio para recovery controlado. |
| Cuándo aparece: cuando un run entra en repeticiones infinitas o muy largas. | Cuándo aparece: cuando un paso incorrecto termina de inmediato el escenario o dispara una acción no deseada. |
En resumen: No Stop Conditions trata de un loop no controlado, mientras que Single-Step Agents trata de ausencia de loop donde sí hace falta.
Tool Calling for Everything vs Single-Step Agents
| Tool Calling for Everything | Single-Step Agents |
|---|---|
| Problema principal: tool-calls innecesarios incluso en escenarios simples. | Problema principal: un tool-call crítico se ejecuta en un paso sin validar el resultado. |
| Cuándo aparece: cuando tool-call se vuelve la ruta por defecto. | Cuándo aparece: cuando después del tool-result no existe loop para validar o corregir. |
En resumen: Tool Calling for Everything aumenta la cantidad de llamadas innecesarias, y Single-Step Agents aumenta el riesgo de una llamada crítica no controlada.
Autoevaluación: ¿tienes este anti-pattern?
Chequeo rápido del anti-pattern Single-Step Agents.
Marca los puntos para tu sistema y revisa el estado abajo.
Revisa tu sistema:
Progreso: 0/8
⚠ Hay señales de este anti-patrón
Intenta mover los pasos simples a un workflow y dejar el agente solo para decisiones complejas.
FAQ
Q: ¿El enfoque single-step siempre es malo?
A: No. Encaja en escenarios read-only seguros sin tools ni side effects. El problema aparece cuando se aplica a tareas que requieren recovery y control.
Q: ¿Cómo saber que hay que pasar a loop?
A: Si hay tool-calls, acciones externas, output ambiguo o riesgo de fallo con alto impacto, necesitas un bounded loop con stop_reason explícito.
Q: ¿Sube mucho la latency al pasar a loop?
A: Puede subir, pero se controla con budget limits. En producción suele importar más un resultado controlado y seguro que "rápido pero frágil".
Qué sigue
Anti-patterns relacionados:
- Agent Everywhere Problem - cuando se agrega agente donde un workflow es suficiente.
- No Stop Conditions - cuando hay loop, pero sin parada controlada.
- Tool Calling for Everything - cuando se llaman tools sin necesidad explícita.
Qué construir en su lugar:
- Stop Conditions - cómo definir condiciones de finalización para un run controlado.
- Routing Agent - cómo separar rutas read-only y side-effecting.
- Tool Execution Layer - cómo ejecutar tool-calls de forma segura mediante policy y límites.