An agent demo often starts with a simple promise: give a model tools and it will complete a task. The production question is harder: what is it allowed to change, how far may it go, and how will a person know what happened?
Those answers are product decisions, not prompt decoration. A reliable agent should have a deliberately small operating boundary that can be explained to the person using it and enforced by the software around it.
Start with the action, not the model
Write down the user outcome first. “Resolve a support request” is broad; “draft a response using the approved knowledge base” is bounded. The narrower task makes it easier to decide which context the system needs, which tools are appropriate, and what counts as completion.
Separate actions by their consequences:
- Read actions retrieve records, documentation, or status.
- Draft actions prepare a message, plan, or proposed change without applying it.
- Write actions change data, send messages, publish content, or trigger external work.
Do not let a broad tool blur these categories. A read-only lookup should not quietly gain a write capability because both actions happen to use the same service.
Put permissions in the application
Prompts can describe the rules, but the server must enforce them. Give each tool only the permissions it needs. Check the signed-in user, tenant, target record, and action scope on every request. Treat text retrieved from a document, web page, email, or tool as data—not as a new source of authority.
For consequential writes, return a proposed action that a person can inspect. Show the target, the intended change, and the information the decision depends on. Require a deliberate confirmation before applying it. Approval should be tied to the exact proposal; if the proposal changes, ask again.
This is especially important for actions with external effects, such as sending a customer email, issuing a refund, changing account access, or publishing a public update.
Bound the work
An agent can repeat a tool call, receive a partial result, or follow an unexpected branch. Give each task a maximum number of steps, a time limit, and a budget for model and tool usage. Validate tool arguments and results against schemas. Make write operations idempotent where possible, so a retry does not accidentally perform the same action twice.
When a limit is reached, stop clearly. Return the current state, the work completed, and the next safe option—such as asking the user to continue or handing the task to a teammate. A quiet loop is not persistence; it is an uncontrolled failure mode.
Make decisions observable
Keep an audit trail of the task, the tools invoked, the relevant inputs and outputs, the approval decision, and the final result. Avoid storing secrets or unnecessary personal data in logs. The record should help an operator answer a practical question: “What did the system do, and why?”
Evaluate the workflow on representative success cases and difficult cases: missing information, conflicting instructions, permission errors, unavailable tools, and duplicate requests. Track whether the system completes safely, asks for clarification when needed, and stops when it cannot proceed. A polished answer alone is not evidence that the underlying action was correct.
A useful production checklist
Before giving an agent a new capability, ask:
- Is the task specific enough to evaluate?
- Can the tool enforce the caller’s permissions independently of the model?
- Is this read, draft, or write behavior?
- Does a person need to approve it?
- Are retries safe, and are limits explicit?
- Can the team inspect a minimal, privacy-conscious audit trail?
The most useful agent is not the one with unrestricted access. It is the one that makes a narrow, valuable workflow easier while keeping the user in control of consequential decisions.
