It states the plan first
The agent decomposes the request and commits to a plan before acting, which makes the plan reviewable — and makes a bad plan cheap to catch.
AI Agents
BuildA chatbot tells you what to do. An agent does it.
Autonomous agents that plan, call real tools against real systems, and leave a trace of every action — with human approval gates on anything consequential.
Typical stack
- Claude
- OpenAI
- LangGraph
- Temporal
- PostgreSQL
- Redis
- Node.js
- TypeScript
Written for: An operations owner who has automated the answering and discovered the doing is still manual.
Who it is for
Is this built for a business like mine?Built for businesses drowning in high-volume, low-judgement work.
Agents earn their cost where a task is repetitive, rule-shaped and currently done by someone whose time is worth more. These are the shapes we see most often.
What we see
Dispatchers spend the first three hours of every day making check calls and updating loads.
What we build
An agent that runs status checks, updates the TMS and escalates only the loads that are actually off-plan.
The detail that matters
It escalates on a rule you set — hours late, not "seems concerning".
What we see
"Where is my order" is most of the support queue, and answering it means opening three tabs.
What we build
An agent with read access to your commerce platform and carrier APIs that resolves the whole question, including the refund path when it is warranted.
The detail that matters
Refunds above a threshold you choose stop for approval instead of being issued.
What we see
Engineers sit in the support rotation answering tier-one questions the docs already cover.
What we build
An agent grounded in current docs and live API behaviour, that reproduces the issue where it can and hands over a written diagnosis where it cannot.
The detail that matters
It says it is unsure rather than inventing an endpoint that does not exist.
What we see
Inside sales spends all day answering stock and lead-time questions from trade accounts.
What we build
An agent that reads live stock, quotes lead times and drafts the order, with a human confirming before anything is committed.
The detail that matters
Nothing is committed to the ERP without a person, by design.
What we see
Enrolment season brings ten times the enquiry volume, and the same fifty questions about eligibility, fees and deadlines are answered by hand.
What we build
An agent grounded in current, versioned policy that answers eligibility and fee questions, checks application status and books an advisor call when the answer is genuinely conditional.
The detail that matters
Policy is versioned, so an eligibility answer is never last year’s — and a wrong one here is a complaint, sometimes a refund.
What we see
Monitoring fires thousands of alerts a month and analysts open every one, even though most clear on the first check.
What we build
An agent that gathers the evidence a first-pass review needs, classifies the obvious clears and routes the rest to an analyst with the investigation already started.
The detail that matters
It gathers and classifies. The disposition is always a person’s, because a machine-made compliance decision is a liability with a delay on it.
What we see
Renewals, document chases and status updates are remembered rather than scheduled, so the ones that slip are the ones nobody notices.
What we build
An agent that tracks outstanding items, chases them on a schedule and updates the case record — stopping at a gate before anything client-facing is sent.
The detail that matters
It collects and chases. It never advises, and every action lands in an auditable trail by construction.
And who it is not for
If the task genuinely requires judgement every time — negotiation, clinical decisions, anything where the right answer depends on reading a person — an agent is the wrong tool and we will tell you that rather than sell you one.
The problem
Do they understand what is actually going wrong?Most "AI agents" are a chat window with ambition.
They can describe the refund policy but not issue the refund, summarise the ticket but not update the record. The moment one is given real permissions, the second problem appears: nobody can say what it did, why, or whether it should have. So it gets given no permissions, and the work stays manual.
It answers the question and a person still does the task.
It calls a tool with the wrong argument and nothing catches it until a customer complains.
There is no record of what it decided, so a bad outcome cannot be explained or prevented.
One unusual case sends it into a loop that spends money until somebody notices.
What we build
What exactly would I be buying?Agents with brakes.
Autonomy is not a slider you turn up. It is a set of specific permissions granted to a specific agent for a specific task, with a specific point at which it must stop and ask. We build the brakes before we build the engine.
Tools are contracts
Every tool has a typed schema. A malformed argument fails at the boundary with a readable error, rather than half-executing inside your systems.
Gates on anything consequential
Spending money, contacting a customer, changing a record that matters — each sits behind an approval you configure. Autonomy grows as evidence accumulates.
Full replay
Every step, tool call, argument and result is recorded and replayable. "Why did it do that" is a question with an answer.
How it works
How does this actually function?The loop, and where it stops.
An agent that cannot stop is not autonomous, it is unsupervised. Step limits, spend limits and gate conditions are part of the loop rather than bolted around it.
Observe
Plan
Act
Check
Gate → humanReport
Check runs after every action, not at the end. A wrong step is caught before it compounds into five.
Gates are conditions you write — amount, customer tier, record type — not a confidence score the model produces about itself.
Step and spend ceilings are hard limits. Hitting one is an escalation, not a crash.
What changes
What is different afterwards?What is different afterwards.
Tasks finish
The distinction that matters: work leaves the queue completed rather than arriving at a person as a well-summarised suggestion.
Volume completed end to end without a human touching it.
Risk has a ceiling
Each agent holds narrow, scoped permissions and stops at defined gates, so the worst case is bounded by design rather than by hope.
The maximum an agent can do wrong, written down before launch.
Behaviour is explainable
Any action can be replayed with the full context the agent had, which turns an incident into a fix instead of a policy debate.
Every action traceable to the plan and inputs that produced it.
How we deliver
How does this start, and what do I get at each step?Six stages, and every one has an exit.
You can stop after any stage with something useful in hand. That is the point of naming the artefacts rather than the activities.
- 01
Task inventory
Every candidate task scored on volume and on what failure costs. High volume and low failure cost goes first — that is where autonomy is cheap to earn.
- Scored task inventory
- Success criteria per task
- The tasks we recommend leaving to people
- 02
Tool design
Each action the agent can take, defined as a typed contract with its permissions and its failure behaviour.
- Tool schemas
- Permission matrix per agent
- Gate conditions, written by you
- 03
Agent build
Planning, execution and checking, against your real systems in a sandbox.
- Working agent
- Trace viewer
- Step and spend limits configured
- 04
Shadow mode
The agent proposes every action and a human approves each one. This is where the gate policy gets corrected by contact with reality.
- Shadow report
- Approval rate by task type
- Revised gate policy
- 05
Graduated release
Autonomy widens one task type at a time, on evidence from shadow mode rather than on a launch date.
- Release plan per task type
- Monitoring and alerts
- Rollback procedure
- 06
Handover
Your repository, your infrastructure, your runbook — including how to add a tool and how to tighten a gate.
- Code and infrastructure transferred
- Runbook
- Recorded training session
Questions
But what about the thing that worries me?The questions people actually ask.
What is the actual difference between an agent and a chatbot?
A chatbot produces text. An agent produces outcomes — it plans, calls tools that change real state in real systems, checks the result, and reports what it did. If the output is a message rather than a completed task, it is a chatbot.
How do you stop it doing something harmful?
Four mechanisms, layered: permissions scoped per agent so it can only reach what its task needs; schema validation so malformed calls fail at the boundary; approval gates on consequential actions; and hard step and spend ceilings. Plus a full trace, so anything that does go wrong is diagnosable.
Can it work with the tools we already use?
Anything with an API — Zendesk, Intercom, HubSpot, Salesforce, Shopify, Stripe, Slack, your own systems. Where there is no API we build the integration layer, and where the system is old we accept its terms rather than assume modern ones.
How much supervision does this need?
Heavy at first and light later, deliberately. Shadow mode means every action is approved by a person; autonomy widens per task type as the approval rate proves it should. Most clients are still approving one or two categories a year in, and that is a healthy outcome rather than a failure.
What happens when it encounters something it has never seen?
It escalates. The escalation rule is explicit and written by you — not a confidence threshold the model sets for itself — and the case is logged so the gap can be closed deliberately.
The other half
The escalation has to land somewhere.
Every gate and every escalation rule creates a queue of things the agent decided not to handle. Most vendors stop at that boundary and hand you the problem. We staff the other side of it — trained people who take the escalation with the full trace attached, which is why our gates are set for correctness rather than for a demo.
Live Chat SupportStart
What is the next step?Tell us the problem, not the specification.
A short call is usually enough to say which half of the business your problem belongs to, roughly what it costs, and whether it is worth doing at all.
Related services
- AI EngineeringAI DevelopmentApplied AI systems built with retrieval, evaluation and observability from the first commit — because those decide whether it still works in month six.
- AI EngineeringAI Voice AgentsVoice agents that answer, qualify and book against live availability — and hand a warm call to a person the moment the conversation needs one.
- DevelopmentWebsite DevelopmentFast, accessible, search-legible websites built on a performance budget — and handed over as a codebase you own, not a platform you rent.