Before giving a system more tools, decide which actions it should be allowed to take and when it should stop.
Describe the permitted work
Define the task in terms of actions and resources. An agent that prepares a purchase request does not necessarily need permission to place an order. Separate reading information, proposing a change, and carrying it out. Give each tool a narrow purpose and enforce permissions outside the model, where the application can check them consistently.
Design the stopping points
Decide what should happen when information is missing, a request falls outside scope, or a tool fails. Place practical limits on retries, execution time, and spending. A system should be able to return an incomplete result with an explanation. Continuing indefinitely is rarely a useful response to uncertainty.
Make actions inspectable
Keep an appropriate record of the tools called, their outcomes, and any approvals. Avoid collecting sensitive content merely because it is available. Give the people operating the system a way to understand what happened and to pause further actions. When a task involves multiple steps, make partial completion visible.
Test the awkward cases
Include interrupted tasks, repeated requests, conflicting instructions, and unexpected tool responses in evaluation. Check whether retrying an operation could repeat its effect. Increase autonomy only when the evidence supports the next level of responsibility and the people accountable for the workflow agree.
