Define Agent Boundaries Before Adding Tools

Start with one completed outcome

An agent is useful when it can move a task through several steps while remaining observable. Begin with one outcome such as "prepare a cited support brief for review," not "answer every support question." The narrower statement exposes the tools, information, and approvals the workflow truly needs.

Give tools explicit contracts

For every tool, document what the agent may read, write, or send. State the input shape, the expected output, rate limits, and failure behavior. A search tool may retrieve public pages; it should not silently publish a summary. A calendar tool may draft an event; it should request approval before creating it.

Practice: draw the stop points

Map the workflow as input, reasoning step, tool call, result, and handoff. Mark where the agent must stop because the result is uncertain, sensitive, irreversible, or expensive. Those stops are product requirements, not a sign that the agent failed.

Common mistake

Do not give an early agent broad credentials to compensate for missing design. More access can make a demo look capable while making a real workflow less safe and harder to debug.