Enterprise agents should be bounded by a small set of well-defined tools, run with the requesting user's permissions, and pause for human approval before any action with external consequences. Autonomy belongs in retrieval, planning and drafting, not in irreversible operations.
Tools are the design surface
An agent is only as safe as the tools it can call. Each tool should do one bounded thing, validate its own inputs, enforce permissions internally and be idempotent where possible. A tool that accepts a free-form query and executes it is an unbounded capability, regardless of how it is prompted.
Prefer narrow tools with typed parameters over general ones. Create a draft invoice for order X is safer and more reliable than run any SQL, because the first cannot be misused while the second cannot be constrained.
Return structured results rather than prose. Structured tool output lets the agent reason reliably and lets the platform record what happened for audit, whereas free text loses the distinction between the observation and the model's interpretation of it.
- One bounded purpose per tool with validated typed inputs.
- Enforce authorisation inside the tool, not in the prompt.
- Prefer idempotent tools so retries are safe.
- Return structured results that can be logged and audited.
Permissions and approval gates
An agent that runs as a privileged service account inherits all of that account's access and can be induced to use it. Every action must execute under the permissions of the user who invoked the agent, so the blast radius of a mistake equals the blast radius of that user acting directly.
Classify actions by reversibility. Reading, searching, summarising and drafting are safe to automate. Sending an email, posting a transaction, modifying a record or calling a third party are not, and require a confirmation step.
The approval gate must show the concrete action, not a summary. A reviewer approving what the agent proposes needs to see the recipient, the message, the amount and the record affected, and the approval must be recorded with the actor and timestamp.
| Action class | Example | Recommended autonomy |
|---|---|---|
| Read and retrieve | Search documents, fetch a record | Fully autonomous |
| Analyse and summarise | Explain a variance, summarise a thread | Fully autonomous with citations |
| Draft | Compose a reply, prepare an order | Autonomous, requires send approval |
| Propose a change | Suggest a reorder quantity | Requires explicit approval |
| Execute reversible | Create a draft record, tag a document | Autonomous with audit log |
| Execute irreversible | Post payment, send external email | Mandatory human approval |
| Bulk operation | Update many records | Approval plus dry-run preview |
Failure modes and observability
Agents fail in ways that conventional software does not: loops that repeat the same tool call, plans that drift from the objective, escalating cost without progress, and confident action on a misread state. Each needs an explicit control.
Set hard limits on steps, tool calls, wall-clock time and cost per invocation, and terminate with a clear outcome when a limit is reached. A bounded failure that routes to a human is far better than an unbounded run.
Record a complete trace of every step: the objective, each tool call with its inputs and outputs, the model's reasoning summary, latency, token cost and the final action. Traces are what make an agent debuggable and are also the evidence base for evaluation.
- Cap steps, tool calls, duration and cost per invocation.
- Detect and break repeated identical tool calls.
- Terminate gracefully and route to a human on limit breach.
- Record a full step trace with cost and latency.
Rollout and where the value is
Start with a narrow, high-volume task that has a clear success criterion and a natural human checkpoint, such as triaging inbound requests, preparing quotes from a catalogue or reconciling discrepancies in a queue. Measure time saved and error rate against the manual baseline.
Roll out behind a flag to a small group, review traces weekly and expand only when the error rate is acceptable and the human checkpoint is being used rather than rubber-stamped. An approval gate that everybody clicks through is not a control.
Be honest about the value shape. The gain usually comes from removing routine effort at volume, not from replacing judgement, and the cost is the engineering required to make the bounded tool set, permissions, approval flow and tracing work properly. Where those do not exist, the agent should not be given autonomy.
- Start with one narrow, high-volume, measurable task.
- Compare time saved and error rate against the manual baseline.
- Review traces weekly and expand gradually.
- Verify approval gates are genuinely used, not rubber-stamped.
Frequently asked questions
Should AI agents be allowed to act autonomously in enterprise systems?
For reading, analysing and drafting, yes. For irreversible or externally visible actions such as payments, sending messages or posting transactions, no: those require a human approval gate that shows the concrete action to be taken.
What permissions should an AI agent run with?
The permissions of the user who invoked it, never a shared service account with broader access. That keeps the consequences of an error bounded by what that user could have done directly.
How do you control the cost of agentic workflows?
Set hard limits on steps, tool calls, wall-clock duration and token cost per invocation, detect and break repeated identical calls, and terminate gracefully with a clear outcome when a limit is reached.
References
Engineer your next strategic platform
Estimate your project investment and delivery timeline instantly, or schedule an architectural discovery call with our engineering leadership.