AI & Agents

An agent is only useful once it is allowed to act

And it is only safe to allow once the boundary is written down. We build agents that work against your real systems through tools you register, with an approval line you draw and a record of everything they did.

The loop, and where the rules sit in it. Every tool call passes the policy; retrieval feeds context in from your own data rather than from the model’s memory.

Who it is for

You are probably here for one of these

You have a process that is mostly rules and mostly manual

Quoting, triage, reconciliation, onboarding checks. The rules exist — they live in a document and in three people’s heads, and the work is looking things up in four systems and typing the answer into a fifth.

You have a corpus nobody can search

Contracts, tickets, specifications, years of it. Search returns documents that contain the word; the question needs the document read. People give up and ask the one colleague who remembers.

You shipped an LLM feature and it stopped being impressive

It demonstrates well and fails on the long tail, and nobody can say whether last week’s prompt change made it better or worse — because there was never anything to measure it against.

The boundary

What the agent may do, written down before it runs

Not a prompt asking it to be careful. A prompt is a request, and a request can be argued with — this is data the system enforces.

Runs unattended

Reversible, or read-only.

Read a record
Search the corpus
Draft a reply for review
Propose a change
Run a report

Waits for a person

Costly, or visible outside the company.

Write to a system of record
Spend money
Contact a customer
Change an entitlement
Delete anything

Cannot reach at all

Enforced by the system, not requested in a prompt.

Anything not registered as a tool
Records outside the scope it was given
A write it already failed once
Another agent’s tools

The shape is ours; the contents are yours. Where each line sits is a decision you make in discovery and it is written down before anything runs — which is what makes it reviewable by the person who has to sign for it.

What we do

Named things, not capabilities

Every line below is something that exists when the work is finished — a service, an index, a check that runs in your pipeline.

Agents that act on your systems: MCP servers exposing your operations as named tools with typed arguments
Provider-portable loops — the model is a dependency, not the architecture
An approval boundary: what runs unattended, and what waits for a person
A record of every tool call, its arguments and its result
Retrieval that still answers at scale: pgvector with HNSW indexes — no separate vector database to run and keep in sync
Chunking and re-ranking tuned against your documents, not against a benchmark
Retrieval evaluated separately from generation, because they fail differently
Access rules applied at retrieval, so the model never sees what the reader may not
Evidence that a change is an improvement: An evaluation harness with a fixed regression set
A score on every change, in CI, before it reaches anyone
Cost and latency tracked next to quality, because all three move together

What you get

The things that are yours at the end

Objects rather than activities. Each of these is something you hold, in your own repository, whether or not we are still working together.

An MCP server in your repository

Your operations exposed as named tools with typed arguments, running in your infrastructure. It is a normal service you can read, test and deploy — not a black box with a vendor behind it.

The loop, portable

Written against a provider-agnostic interface, so changing model is a configuration change and a re-run of the evaluation set rather than a rewrite.

The written policy

What the agent may do alone, what it must ask a person for, and what it can never reach. Reviewable by someone who does not read code, because that is usually who has to sign it.

An evaluation harness

A fixed set of cases and a score, so the next change is measurable instead of argued about — and a regression fails the build rather than reaching a customer.

Stack

What this line is built with

Chosen per system rather than per company. Where two things sit together below, we treat them as interchangeable and pick on the day.

Agents and protocol: MCPAgent loopsLangChainLangGraph
Models: AnthropicOpenAIGeminiHugging FaceOllama
Retrieval: RAGEmbeddingsPostgreSQLMySQL
Numerics: PyTorchTensorFlowpandasNumPyscikit-learn

Engagement

How it runs, and how it is bought

Usually fixed scope through the first governed loop, then continuous delivery — an agent’s value comes from the second and third process it learns, and that is not knowable at the point of pricing the first.

Fixed scope

A defined deliverable, priced once — after discovery has said what it is, never before. What is in, what is deliberately out, and what we are assuming about your data and your deadlines is written down first.

Suits A first version, a migration with a known end, or a pilot with a decision at the end of it.

Continuous delivery

A team on your work month to month. A written update every week and a working build you can open — not a status percentage, the thing itself, running.

Suits A product still finding its shape, or a system that needs to keep moving after it launches.

Team extension

Engineers inside your team: your repository, your conventions, your release process, your stand-up. A good deal of our work is delivered this way, so it is a shape we have real practice at rather than one we are trying on.

Suits A team that knows what to build and is short of the people to build it.

01
Discovery
1–2 weeks
The process as it actually runs, the systems the agent would need to touch, and a first draft of where the approval line sits.
02
First governed loop
3–4 weeks
An agent running against your systems through registered tools, outside production, with the audit trail already on.
03
Evaluation in CI
alongside, from week one
A regression set and a score on every change. It is not a phase; a harness added at the end has nothing to compare against.
04
In production
6–10 weeks
Unattended for what the policy allows, queued for a person where it does not.

Indicative, and stated as ranges on purpose. What moves them is how many surfaces you need at once, how much of the existing system has to keep running, and how quickly decisions can be made on your side — never how many people we add.

Related work

Where this line has been used

All work

April 2024

SODVELONCON 2024

The 18th National Conference of the Society of Dermatologists, Venereologists and Leprologists of Nepal — Hotel Barahi, Pokhara.

A two-day national conference where registration, payment and attendance all had to work at once, in front of the delegates. Registration alone spanned nine delegate categories across three pricing tiers in two currencies, and once the doors opened the organisers needed to know who was in which hall, live, without a queue forming at any of them.

Web platform
Mobile app
Backend
UI/UX and graphics
On-site IT

Questions

Asked before, answered here

Which model do you use?

Whichever fits the task, and the choice stays reversible. The loop is written against a provider-portable interface, so switching is a configuration change plus a re-run of the evaluation set. Locking a system to one provider is a decision worth avoiding while it is still cheap to avoid.

Does our data go to a model provider?

Only what you decide to send. Retrieval runs in your infrastructure and access rules are applied there, so the model sees the passages your policy allows and nothing else. Where nothing may leave at all, open models run on your own hardware — it costs quality, and it is sometimes the right trade.

What stops it doing something expensive or irreversible?

It cannot call anything that has not been registered as a tool, and every tool declares whether it runs unattended or waits for a person. The boundary is data the system enforces, not an instruction in a prompt — a prompt is a request, and a request can be argued with.

How do we know it is getting better rather than different?

An evaluation harness with a fixed regression set runs in CI, and a change that lowers the score fails the build. Without one, every prompt change is a matter of opinion and the opinion belongs to whoever demoed it most recently.

We already have a RAG prototype that underperforms. Can you take it further?

Usually. The fix is rarely the model: it is chunking, re-ranking, and evaluating retrieval separately from generation so you can see which half is wrong. That diagnosis is normally the first week.

Start here

Tell us what you are building

Or what is breaking, or what has to go faster. You will get a straight answer from an engineer who would do the work.

Start a project