Its own identity
An agent gets a dedicated service identity, never a borrowed staff account. Everything it does is attributable to it, and access can be revoked in one place without affecting a person.
AI Automation & Agents
AI Automation & Agents
Controlled automation of repetitive work — scoped permissions, human approval where it matters, and a complete record of what happened.
Definition
What an AI agent actually is
A system that is given a goal, a limited set of tools, and permission to work through the steps itself — rather than one that simply answers a question.
A chatbot produces text. An agent takes actions: it reads a mailbox, looks up a record, extracts a figure, drafts an entry, files a document. It decides the order of those steps within the boundaries it has been given, and it repeats the process reliably at volume.
That difference is the entire commercial case, and the entire risk. Something that can only produce text is limited in what it can get wrong. Something that can act inside your finance system, mailbox or CRM needs to be treated with the same seriousness as a new member of staff with system access — because functionally that is what it is.
We design them accordingly: a named identity, a defined job, access to only what that job requires, supervision, and a record of everything they did.
Design principles
- Identity
- Its own, never a borrowed staff account
- Scope
- An explicit list of permitted tools
- Data
- Least privilege, read separated from write
- Approval
- Human gate on anything consequential
- Failure mode
- Escalate to a person, never guess
- Oversight
- Logged, monitored, and stoppable
Suitability
What agents are useful for — and what they are not
Being clear about the second list is what keeps the first list credible. Most organisations have one or two processes worth automating properly, not twenty.
Well suited
- High-volume, repeatable tasks with recognisable patterns
- Reading documents and extracting structured information
- Moving information between systems that do not integrate
- Classifying and routing incoming work
- Drafting routine correspondence for a person to approve
- Retrieving and summarising information from internal sources
- Monitoring for a condition and raising it to a human
- First-pass checks that a person then confirms
Poorly suited
- Low-volume tasks where the build costs more than the saving
- Decisions where being wrong is expensive or irreversible
- Anything requiring accountability that cannot be delegated
- Processes that are broken — automation makes them fail faster
- Work that depends on context nobody has written down
- Situations where a customer needs a person, not a faster reply
- Final approval of payments, contracts or employment decisions
- Anything you could not explain or evidence to a regulator
The most common mistake we are asked to correct is automating a process that was already unreliable. Automation does not repair a broken process; it executes it faster and more consistently, which usually makes the underlying problem more visible and more expensive.
Controls
How we keep automation controlled
Every one of these is decided and documented before the agent touches a live system. Retrofitting controls to something already embedded in daily work is considerably harder than building them in.
Scoped tool access
It can call a defined list of tools and endpoints and nothing else. Adding a capability is a deliberate change, reviewed like any other permission grant.
Least-privilege data access
Read access is limited to the specific mailbox, folder or record set the task requires. Write access is separate, narrower, and granted only where the task genuinely needs it.
Human approval gates
Anything with financial, legal, contractual or reputational consequence stops for a person. The agent prepares the action; a human commits it.
Confidence handling
The system recognises when it is uncertain and escalates rather than guessing. A well-designed agent produces a manageable exception queue, not a plausible-looking error rate.
Complete logging
Every input, tool call, output and approval is recorded and retained, so any individual case can be reconstructed months later for an auditor or a customer complaint.
Monitoring and alerting
Volume, exception rate, latency and failures are watched. A silent agent that stopped working three weeks ago is a common and expensive failure mode.
Prompt injection defence
Content the agent reads — emails, documents, web pages — is treated as untrusted input, not as instructions. Capability limits mean a successful injection still cannot exceed the agent's permissions.
A documented kill switch
A named person can stop the agent immediately, and the manual process it replaced is documented and still workable. Nothing runs that the business cannot turn off.
Position
Controlled automation, not autonomy
There is a good deal of enthusiasm at present for agents that operate with little or no supervision. It makes for a compelling demonstration. It makes for a poor operating model in a business that has auditors, insurers, customers and legal obligations.
The value in these systems is not that they remove people from the process. It is that they remove the transcription, the copying between systems, the checking of the routine cases — and leave people doing the part that requires judgement. A finance team reviewing forty exceptions instead of keying nine hundred invoices is a substantial gain, and it does not require anyone to pretend the system is infallible.
Supervision is not a limitation we have imposed reluctantly. It is what makes the system deployable, insurable and trusted by the people who have to work alongside it.
Process
How an automation project runs
The shadow-running stage is the one most projects skip, and the one that most reliably prevents an expensive surprise.
- 01
Pick the right task
Volume, repeatability, error tolerance and the cost of being wrong. If the numbers do not work, we say so before anyone builds anything.
- 02
Design the controls
Identity, permissions, approval points, logging and failure behaviour agreed in writing. This happens before the automation, not after it.
- 03
Build and run in shadow
The agent runs alongside the existing process without acting, so its output can be compared against what people actually did. Discrepancies are the design feedback.
- 04
Cut over and monitor
Staged handover with the manual route still available, then ongoing monitoring of exception rate and volume. Documented so your team owns it, not us.
FAQ
AI automation and agents: common questions
What is an AI agent, in plain terms?
An AI agent is a system that can take actions in your business systems rather than just produce text. It is given a goal, a limited set of tools it may use — read this mailbox, look up that record, draft an entry — and it works through the steps itself. The distinction that matters commercially is that it does things, which is why permissions and approval design matter far more than they do for a chatbot.
Should our business use AI agents?
Only where there is a specific, high-volume, well-understood task that justifies it. Agents are worth the engineering effort when a process runs many times a day with recognisable patterns and a tolerable cost of occasional error. For most SMEs there are one or two such processes, not twenty. Deploying an agent because agents are current is how organisations acquire an unmonitored system with standing access to their data.
Do agents run without any human involvement?
Ours do not, on anything consequential. Full autonomy is technically achievable and commercially unwise for most business processes. We design for controlled automation: the agent does the repetitive work and prepares the outcome, and a person approves anything that commits the business. That approval step is usually seconds, and it is what makes the system defensible.
What is prompt injection and should we worry about it?
Prompt injection is when instructions are hidden in content the AI reads — a line in an email, text in a supplied document — attempting to make it act against your interests. It is a genuine risk for any agent that processes incoming material. The practical defence is not clever filtering alone but capability limits: if the agent cannot send external email or change financial records, an injection that tells it to cannot succeed.
What happens if the agent breaks or gets it wrong?
It is designed to fail into a human queue rather than fail silently. Exceptions escalate, monitoring alerts on abnormal volume or error rates, a named person can stop it immediately, and the manual process it replaced remains documented and workable. We will not build something the business cannot operate without on day one.
Can this work with our existing systems?
Usually. Most finance, CRM and line-of-business systems have an API, and Microsoft 365 is well covered. Where a system genuinely has no integration route, we say so early — screen-scraping a legacy application is possible and almost always a maintenance liability we would rather you avoided.
Automate the right work, properly.
Bring us a process that consumes more time than it should. We will tell you honestly whether it is worth automating, and what it would take.