Agents that finish a bounded task — and know when to hand it back.
An AI agent is a system in which a language model chooses the next step of a task and carries it out through tools it has been allowed to use. Done well, it takes repetitive multi-step work off people’s desks. Done carelessly, it acts with more authority than anyone intended.
We design agents around one workflow at a time, with the narrowest possible tools, explicit approval points and a record of every step.
01Assistant, fixed call or agent?
Who decides the next step — and can it change anything?
“Agent” is used loosely. Two questions separate the options: whether the model or your code decides what happens next, and whether the system can act on other systems at all.
| Question | Conversational assistant | Fixed model call | Tool-using agent | Conventional automation |
|---|---|---|---|---|
| Who decides the next step | The person, turn by turn | Your code; the model fills one step | The model, inside limits you set | Rules written in advance |
| Can it act on systems? | No — it answers and drafts | Only through the code around it | Yes, through allowlisted tools | Yes, along fixed paths |
| Suited to | Questions, drafting, exploring a topic | Classifying, summarising or extracting at one point in a process | Tasks whose steps genuinely vary from case to case | Stable, well-understood processes |
| Main risk | Confident but wrong answers | An error at that step flows downstream | Wrong or unauthorised actions; manipulation through content it reads | Brittle when inputs change shape |
02Where an agent earns its place
Multi-step work that is repetitive, but never quite the same twice.
Examples to assess against your own processes — not descriptions of existing deployments. Potential use case
Request triage with lookups
Read an incoming request, pull the related customer or asset record, classify it and route it with a drafted summary — anything unusual goes to a person.
Case-file assembly
Gather the documents, history and status needed for a decision from several systems into one bundle for a reviewer.
Reconciliation with exceptions
Compare records held in two systems, change nothing automatically, and list each mismatch with the evidence behind it.
Runbook steps for routine requests
Check status, collect missing details and prepare a change for an internal service desk, stopping at the approval step.
When conventional automation is simpler and safer. If the steps are the same every time, a workflow tool or script is cheaper to run, easier to test and fails predictably. If one judgement is needed — classify this, extract that — a fixed model call inside ordinary code is usually enough. And if a mistake would be costly, hard to reverse and unreviewed, an agent is the wrong design whatever the model.
03How it works
A loop with limits, checks and a way out.
Agent loop
- InputTask arrivesRequest, ticket or schedule
- ModelPlan next stepWithin instructions and a step limit
- ToolCall an allowlisted toolScoped credentials, typed arguments
- CheckValidate the resultSchema and business rules↳ retry with backoff, or stop
- PersonApproval gateFor consequential actions↳ declined: hand back with context
- OutputActWrite, send or close
- StoreTraceEvery call and decision recorded
- Input
- Model
- Tool
- Check
- Person
- Store
Define the boundary
Write down the task, its end state, the systems involved and what the agent must never do. If the boundary does not fit on a page, the task is usually too broad for one agent.Design narrow tools
Each tool does one thing — “look up an order by number”, not “run any query” — with typed inputs, a clear description the model can follow, and its own permission scope.Constrain the loop
Instructions, a maximum number of steps, timeouts on every call, retries with backoff for transient failures, and an explicit “cannot complete” outcome.Validate before acting
Tool arguments and model output are checked against schemas and business rules before anything is written. Invalid output is rejected and reported, not quietly repaired.Put people at the right points
Approval before actions that move money, contact customers, change records of authority or are hard to undo; escalation that carries the context gathered so far.Trace and replay
Each run keeps its instructions, tool calls, results and decisions, so a reviewer can see why something happened and fixes can be tested against past runs.
04Implementation considerations
Decisions that shape cost, safety and maintainability.
- Identity and permissions
- Whether the agent acts under its own service identity or on behalf of a signed-in user — and in either case with permissions no broader than the task, granted by your administrators.
- One agent or several
- One agent with a few well-described tools is easier to test and reason about. Splitting work across several agents is considered only when one set of instructions or tools becomes unmanageable.
- State and idempotency
- Long-running tasks save their state so they can resume, and write operations carry idempotency keys so a retry cannot apply the same change twice.
- Cost and latency
- Every pass through the loop is at least one model call. Step limits, caching and smaller models for simple sub-steps keep cost and response time predictable.
- Fallback
- When a dependency is down or the agent is unsure, the case lands in a queue someone already watches — never in a silent failure.
05Limits and security
What can go wrong, and what we design against.
The threat model follows public guidance such as the OWASP Top 10 for LLM Applications (external site), in particular prompt injection and excessive agency.
Limitations
- Models can choose the wrong tool, misread an instruction or stop early. Testing reduces this; it does not remove it.
- An agent can do no better than the data and actions its tools give it.
- Small errors compound over long, open-ended tasks, so narrow tasks are more reliable than broad ones.
Security implications
- Emails, documents and web pages the agent reads can contain instructions meant to redirect it. That content is handled as data, never as a source of commands.
- No tool is granted that the task does not need, and no tool can exceed its own permission scope.
- Secrets live in the tool layer, never in prompts, and outputs are validated before they reach another system.
- Traces can contain personal or confidential data, so they have access controls and a retention limit.
06How success is measured
Judged on finished tasks, not impressive demos.
Measures are agreed before building and re-run on every change. How we evaluate and govern AI systems.
- Task completion
- Share of representative cases completed correctly end to end, compared with how the work is done today.
- Tool-call correctness
- Right tool, right arguments, right order — checked step by step against expected traces.
- Escalation quality
- Cases handed to people when they should be, with enough context to act — and not handed over needlessly.
- Safety
- Unapproved actions blocked, and behaviour on deliberately adversarial inputs.
- Cost and latency
- Model calls, tokens and elapsed time per completed task.
07Related
Related services.
Next step
Bring one workflow you would hand to a careful new colleague.
Describe the steps, the systems involved and where a person must sign off. We will tell you whether an agent, a fixed automation or neither is the right fit.