Tool contracts
Every action the agent can take becomes a typed function with declared scope, side effects, an idempotency key and a rollback path — tested like ordinary backend code, so a failure repeats.
Typed tool layerAI & data
Agents that complete work inside your systems
We build single-purpose agents that take a request, call your systems, and finish the task — or stop and hand it to a named human with the full reasoning attached.
- Fixed scope
- 14 days to demo
- Full IP transfer
- Eval suite included
What an agent actually is
An agent is a program that decides what to do next. You give it a goal, a set of tools it may call, and a boundary it may not cross; it plans, calls, observes the result, and either continues or stops. The interesting engineering is almost never the prompt — it is the tool boundary. What the agent is allowed to reach, under whose credentials, and what happens to the record when a call half-succeeds.
Getting an agent to work once is a weekend. Getting it to work on the tail — the malformed order, the customer who already has an open case, the API that returns 200 with an empty body — is the project. Most of our build time goes into what happens when the world does not match the happy path: what the agent retries, what it refuses, and what it escalates instead of guessing.
| What is true of this work | What it forces | What we do about it |
|---|---|---|
| Retrieved text can carry instructions | Treat all context as untrusted | Allowlisted tools, no arbitrary execution |
| Tool calls have real side effects | Retries must not double-charge | Idempotency keys and rollback paths |
| Some actions cannot be undone | Autonomy must stop before them | Named approver gates irreversible writes |
| Loops can burn budget silently | Cost is unbounded by default | Per-task ceilings trip a breaker |
| Model behaviour drifts across versions | Yesterday’s fix can regress today | Graded eval suite blocks merges |
In scope
- One agent completing one defined job
- Typed tool layer over your systems
- Approval queue and reviewer interface
- Eval suite wired into your CI
Not in scope
- Several agents negotiating a shared plan
- Building APIs your systems do not expose
- Ongoing operation once handover completes
Handled by
- Agentic AI DevelopmentMulti-agent planning over a long horizon
- Software IntegrationBuilding and wrapping the APIs an agent calls
What we build
Grounded retrieval
The agent reads your policies, tickets and records rather than reciting from training. We build the chunking, ranking and freshness rules, and make it cite the passage it acted on.
Cited retrieval indexHuman handoff and approval
A confidence and risk policy decides which tasks the agent finishes alone and which land in a human queue with a proposed action, its trace, and one-click approve or correct.
Human approval queueEvaluation harness
A graded set of real tasks with expected trajectories, re-run on every change to prompts, tools or model version. It reports completion, wrong-tool rate and cost per task, and blocks regressions.
Graded eval setDurable runs
Long tasks checkpoint at each completed step, so a crash, a rate limit or an overnight approval resumes instead of restarting. Idempotency keys stop a retry refunding the same customer twice.
Checkpointed run storeTraces and budgets
Every run is stored as a replayable trace: input, retrieved context, each tool call, tokens and cost. Per-task and per-tenant ceilings trip a breaker before a retry loop becomes an invoice.
Replayable trace storeHow the work runs
- 01Week 1
Task teardown
We record how the people doing the job today handle real cases: what they open, what they decide, where they hesitate. That transcript becomes the agent’s scope, its tool list and the first eval set.
You getScoped task spec and eval set
- 02Weeks 1–2
Tool and permission design
Before any agent code, we build and test the tools against your systems: read paths first, then writes behind an approval gate. Each gets a scoped credential, so blast radius is bounded by design, not prompt.
You getTyped tool layer with scoped credentials
- 03Week 2
Loop and demo
We wire the loop, retrieval and stop conditions, then replay the recorded cases until it clears the anchor set. Fourteen days in you see it running on your systems, with the remaining failures named.
You getWorking agent on your data
- 04Weeks 3–14
Shadow run and release
The agent runs alongside the team without acting — it proposes, a human decides, we score every disagreement. Autonomy then switches on task class by task class. Release hands you dashboards, alerts, runbook and repo walkthrough.
You getLive agent, runbook and repo
What you are handed
- Typed tool layer with scoped credentials
- Graded eval set of real tasks
- Human approval queue and review UI
- Replayable trace store per agent run
- Cost and tool-call circuit breakers
- Shadow-run accuracy report against human decisions
- Prompt and policy versioning in your repo
- Runbook for failures and escalation
- Source repository under your organisation
Typical stack
Runtime
PythonFastAPILangGraphTemporalCeleryRedis
Retrieval
Postgres with pgvectorQdrantOpenSearchUnstructuredMCP servers
Evaluation
PytestPromptfooDeepEvalLangfuseRagas
Platform
DockerKubernetesTerraformGitLab CIOpenTelemetryGrafana
The calls we make, and why
Should we build this ourselves or buy an agent platform?
Build only where the decision logic is your own
Vendors already solve meeting notes and first-line FAQ deflection, and they integrate the common systems. What they cannot encode is your underwriting rules, your triage policy, your pricing exceptions. The test: would you be embarrassed if a competitor bought the identical tool?
We’d choose otherwise whenthe workflow is standard, a vendor covers it, and the budget is better spent on integration
Should the agent plan freely, or follow a fixed workflow with LLM steps?
Default to the fixed workflow; free planning is the exception
If you can draw the steps on a whiteboard, encode them as a state machine and use the model only where judgement is genuinely needed — classification, extraction, drafting. Free planning costs more, fails less predictably, and is much harder to evaluate.
We’d choose otherwise whenthe branch count is large and unknowable — open-ended research, diagnosis, anything you cannot enumerate
Do we need to fine-tune a model for our domain?
Almost never at the start — fix the context first
When an agent behaves badly the cause is usually retrieval or an ambiguous tool description, and fine-tuning bakes that mistake in at greater cost. Every tune also pins you to one provider and adds a re-training step to every change.
We’d choose otherwise whenone narrow, high-volume step has a stable output shape and a smaller model cuts spend
How much autonomy should the agent have on day one?
None it has not earned in a shadow run
We ship read and draft autonomy immediately, then release write actions one task class at a time as measured agreement clears a threshold you set. Autonomy is a permission granted per action type, not a switch flipped at launch.
We’d choose otherwise whenthe work is reversible and low-value — tagging, routing, enrichment — where waiting on a human costs more
This fits if
- You have a high-volume task with a clear definition of done
- Your systems expose APIs, or you will build the missing ones
- Someone on your team can adjudicate disputed cases during the shadow run
- The work is judgement-heavy enough that rules engines already failed
- You want the repo, prompts and eval set in your own organisation
Look elsewhere if
- You want a website chat widget — a smaller, cheaper build
- The task is fully deterministic — a scheduled script beats an agent
- Nobody can be named accountable for what the agent decides
EngagementFixed-scope build
Typical length8–14 weeks
How it startsSend us one task you would hand a new starter, and we will scope it in a week.
Questions we get asked
What does an AI agent build actually cost?
Price is driven by how many systems the agent must touch and how hard they are to reach, not by the agent itself. We quote a fixed scope after a one-week exercise. Two clean REST APIs and one document source is a small build; six systems, one a mainframe without an API, is a different project priced separately.
What does it cost to run once it is live?
Running cost is per completed task, and a task costs many times a single chat reply, because the agent reads, calls several tools and re-reads every result. The multiple depends on your task, so we instrument cost per task from the first week and set hard ceilings per task and per tenant.
Who owns the agent, the prompts and the data?
You do — source code, prompts, tool definitions, eval sets and traces transfer to your organisation on final payment, with no runtime licence retained. The repository lives under your GitHub or GitLab account from day one, not ours. Your data is used to build and evaluate your agent and nothing else; we do not pool it or train on it.
What happens when the agent gets something wrong in production?
Every run leaves a replayable trace, so the first step is to reproduce the decision rather than argue about it. A wrong action is rolled back through that tool’s rollback path, the case becomes a permanent eval case, and the fix ships behind the same gate as any code change. During the 30-day warranty that work is ours, not billable.
How do you stop the agent being tricked by a malicious document?
We treat every piece of retrieved text as untrusted input, not as instruction — the same posture you take with user-supplied SQL. Injection cannot be fully prevented at the model layer today, so the control is containment: scoped credentials, an allowlist of tools, no arbitrary code or query execution, and human approval in front of anything irreversible.
Often bought alongside
Tell us the requirement.
Thirty minutes with the engineers who would build it. You leave with a scope, a timeline and a fixed price — or an honest no, and the reason why.