AI & Automation - AI Agents
AI agents with a job description, permissions and a manager.
An agent is only useful when its task is bounded, its access is deliberate and a person is accountable for what it does. We design agents for specific operational jobs inside your existing systems, starting in propose-only mode and extending autonomy only where measurement justifies it.
At a glance
- Who this is for
- Operations and service leaders with high-volume, judgement-light work that still needs interpretation.
- Default posture
- Read-only access, propose-only output, human approval before anything commits.
- Prerequisite
- A documented process and a system of record the agent can safely read from.
Agent types
Five agent shapes worth building.
Each maps to a real operational job. If a proposed agent does not match one of these shapes, its scope is probably too broad.
Intake agent
Reads inbound email and form submissions, classifies intent, extracts the key fields, creates or updates the record and routes it to the right queue.
Research and preparation agent
Assembles context before a human acts - account history, open items, prior correspondence and relevant documents gathered into one brief.
Drafting agent
Produces a first response, quote narrative or report section from your templates and live data, then waits for a person to approve or edit.
Monitoring agent
Watches for conditions that need attention - stalled jobs, unreconciled items, ageing enquiries - and raises them with the context to act on.
Internal knowledge agent
Answers staff questions from your own procedures and product data, citing the source document so the answer can be verified.
Design method
How we scope and control an agent.
The controls are the hard part. The model is the easy part.
01
Define the job precisely
One bounded task with a clear start, a clear finish and a definition of success. Open-ended agents are the reason most agent projects fail.
02
Set permissions deliberately
Read-only by default. Write access is granted field by field, record type by record type, with anything irreversible excluded.
03
Choose the autonomy level
Propose-only, act-with-approval, or act-and-notify. New agents start at propose-only and are promoted only on measured performance.
04
Design escalation first
What the agent does when it is uncertain, when data is missing, or when the case is out of scope - routed to a named human, never guessed.
05
Log everything
Every input, decision, action and output recorded and reviewable. If it cannot be audited afterwards, it should not be running.
06
Review on a schedule
A regular sample review against real cases. Performance drifts as your data and processes change, and it needs a standing owner.
Suitability
Where an agent belongs, and where it does not.
Suited to an agent
Bounded and recoverable
- Varied input that a person currently reads and interprets
- High volume, low individual value per case
- Mistakes visible quickly and cheap to correct
- Clear escalation path to a person who can resolve it
- A measurable baseline it can be judged against
Not suited
Use rules or a person
- Structured data with deterministic rules
- Irreversible actions: payments, contracts, deletions
- Anything with safety, legal or regulatory consequence
- Processes that are not documented or agreed
- Customer conversations requiring genuine accountability
Our position
Three things we will tell you up front.
01An agent is a system component, not a staff member
It needs an owner, permissions, monitoring and a change process, exactly like any other part of your system estate.
02We do not deploy autonomous agents into finance or contracts
Those steps keep human approval. An agent may prepare the work; a person commits it.
03Start with one, prove it, then consider a second
Multiple interacting agents multiply failure modes and make diagnosis much harder. Sequence deliberately.
Describe the task, and we will tell you if an agent fits.
Often the honest answer is that a workflow rule would do the same job more cheaply and more predictably.