Distinguish workflows from agents
Anthropic's engineering guide distinguishes predefined workflows from systems in which a model dynamically chooses its process and tool use. This is a useful design vocabulary, not a requirement to make every assistant autonomous. More flexible orchestration introduces more decisions to evaluate.
A fixed sequence can be the right product. If a request always requires collecting fields, validating them, and generating a draft, ordinary application code can control the sequence. An agent becomes interesting when the next useful step genuinely depends on what it discovers.
Technical foundation: Anthropic: Building effective agents
Start with one bounded job
Consider a documentation maintenance assistant. It might inspect a changed API, find affected pages, and propose edits. Discovery can vary, making an agent loop useful. Publishing those edits is a separate action with a different permission boundary. Keep the first version limited to a reviewable proposal.
Define its inputs, allowed tools, maximum work budget, and completion evidence. A report saying everything is done is not enough. Require the changed files, unresolved questions, and the checks performed. The system should distinguish a completed task from a partial result that needs a human decision.
Build the loop around application state
A practical loop observes the current state, proposes an allowed action, executes it through a controlled tool, and evaluates the result. Persist important progress outside the conversational transcript. If execution is interrupted, the application should know which operations completed and which remain uncertain.
Set limits on repeated actions, elapsed time, and resource use. Detect identical failures and return a useful blocked state instead of requesting the same operation indefinitely. A retry may be appropriate for a transient timeout; it is not a remedy for a missing permission.
Make authority visible
Read access, editing a local draft, sending a message, and deploying a release are different powers. Show users what the agent can do and request approval when the task crosses a meaningful boundary. Authorization must be checked by the tool implementation, not inferred from the model's confident wording.
Evaluate difficult interruptions: a tool returns incomplete data, an external page contains hostile instructions, or a user changes the objective halfway through. Useful autonomy includes knowing when to stop. A bounded agent that hands back clear evidence can be more valuable than one that continues without a reliable finish condition.
Before enabling autonomous steps
- Explain why a fixed workflow is insufficient.
- Separate discovery and drafting from consequential execution.
- Persist operation status and define a restart strategy.
- Set time, step, and usage limits with explicit stop states.
- Test denied actions and malicious tool content.
