We build agents that do work rather than describe it — reading your systems, calling tools, and carrying a process to completion. Every action runs under a scoped identity, and anything irreversible stops for a person first.
The agent loop
AI agent development builds software that plans multi-step work and takes actions in your systems through tools and APIs. Unlike a chatbot, an agent writes to records and triggers processes, so every run carries an audit trail and a human approval gate on irreversible steps.
Agent demos are easy. A model calls three tools in a happy path and the room applauds. Everything that makes production hard is absent from that demo, and here is what it is.
The fastest way to get a demo working is to give the agent the same credentials a senior operations person has. It is also the fastest way to create an internet-reachable component with unlimited write access to your CRM. Agents need their own scoped service identity per tool, which is slower to set up and the only defensible design.
A tool returns an error the model does not understand, so it tries again with slightly different arguments, then again. Without a hard step budget and a cost cap per run, this continues until someone notices the bill or the rate limit. Every agent we ship has both, enforced outside the model.
A record was updated incorrectly three weeks ago. Which step did that, what did the model see at the time, and what would it do now? If the answer requires guessing, the agent is not auditable and should not have write access. Replayable run logs are not a nice-to-have, they are the precondition for letting the thing act at all.
Multi-agent architectures are appealing on a whiteboard and unpleasant in production. Context degrades at every handoff, failures become non-deterministic, and debugging means reconstructing a conversation between four models. One well-scoped agent with good tools beats five agents talking to each other almost every time.
This is the most expensive mistake on the list, and the least discussed. If the path through a process is the same every time, a deterministic workflow automation will run it faster, cheaper and more predictably than any agent. Agents earn their complexity where the route genuinely varies per case and a person would otherwise have to decide. We will tell you when you are in the first category, even though the second is the more interesting engagement.
The model is roughly ten per cent of the system. These are the other ninety.
The agent never receives your credentials. It receives the ability to call functions we wrote: typed inputs, validated arguments, a scoped service identity per tool, and its own rate limit. A tool that reads order status and a tool that cancels an order are separate things with separate permissions, even though a model would happily treat them as one capability.
Where a system exposes no API, the tool is backed by an RPA routine or a database integration instead — that connection work sits under AI integration services.
A run's state lives in a database, not in a growing conversation the model has to keep re-reading. That makes runs pausable, resumable and replayable, keeps token cost flat as a run gets longer, and means an approval that takes two days does not require holding a session open for two days.
Every tool is labelled reversible or not before the agent is allowed to call it. That single classification decides more about the safety of the system than any prompt instruction ever will.
Model input, tool called, arguments, result and decision, recorded per step. You can reconstruct any run months later, which is what makes an incident investigable instead of merely regrettable.
A hard step limit, a cost ceiling per run, and a switch that halts every in-flight run immediately. All enforced by the orchestrator, so a confused model cannot reason its way past them.
An agent that reads an inbox will eventually read an email written specifically to instruct it. You cannot prompt your way out of this. The defence is architectural: retrieved and received content is treated as data rather than instruction, tools stay scoped so a successful injection reaches a small blast radius, and irreversible actions still stop at a person regardless of how convincing the request was.
The full control set lives under AI governance and security, reviewed by the same team that runs our VAPT engagements.
We will tell you whether it needs an agent or a workflow, and why.
Advance the run one step at a time. Read-only steps proceed on their own. At step five the agent wants to schedule a payment, and the run stops until somebody decides.
Run
ap-recon · step 0 of 6
fetch_mailbox_item(id: "INV-88214")
→ supplier invoice PDF received, 2 pages
extract_invoice_fields(doc: "INV-88214")
→ supplier: NORTH-STEEL · po_ref: PO-4471 · qty_billed: 500 · confidence: 0.94
lookup_purchase_order(ref: "PO-4471")
→ qty_ordered: 480 · qty_received: 480 · status: closed
variance detected: billed 500, received 480
→ 20 units over receipt · exceeds tolerance of 2% · cannot auto-approve
schedule_payment(po: "PO-4471", qty: 480, hold_variance: true)
→ irreversible · run paused · awaiting human approval
Approved by finance.lead · payment scheduled for 480 units
→ variance of 20 raised with NORTH-STEEL · run logged · replay available
Rejected by finance.lead · no payment scheduled
→ routed to AP queue with extraction, PO record and variance note attached
Steps one to four are read-only, so they run without asking. Step five writes to a payment system and cannot be undone with a click, so it stops. That boundary is set during design, not decided by the model at runtime, and it is the difference between an agent you can deploy and one you can only demonstrate.
Five steps, in this order. It follows the same delivery shape as the rest of the AI and automation practice, with tool design standing in for process mapping.
What a successful run looks like, what the agent is explicitly not permitted to attempt, and how the result gets verified. That last one eliminates more candidate use cases than anything else: if nobody can check whether the agent got it right, it does not go to production regardless of how impressive the demo was.
Every capability becomes a documented function with typed inputs, validated arguments, a scoped service identity and its own rate limit. This is where most of the engineering time goes, and it is the part that determines whether the agent is safe. The model gets no credentials, only the tools we chose to give it.
Plan, act, observe, decide — with state held in a database rather than inside a growing conversation. A run can be paused for a two-day approval and resumed exactly where it stopped, and token cost stays flat instead of climbing with every turn.
Each tool is classified reversible or irreversible. Irreversible calls route through a human confirmation recorded against an identity before the action executes. Where the organisation is comfortable, some gates convert to act-and-notify with a reversal window instead, which is a policy decision rather than a technical one.
Per-run logging with full replay, a step budget, a cost ceiling, a kill switch, and a fixed set of scenarios that must pass before any model or prompt change ships. Your team receives the runbook, the dashboards and the rollback path, plus 100% of the source and IP on final approval.
Grouped by the job each layer does. Selection depends on where your data may live and what you already run in production.
Agents frequently share infrastructure with the rest of your automation estate, so the orchestration and deployment decisions overlap heavily with workflow automation and with the architecture work our IT consulting team does before anything is provisioned.
These four get described with the same word and behave nothing alike. Each has a different failure mode and a different permission profile.
Sits alongside a person and does the fetching and drafting. It looks things up across systems, prepares a reply or a record, and hands it over for a human to send or commit. Nothing it produces takes effect on its own.
This is the cheapest agent to make safe and the easiest to get adopted, because the person keeps the pen. If you are unsure where to start, start here. It also overlaps heavily with grounded conversational AI, and the two are often the same build.
Permission profile
Read broadly, write nothing
Failure mode
A confident wrong draft that a rushed person sends
Good fit when
The judgement should stay human but the gathering should not
Autonomy is a dial, not a switch, and it is set per tool rather than per agent. Move it and watch which actions cross from gated to automatic.
Set per tool, agreed with the process owner.
The agent queries systems and reports. It cannot change anything, so the worst outcome is a wrong summary. Nearly every agent should start here for its first fortnight in production, running silently alongside the humans doing the work.
Automatic
Lookups, reconciliation checks, exception detection, reporting
Still human
Everything that changes a record
A quantity variance on a supplier invoice, handled by people and then by a process agent with a Level 3 boundary. Note where the human time moves rather than disappears.
Elapsed: about four working days · five handoffs
Day 1 · Invoice lands in a shared inbox
Waits for whoever is on AP duty to open it.
Day 1 · Keyed into the ledger by hand
Fields retyped from the PDF, with the usual transposition risk.
Day 2 · Someone notices the quantity does not match
Or does not notice, which is the more expensive branch.
Day 3 · Email to the warehouse to confirm receipt
Reply arrives whenever it arrives.
Day 4 · Finance lead approves the corrected amount
The only step that genuinely needed a decision.
The finance lead still approves. What went away was four days of waiting, the retyping, and the branch where nobody spots the variance at all. That is the honest shape of the benefit, and it is the shape we scope against — the same logic drives document processing engagements.
Four scenarios from sectors we work in. Each one has a varying path and a verifiable outcome, which is the test. Profiles are anonymised.
A regional operator's agent watches for shipments that miss a checkpoint, pulls the carrier record and the customer's service terms, decides whether the delay breaches an SLA, and either notifies proactively or escalates to the account owner. The path differs per consignment, which is exactly when an agent beats a workflow.
Logistics engagementsThe run demonstrated above, deployed in a manufacturing finance function. In-tolerance invoices complete without a person; variances stop for approval with the evidence already gathered. The volume of items reaching a human drops sharply while the decisions that matter stay with the finance lead.
Manufacturing engagementsFor a lender, a read-only agent assembles a complete onboarding case: documents gathered, fields cross-checked against registries, missing items listed. It never approves anybody. It removes the assembly work so an analyst spends their time on the judgement rather than the collation.
Banking and insuranceA professional services firm runs a research agent over incoming tender documents. It extracts every requirement, finds the closest previously written response, and drafts a first pass with references to the source proposal. A partner still owns what gets submitted.
Consulting providersThese four get conflated constantly, and picking the wrong one is the most common reason an automation programme costs more than it saves.
| Criterion | Chatbot | Workflow automation | RPA bot | AI agent |
|---|---|---|---|---|
| Decides the path | No, it answers | No, the path is fixed | No, the script is fixed | Yes, per case |
| Writes to systems | Rarely, and only on rails | Yes, deterministically | Yes, through the interface | Yes, within a permission boundary |
| Handles a case it has not seen | Escalates | Fails or halts | Breaks, often silently | Attempts a route, then escalates if it cannot |
| Predictability | High within scope | Total | Total until the interface changes | Bounded, not total — the honest trade |
| Use it when | People need answers | The steps never vary | There is no API to call | The route varies and the result is verifiable |
In practice a working system usually contains three of these. An agent handles the varying middle, a workflow carries the deterministic ends, and an RPA bot acts as the tool for whichever system refuses to expose an API. Designing that split is most of the value in the first two weeks of an engagement.
Agents sit on top of other things. These are the neighbouring parts of the AI and automation practice that usually appear in the same statement of work.
The deterministic scaffolding around the agent. Triggers, retries, queues and the parts of the process that should never involve a model at all.
Where the requirement turns out to be answering rather than acting. Cheaper, faster to approve, and often the right first project.
The model layer underneath: evaluation harness design, retrieval architecture and provider-neutral deployment.
Accountability, access control and logging for systems that act. Agents raise the governance bar more than any other AI system you will deploy.
Where agents most often go customer-facing first: resolving a request end to end rather than routing it to a queue.
The operations-leader framing of the same decision, for people sizing an automation budget rather than designing the system.
Agent front-ends and approval interfaces are built by the same team that handles our custom web development work, so the gate a finance lead clicks is a proper piece of software rather than a form bolted onto a chat window. If you want to talk through a specific process, send us the details or read the general help centre first.
The ten that come up in almost every first conversation about autonomous AI agents.
That is where agents belong. We will map the tools it would need, the gates it would stop at, and whether a workflow would do the job for less. Reply in under 3 minutes.
