Choose a bounded workflow before giving an agent open-ended control

Start with a decision, not a framework

An agent is useful when choosing the next step is part of the problem. A workflow is useful when the steps are already known. Anthropic’s engineering guidance makes this architectural distinction; its older tooling examples should not be treated as current product instructions. OWASP separately warns about excessive functionality, permission and autonomy. Those principles support a simple design question: which decisions must the system make, and which can ordinary application code settle more predictably?

This guide offers a design exercise, not a tested provider implementation. Use it before selecting libraries or connecting private systems. Its output should be a short contract that another person can inspect. If the contract remains unclear, broader autonomy is unlikely to make the underlying process clearer.

Write the smallest useful outcome

Choose one real task. For an editorial assistant, the outcome might be a draft brief containing three verified source links and a list of unresolved claims. Avoid goals such as handle all research, which hide several responsibilities. Name the person who accepts the result and explain what would cause rejection. A useful acceptance rule identifies a property of the work rather than asking whether it looks impressive.

Next, list inputs the task may use. A source page is evidence to analyze, not an instruction to change the system’s objective. A colleague’s comment may be useful context without authorizing an external message. Represent those differences explicitly in the application. Otherwise the agent may encounter several voices that appear equally entitled to direct it.

Separate predictable steps from uncertain choices

Some operations have clear rules: validate a URL, check a required field, compare a timestamp or ensure a topic belongs to an allowed list. Keep those operations deterministic. Use a model where interpretation is actually needed, such as identifying conflicting descriptions of an event. This gives the system fewer opportunities to improvise and makes failures easier to locate.

Suppose a brief requires recent sources. Code can reject dates outside the window, while the agent explains whether a page reports a new event or merely updates an old story. The two checks answer different questions. Do not ask the model to replace a mechanical boundary that the surrounding system can enforce directly.

Give each tool a narrow contract

A research tool can return a title, URL, publication date and selected evidence. It does not need a hidden ability to delete content or send messages. A draft-writing tool should operate in a scoped workspace. The application should check authorization on every consequential request, even when the agent says the user approved it. A convincing explanation cannot substitute for the actual permission boundary.

For a pilot, use synthetic or approved public data. Keep external publication and customer communication behind a separate action. Show the proposed change and its destination at the decision point. Where the task is already authorized, preserve that scope so routine work does not repeatedly ask the user to approve the same harmless step.

Plan the stop and the recovery

Define a retry limit, a time budget and a maximum acceptable spend. Also define semantic stop conditions: contradictory requirements, unavailable evidence or a requested action outside scope. The result should say what was completed and what remains unresolved. A partial artifact can be useful if its limits are visible.

Preserve enough state to resume without repeating external actions. A retry after a network timeout should not publish a second article or send a second message. Use application-level identifiers and check whether the intended change already exists. Keep a human-readable record of the latest accepted instruction and the resulting artifact.

Review before expanding

Run the pilot against routine and difficult examples. Inspect unauthorized-action attempts, missing evidence and recovery behavior separately from answer quality. Increase scope only when there is a concrete reason and someone owns the new failure modes. The right outcome may be a fixed workflow with one model-assisted step rather than an open-ended agent. That is a successful design if it reliably solves the actual problem.

Sources

• Building effective agents — 2024-12-19
• OWASP excessive-agency guidance — living documentation; accessed 16 October 2026