Agentic Workflows and Multi-Step Orchestration
It is a loop, not a call
Agentic systems wrap the Messages API in a loop: send state, inspect stop_reason, execute any requested tools and append results, repeat until end_turn or a termination condition. Every agent needs explicit termination: a maximum iteration count, a wall-clock or token budget, and a defined success predicate. Without these, a model that keeps probing a failing tool burns money indefinitely.
Design patterns
Orchestrator–worker splits a large job into scoped subtasks with fresh context windows; the orchestrator should receive compact summaries, not raw transcripts. Multi-agent designs win when subtasks are genuinely independent and lose when they are not, because coordination overhead and error compounding grow quickly. Prefer the simplest architecture that passes your evaluations.
Reliability habits
Make tools idempotent and side effects reversible - retries happen. Never trust agent-supplied arguments for authorization; validate against a policy layer outside the model. Surface errors as structured observations. Log every step with inputs, outputs, tokens, and latency; an agent you cannot trace is an agent you cannot debug.
Context pressure
Long loops accumulate tool output. Trim or summarize stale observations, keep the plan and current state near the end of the prompt, and drop raw payloads once distilled into facts.
Trap to watch
Assuming the model will stop on its own, or letting an agent's own tool call authorize an irreversible action.
Rule of thumb
Before adding a second agent, ask whether one loop with better tools, a clearer system prompt, and a stricter stopping rule would do the job. Usually it would.