AI agents that build and check, with proof
For software teams who want AI agents doing real engineering work. We design and set up a pipeline of agents that research, build, review and test code in your repositories, with verification gates that tie every approval to what was actually inspected, so a broken check cannot quietly pass work through.
Service 08
No 17040048
Major build
From £15,000
Fixed quote after scoping
The price depends on the number of repositories, agents and gates. Model and infrastructure usage costs are yours and are estimated in the quote.
Who it is for
- Software teams and agencies that want AI agents opening, reviewing and testing pull requests, not just autocompleting code.
- Teams already using coding agents who have had a change slip through a check that should have caught it.
- Founders who want a small team to ship like a larger one, without losing control of what ships.
What the work covers
Agents with defined roles
A pipeline works best when each agent has one job and is judged on it. A typical design separates research, building, review and testing, so the agent that writes a change is never the one that approves it. Each role has written instructions, the tools it may use and a clear definition of finished. We agree the roles with your engineers at design, starting with the tasks where agents are most useful and least risky, such as dependency updates, test coverage or well-specified features, and add more only once the first ones run reliably.
Permissions limited to the task
Agents get the minimum access their role needs and nothing by default. A research agent may read code and documentation but not push. A build agent may open pull requests on a branch but not merge. Secrets, production systems and customer data stay out of reach unless you decide otherwise and the reason is written down. We set these limits in GitHub, your CI and the agent tooling itself, so they are enforced rather than requested in a prompt. If an agent misbehaves, the damage it can do is bounded by design.
Verification gates with Slipmark
A review is only meaningful if the thing approved is the thing that ships. Slipmark, our open-source GitHub Action, binds each agent approval to a hash of exactly what was inspected and refuses the merge if anything changed afterwards. We built it after a gate in our own nightly pipeline of more than 20 agents reported green for months while checking the wrong branch. When we pointed it at 23 open agent pull requests, it refused all 23. Gates do not prove the code is correct; they prove the approval still applies.
Behavioural locks
Some behaviour must never change without a person deciding it should: data isolation between customers, how money is calculated, who can see what. We write tests that lock that behaviour and make the pipeline treat any change to them as a stop, not a failure to be fixed automatically. An agent asked to make tests pass will sometimes change the test instead of the code. Locks prevent that for the parts of your product where a quiet change would be most costly, and they make your rules visible in the repository.
Humans approve the irreversible
Agents can draft, build, review and test at volume, but anything that cannot be undone needs a named person. That includes merging to your main branch where you choose, releasing to production, running migrations, changing permissions and deleting anything. We design the approval points so they arrive with the evidence a reviewer needs: what changed, what was checked and what the gates found. The goal is that your engineers spend their time on decisions that matter rather than reading every line an agent writes.
Monitoring and handover
A pipeline nobody understands is a liability, so the build ends with your team running it. We record what every agent did, which gates passed or refused and why, and set up alerts for the failures that matter. The runbook covers what to do when an agent stalls, a gate refuses or a model changes its behaviour. Your named engineer runs the pipeline with us, then without us, and we review it together after 30 days to adjust roles, permissions and gates based on what actually happened.
Typical pipeline patterns
These are illustrations of the kind of work, not client results.
Nightly research, build and review
Agents pick up agreed tasks, open pull requests, and a separate review agent checks them against your rules. Example only.
Approvals bound to what was checked
Every agent approval tied to a hash of the files inspected, and refused if anything changed before merge. Example only.
Behavioural locks
Tests that lock behaviour you never want to change silently, such as data isolation between customers. Example only.
What you get
Built on GitHub and your existing CI, with the AI models and coding agents you choose. Slipmark is open source under Apache-2.0, so nothing is locked to us.
- 01A pipeline design: which agents, which tasks, which tools and which humans approve what.
- 02The pipeline set up in your repositories and CI, with the agents' permissions limited to what they need.
- 03Verification gates using Slipmark, our open-source GitHub Action, or equivalent checks in your CI.
- 04Behavioural locks and test suites for the parts of your product that must not drift.
- 05Monitoring of what the agents did, and a runbook for when something fails.
- 06Handover, documentation and a review after 30 days.
What changes
- Agents doing defined engineering work in your repositories, with permissions you set.
- Approvals that are refused if the code changed after it was checked.
- The behaviour you care most about locked by tests that agents cannot quietly rewrite.
- A person approving every irreversible step, with the evidence in front of them.
- Engineers on your team who understand and run the pipeline themselves.
How it runs
- A 20-minute fit call and a short look at your repositories and CI, then a fixed quote.
- A written design of agents, permissions, gates and approval points, agreed before building.
- Built on one repository first, with regular working sessions with your named engineer.
- Handover with documentation and a runbook, then a review after 30 days.
What you supply
- Access to the repositories and CI involved, ideally starting with one.
- A named engineer who owns the pipeline on your side.
- Your rules: what agents may change, what needs human approval, what must never change.
Limits
- Agents need human ownership. We do not hand over a pipeline that nobody on your team understands.
- Verification gates prove that what was approved is what ships. They do not prove the code is correct; tests and review still matter.
- We do not promise a particular productivity gain. We agree what the pipeline must do and show you what it does.
How it works
- 01
Scope
A 20-minute fit call, then a short look at your repositories and CI. You receive a fixed quote.
- 02
Design
Agents, permissions, gates and human approval points agreed in writing.
- 03
Build
The pipeline set up on one repository first, with gates and locks, then extended.
- 04
Hand over
Your engineers run it with us, then without us, with documentation and a 30-day review.
We run one ourselves
Evidence from our own work
Our own nightly pipeline of more than 20 agents researches, builds, reviews and tests our products. When one of its gates was found checking the wrong branch, we built and open-sourced Slipmark to make it impossible to miss again. This is our own engineering, not a client result.
The gate that reported green for monthsWhere it fits
A Control Review of an existing agent setup often comes first; once the pipeline is handed over, monitoring keeps the gates and agents under watch.
Questions before you start
How much does an AI agent pipeline cost?
From £15,000 as a fixed quote, depending on the number of repositories, agents and gates. Model and infrastructure usage is separate and estimated in the quote.
Which coding agents and models do you use?
The ones that suit your team and your data rules. We agree them at design, and the pipeline is built so they can be changed later.
Will the agents have access to production?
Not unless you decide they should, and never by default. Agents get the minimum permissions their tasks need, and anything irreversible needs a person.
What is Slipmark's role?
Slipmark is our open-source GitHub Action. It binds each agent approval to a hash of what was inspected and refuses if anything changed, so a stale approval cannot ship.
What is the next step?
Tell us about your repositories and what you want agents to do in the contact form. We arrange a 20-minute call and send a fixed quote.
Can we start with one repository?
Yes, and we recommend it. We set the pipeline up on one repository first, with its gates and locks, and extend it once your team is comfortable with how it behaves. The fixed quote reflects the scope agreed.
What happens to our code and data?
It stays in your repositories and CI, and goes only to the AI models and agents you approve. We agree data rules at design, including which models may see which code. Model and infrastructure usage is on your accounts, estimated in the quote.
Do we need Slipmark, or can we use our own checks?
Either works. Slipmark is open source under Apache-2.0 and is our default for binding approvals to what was inspected. If your CI already has equivalent checks, we use or extend them instead. What matters is that a stale approval cannot ship.
Tell us what needs to work better.
Describe the process and the tools involved. If it looks like a fit we will arrange a 20-minute call.