AI agent development for agents that finish the work
Multi-step agents that use your tools, follow your rules, and hand off to a human at exactly the points where a human should decide.
it acts on its own until the step you said it may not
- Tool-using agents
- Multi-step workflows
- Human-in-the-loop gates
- Best when
- A multi-step task with clear rules that people do by hand today, at volume.
- Not a fit when
- A one-off decision that needs judgement, or a task with no way to check the outcome.
- First thing you get
- One workflow run end to end by an agent, with the approval gate in place, on your data.
What is an AI agent?
An AI agent is software that uses a language model to work through a multi-step task: it reads a request, decides what to do next, calls the systems it needs, such as your ERP, CRM or inbox, and reports what it did. We build agents that follow your rules and hand decisions to a person where a person should decide.
A chatbot answers. An agent acts — it reads a request, decides what to do, calls the systems it needs, and reports back. That difference is where most of the operational value sits, and also where most of the risk does.
We build agents that are scoped deliberately: a defined set of tools, explicit guardrails on what they may do unattended, and a clear escalation point where a person takes over. An agent that can do anything is not a feature, it is an incident waiting to be scheduled.
What this includes
- 01
Tool-using agents
Agents wired into your real systems — CRMs, ticketing, databases, internal APIs — through a controlled tool layer.
- 02
Multi-step workflows
Long-running tasks that plan, execute, check their own work, and retry when a step fails.
- 03
Human-in-the-loop gates
Defined checkpoints where the agent pauses for approval before anything consequential happens.
- 04
Guardrails and permissions
Scoped credentials, allowed-action lists, and spend limits so an agent cannot exceed its remit.
- 05
Observability
Every decision, tool call, and output logged so you can audit what the agent did and why.
- 06
Evaluation harnesses
Test suites for agent behaviour, so a prompt or model change does not silently degrade quality.
Situations we see most often
Back-office request handling
An agent triages incoming requests, gathers what it needs from internal systems, drafts the response, and routes anything unusual to a person.
Data reconciliation
Cross-checking records between systems that were never designed to agree, flagging genuine mismatches instead of noise.
Research and summarisation at volume
Reading large document sets, extracting the specific fields that matter, and producing a structured output your systems can consume.
Customer operations assist
An agent prepares the full context for a support case before a human opens it, so the person starts from an answer rather than a search.
What to know before you start
AI agent, chatbot or automation: which do you need?
A chatbot answers questions. A conventional automation follows fixed rules: if this, then that. An AI agent sits between them: it works towards a goal, decides which steps to take, and uses your systems to take them. That flexibility is what lets it handle requests that are similar but never identical.
If the steps never vary, plain automation is cheaper and more predictable, and we will recommend it. If people only need information, a cited assistant is enough. An agent earns its cost when the work is multi-step, the inputs vary, and today a person is copying between systems to get it done.
Which tasks are good candidates for an AI agent?
The best candidates share four traits: the task happens at volume, it follows rules a person could write down, it touches several systems, and the outcome can be checked. Triaging back-office requests, reconciling records between systems and preparing case context before a person picks it up all fit.
Poor candidates are one-off judgement calls, tasks where nobody could tell whether the result was right, and anything irreversible without a person in the loop. Starting with one well-chosen workflow, run end to end, teaches more than a broad pilot.
How is an agent tested before it touches real work?
First against an evaluation set: real past cases with known correct outcomes, so behaviour is measured rather than demonstrated. Then usually in shadow mode, running alongside the people doing the work, with its proposed actions compared to theirs but nothing executed.
Only then does it act, behind approval gates on anything consequential. Autonomy is widened one step at a time, as the logged record shows the agent getting that step right. Every prompt or model change re-runs the evaluation set, so quality cannot drift silently.
What does an AI agent cost to run?
Beyond the build, an agent has a running cost: model calls for each step it reasons through, plus the infrastructure for queues, retries and logging. The cost per task depends on how many steps a task takes and which model each step uses.
We design for it explicitly: cheaper models for routine steps, stronger ones only where reasoning needs it, caching where inputs repeat, and spend limits per run so a looping agent cannot run up a bill. You see cost per task in the same logs as everything else.
What drives the cost of building an AI agent?
Agent projects vary more by the systems and rules around them than by the AI itself. These are the factors that move cost most.
| Factor | Effect | Why it matters |
|---|---|---|
| Systems it must use | High | Each tool, whether a CRM, ticketing system, database or internal API, needs a controlled interface, permissions and error handling. |
| Workflow length and branching | High | Longer tasks with more decision points need more planning logic, more checks and more evaluation cases. |
| Approval and review | Medium | Human-in-the-loop gates need a place for people to review, approve or correct what the agent proposes. |
| Evaluation set | Medium | Building a set of real cases with known outcomes takes effort up front, and is what makes every later change safe. |
| Data access and security | Medium | Scoped credentials, sensitive data handling and audit logging add work, especially in regulated environments. |
| Volume and model choice | Medium | High volumes favour routing routine steps to smaller models; this design work lowers the running cost. |
What a typical engagement looks like
- 011–3 weeks
Discover
Process map
- 022–4 weeks
Design
Interactive prototype
- 03two-week cycles
Build
Working software each cycle
- 04ongoing
Ship & support
Automated pipeline
What we build it with
- Frameworks
- LangGraphVercel AI SDKMCP
- Models
- ClaudeGPTOpen-weight models
- Infrastructure
- QueuesRetriesStructured logging
Questions we get asked
01How do we stop an agent from doing something damaging?
By constraining it before it runs, not by hoping it behaves. Agents get scoped credentials, an explicit allowed-action list, and human approval gates on anything irreversible — payments, deletions, external communication. Everything is logged.
02What happens when the agent gets it wrong?
It will sometimes. The design assumption is that it will. That is why consequential steps sit behind approval, why actions are reversible where possible, and why every run is auditable so you can find out what happened.
03Do we need to replace our existing systems?
No. Agents work through your existing systems via APIs and integrations. That is usually the point — the agent does the tedious cross-system work your team currently does by hand.
04Which AI models do you use?
Whichever suits each step: Claude, GPT or open-weight models. The agent is built so the model can be swapped, which keeps you free to move as models improve or prices change, with the evaluation set confirming nothing got worse.
05Can an agent run inside our own infrastructure?
Yes. For sensitive data we can deploy the agent and an open-weight model in your own cloud or servers, so no data leaves your environment. Where hosted models are used, we use enterprise tiers where inputs are not retained for training.
Adjacent capabilities
Further reading
Tell us what you are building.
Share the problem and we will come back with an approach, a rough shape of the work, and what it would take to deliver it.