Agents need boundaries, not just tools

Giving a model access to tools changes the consequences of a mistake. A weak answer can confuse a reader; a weak decision connected to an action can modify a record or send a message. The design problem is no longer just whether the model understands the request. It is whether the surrounding system limits what an uncertain interpretation can do.

Start with the shape of the task

Some work has a known sequence: receive a document, extract fields, validate them, and present a draft. Other work requires choosing steps based on discoveries. Anthropic distinguishes predefined workflows from agents that dynamically direct their process. That distinction is useful before deciding how much freedom the system needs.

For a document-processing assistant, a fixed workflow may be easier to inspect and recover. If the assistant must research an unfamiliar repository, a more flexible loop may be justified. Flexibility should solve a real constraint, not merely make the architecture sound more advanced.

Separate preparation from commitment

Consider an assistant that helps organise photographs. Reading metadata and proposing album names are different operations from permanently deleting originals. The tool interface should preserve that distinction. A preview of the proposed change gives the person something concrete to approve.

Approval needs to be bound to the actual action and its target. A vague “continue?” is weak if the underlying files or proposed operation can change afterwards. Recheck the authorised scope at execution time. The model should not be the only component deciding whether a tool call is permitted; enforce constraints outside its generated text.

Make uncertainty visible

A tool timeout can leave the result unknown. Repeating a write immediately may duplicate an action that already succeeded. Return structured outcomes that distinguish a confirmed failure from an ambiguous result, and provide a read-only way to reconcile state where possible.

Likewise, define termination conditions. The system should stop when it succeeds, reaches its budget, requires approval, or encounters an unresolved blocker. “Keep trying” is not a complete recovery strategy. Preserve enough of the operation history to explain why the agent stopped without exposing unnecessary sensitive information.

Evaluate behaviour, not confidence

A confident completion message is not evidence that the intended change occurred. Test the resulting state and the path taken to reach it. Did the assistant stay inside the permitted scope? Did it ask before a consequential action? Did it report partial completion accurately?

Begin with read-only or reversible tasks and deliberately exercise failure cases before widening authority. A good agent interface makes capability and limitation legible. The impressive part is not how many tools the model can call; it is how reliably the system turns an intention into an appropriate, verifiable outcome.

Further reading: Anthropic: Building effective agents.