Every change has an owner and checks that can fail
We build with AI coding agents inside a harness we maintain. A person on our side owns each piece of work and decides when it ships. The same rules hold for our own products and for client work. A client agent project then runs in three stages, from discovery to daily use run by your own team.
- Discovery
- A trial agent that asks first
- Grow and run
- Handed to your team
AI does much of the typing. People and tests decide what ships
Building with AI is fast, and it is easy to get wrong. Four rules let us keep the speed and catch the mistakes before they ship, in our own products and in every client project.
A person owns the work
AI coding agents work inside a harness we maintain: written project rules, and a plan, build and review pipeline. A person sets the plan, reads the result and decides what ships. The agent does not decide that.
Tests decide when a change is done
Every change runs through tests, type checks and a build gate before it is merged. The agent that wrote the change does not judge it. If a check fails, the work is not done, whatever the agent reports.
A fresh reviewer tries to break each change
A second reviewer starts in a fresh context, with none of the builder’s working notes. It tries to break each change before it lands. Each finding is checked again before anyone fixes it, so the real problems stand out.
Parallel agents never write to the same file
When several agents work at once, each one writes only its own state file, in its own copy of the code. The pipeline is designed so that no file has two writers.
A client project runs in three stages. Each one ends with something you keep
Discovery
We sit with the people who own the work and the data, and choose one task where an agent is worth building. We list every system it touches. We agree what success looks like, which actions a person approves, and what the agent must never touch. If an agent is the wrong tool, we say so and name what would work instead. The scope of this stage is agreed in writing before it starts.
Approves We agree which actions need a person to approve them, and who that person is.
You receive- A written yes or no on going ahead, with the reasons
- A map of the systems, data and access the agent needs
- The points where a person approves, agreed with the people who will approve
- A first set of test cases, taken from your real work
A trial agent that asks first
One agent works on one task with your real data, in live use. Every action that matters waits for a person to approve it, so the agent earns trust on real work first. We check each change to the agent against the test cases. If the trial shows the approach is wrong, we change course and tell you why.
Approves Every action that matters waits for a person to approve it.
You receive- A working agent in your own code repositories, on your own servers or cloud
- Secure connections to the systems it uses, each limited to what it may do
- A record of every step it takes, and an audit log
- Its results on the test cases, and our advice on whether to grow it
Grow and run
We add tasks at a pace your teams can handle, on the same connections and controls. We remove an approval step only where the results support it and the approver agrees. We monitor the agents, track their cost and run the tests. Your engineers take over the running step by step. Ongoing support is a separate contract, and we promise nothing outside it.
Approves An approval step is removed only where the results support it and the approver agrees.
You receive- More agents on the same connections and controls
- Monitoring, cost tracking and a regular review of test results
- Operating guides, documentation and the test cases
- Engineers of your own who run it without us
Every agent we build for a client comes with four things you keep
They let you trust an agent on real work, and they let your own team take it over.
- Test cases from real work
- Before we build an agent, we collect real cases from your work, each with its right answer. We agree them with the people who do the work today. Every change to the agent is tested against them. The test cases are yours.
- A record of every run
- Every step, every tool call and every decision goes into the run log. When an agent gets something wrong, you can see which step failed and why. So can your auditors.
- Approval points agreed at the start
- Which actions wait for a person, and which person, is decided with you in discovery and written down. The agent cannot skip an approval point. Changing one is your decision.
- A handover your team runs
- We write the operating guides, the documentation and the test cases for your engineers. The handover ends when your team runs the agent and changes it without calling us.
On a client project, you own everything from the first line of code
- The agents, their instructions, connectors and test cases, in your own code repositories
- Your servers and cloud, in your own accounts, so nothing needs moving later
- Your data: we do not train on it, and we keep no copy after handover
- The records and audit logs of every run
- Documentation written so your engineers can take it over alone
- If you stop working with us, everything keeps running
When an agent is the wrong tool, we say so
We tell you in the first conversation when an agent does not fit. These are the four usual reasons.
Work that never changes
If a process always runs the same way, a simple script or a task queue does the job. We recommend the script, even where an agent would be the bigger contract.
Missing data
An agent cannot make up for data an organisation does not have. That is a data project first, and we plan it as one.
Guaranteed answers
If every answer must be proven correct with no person checking it, today’s AI models cannot promise that. We design the step where a person checks, and we tell you what risk remains.
Timelines that skip testing
If the date only works by cutting the checks, we say so before the work starts.
Tell us the workflow. We will say whether an agent belongs in it
A few lines on the work and the systems it touches are enough. Our first reply says what Discovery would cover for that workflow.
Start a project