Design the action boundary before designing the agent.

A product team wants an agent to respond to customer issues. It begins by listing tools: search accounts, create tickets, issue credits, send emails. The model can call all of them. Before the first prompt is written, the project has already made a risky architecture decision.

The decision behind the technology

Tool exposure is a permission contract. A model should not be given general write access simply because the workflow occasionally needs an adjustment. Tools need narrow scopes, server-side validation, rate constraints and explicit user or service identity.

A better way to frame the work

Design the state machine first. Determine what is read-only, what is draft, what requires review and what becomes committed. Use policy and validation outside the model. Each action should have an idempotency strategy and audit record.

Put the idea under realistic pressure

Test a malicious instruction embedded in a retrieved email asking for a credit to a different account. The model might still propose something incorrect; the backend must reject unauthorized action regardless. Then simulate an API timeout after a successful commit.

When the recommendation changes

Low-risk read-only assistants may need simpler orchestration. For consequential transactions, narrow permission sets and human gates are rational. Autonomous behavior should be earned with evaluation evidence.

What to decide before moving forward

Write the allowed actions matrix, approval states, retry semantics, rollback strategy and negative tests before building a multi-agent diagram.

References and context

OWASP LLM security guidance; Thoughtworks Radar Vol 35.