# Design the action boundary before designing the agent.

> Good agent systems know which tools are available, what permissions apply and when a human must approve.

Canonical URL: https://marmation.com/review/designing-an-agent-with-bounded-actions/

By Vikram Roy · 2026-11-12

An AI agent is software that can request actions through connected tools. In customer service, that might mean reading an account or proposing a credit. The business must decide which of those powers it is delegating before the model is allowed to use them.

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.

## Giving a tool is granting a permission

Giving an agent a tool grants it a route to read information or request a change. That access 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, checks enforced by the application’s server, limits on action frequency and an explicit user or service identity.

## Define the stages before connecting the actions

Design the state machine first: the named stages a task can enter and the rules for moving between them. Determine what can only be read, what remains a draft, what requires review and when a change is actually saved. Use policy and validation outside the model. Each action needs an idempotency strategy, so repeating a request does not repeat the business change, and an audit record of what happened.

## Try the wrong account and the uncertain payment

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 a connected service saving a change but failing to return confirmation. Check that trying again cannot create a second credit.

## Give low-risk tasks lighter controls

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.

## Write the action rules before the agent plan

Write down who may take each action, when approval is required, how the system checks an uncertain result before trying again, how to reverse a change and which forbidden actions the tests must reject. Establish these rules before planning several cooperating agents.

### References and context

[OWASP LLM security guidance](<https://owasp.org/www-project-top-10-for-large-language-model-applications/>); [Thoughtworks Radar Vol 35](<https://www.thoughtworks.com/radar>).

## Sources

- [Thoughtworks Technology Radar](<https://www.thoughtworks.com/radar>) — Thoughtworks. Original technical editorial research; exemplar of knowledge product. Example of original technical editorial content Limit: The Radar is an editorial reference. Its inclusion does not imply Marmation affiliation or comparable company scale.
- [Top 10 for LLM Applications](<https://owasp.org/www-project-top-10-for-large-language-model-applications/>) — OWASP. LLM risks such as prompt injection, excessive agency and data disclosures. Threat categories for LLM systems Limit: This is an engineering security reference, not evidence of an independent audit of Marmation or another system.

## Related reading

- [From working prototype to dependable system](https://marmation.com/review/engineering/)
- [Engineering autonomy is a control design problem.](https://marmation.com/review/engineering-autonomy-is-a-control-design/)
- [Fine-tuning, RAG or prompting: ask what needs to change.](https://marmation.com/review/fine-tuning-versus-rag-versus-prompting/)