AI agent development, for work that finishes itself.
An agent is judged on the task it completed, not the reply it wrote.
We build agents that do a job inside your systems: read the record, decide what it needs, call the tool, check the result, and stop for a person when it should. This page is about the engineering of that, the parts that decide whether an agent finishes the work or quietly does the wrong thing. The wider catalogue of AI systems, including copilots and knowledge systems, sits on the AI solutions page.
What building an agent actually involves
An agent is not a prompt with ambition. Most of the build time goes into the six things below, and they are what separates something you can leave running from something that needs watching.
Tools, and the limits on them
An agent can only do what it has been handed. Each tool is a defined action with its own permissions, its own validation, and its own idea of what a bad input looks like, so the boundary is enforced in code rather than requested in a prompt.
- One tool per action, with a typed contract
- Per-tool permissions and scoping
- Input validation before anything runs
- Read-only tools separated from writing ones
Planning, retries, and giving up well
Real tasks fail halfway. The agent needs a plan it can revise, a retry that does not repeat a side effect, and a point at which it stops and says what it could not do rather than inventing a result.
- Multi-step planning with revision
- Idempotent actions, safe to retry
- Step limits and loop detection
- A clean failure message, not a guess
Approval gates and human handoff
Anything irreversible sits behind a person until the record says otherwise. A payment, a deletion, a message to a customer, a contract change: the agent prepares it, someone approves it, and the gate moves as trust is earned.
- Approval queue with full context
- Confidence thresholds that route to a person
- Handoff with the reasoning attached
- Gates loosened per action, not all at once
Memory and what it is allowed to keep
Agents need state to work across steps and sessions, and state is where privacy problems start. We decide what is remembered, for how long, and who it can be shown to, before the first run rather than after an audit.
- Working state across a multi-step task
- Retrieval of prior cases and outcomes
- Retention limits and redaction
- Per-user isolation of anything personal
Evaluation before anyone depends on it
We hold back a set of your real cases with known right answers and score every change against them. A prompt tweak or a model swap that quietly makes things worse gets caught before release rather than by a customer.
- An evaluation set built from your own cases
- Scoring on every change, not just at launch
- Regression checks against past failures
- Sampling of live traffic after release
Cost, latency, and model routing
Running cost is mostly model usage, and most steps of a task do not need the largest model. Routing each step to the smallest model that handles it is the difference between a system that scales and one that gets switched off.
- Small models on classification and routing
- Large models only where reasoning matters
- Caching on anything repeated
- Per-run cost tracked and visible
How the work runs
Tell us what you need
A short written brief is enough to start: what you are building, the stack it has to live in, and the problem behind it. Someone technical reads it, not a sales rep.
passed when we reply with questions and a proposed shape
Scope and quote
We agree what the first release contains and what it costs before anything is built. Anything we cannot estimate honestly gets scoped on its own rather than padded into the total.
passed when the scope and the quote are agreed
Build in the open
Working software arrives in increments, in your repository, with our commits visible from the first week. Progress is something you can open and run, not a status report.
passed when a real user is doing a real job in it
Iterate, then hand over
What the first release teaches sets the priority for the next one. When you want it in house, documentation and a handover period are part of the engagement rather than an extra.
passed when your team can run it without us
How pricing works
Fixed price per milestone
You approve each milestone and its price before it starts, so the cost is known before the work is rather than after. Milestones are sized to be worth reviewing on their own.
Monthly rate for a dedicated team
A set team at a set monthly cost, with notice rather than a minimum term. Priorities move between sprints without renegotiating anything.
Scoping first, quote after
We work out what it should be with you before quoting it. There is no charge for that conversation and no obligation to go ahead.
Frequently asked questions
What ships with every agent
Every build ships end to end, from first scope to live deployment and ongoing support.
