Agentic Operations
The process that currently eats a person’s week runs itself — correctly, on the record, and with your team in the loop exactly where you want them.
6 weeks from kickoff
elapsed
50% now to book the start, 50% on completion. Priced and charged in US dollars.
How far do you want to take it?
Every process after the first is cheaper, because the platform it runs on is already built and already yours.
One process1 of 6 — drag for more
The process that costs you the most time, running end to end. Proves the platform on the work you already know the shape of.
Total
$70,000 USD
Web
6 weeks from kickoff
What you pay, and when
- Due today50% — books the start
- $35,000 USD
- On completion50% — at handover, nothing withheld
- $35,000 USD
- Total
- $70,000 USD
Secure checkout by Stripe. Card details never reach this site.
Who it is for
A process eats a person's week, the rules are knowable, and you want it handled rather than demonstrated.
Not for you if
You want to find out whether agents are useful. That is a pilot, and a pilot should cost less than this.
The same process, before and after
Nothing about the work changes. What changes is who is waiting on it.
Today
Two to three days, and a slice of somebody’s every morning.
With Agentic Operations
Minutes, unattended — and your team sees only the exceptions.
What happens on a single case
Two ways out, and only one of them needs a person.
↳ When it is not sure, or the rules say ask
Either way, it is on the record: what came in, what was decided, which systems were touched, what it cost.
What you get
In detail
The hours come back, and they stay back
The point of this is not that agents are clever. It is that a process which currently consumes a person’s week stops consuming it — permanently, not for the length of a pilot. We start by watching the work as it is actually done, then draw a line: what runs without anyone, what waits for a person, and what the system must never touch on its own. That line is agreed before anything is built, and it is what makes the time saving real rather than notional.
It is right, and you can prove it to someone who doubts you
Before we build, we take a set of your real past cases and agree with you what the correct outcome was for each. That becomes the score. Every change is measured against it, and a change that makes the system worse does not ship. When your finance director asks how accurate it is, you have a number and the workings, not an impression.
It cannot do anything you have not allowed
Spending limits, rate limits, an explicit list of actions that touch the outside world, and a shape every output has to fit before it leaves the system. Where the process reads anything a stranger wrote — an inbound email, a form, a document — it is handled as untrusted. You are not relying on the model choosing to behave.
Your people judge only what needs judgement
Anything that spends money, contacts a customer, or cannot be undone stops and waits for a person. So does anything the system is not confident about. What your team gets is a short queue with the case already assembled — the context, the recommendation, the reasoning — so a decision takes seconds instead of a reconstruction. Everything else simply completes.
You can see what it did, and what it cost
Every run is recorded end to end: what came in, what it decided, which systems it touched, what it produced. Cost is attributed per case, so you can answer what it costs to handle one — and compare that to what it used to. Alerts when the failure rate, the spend or the latency moves, because a system that quietly gets worse is more dangerous than one that stops.
It keeps running on a bad day
Systems go down, formats change, providers deprecate models. The process is built to survive all three: a step that half-finishes is undone cleanly, a run interrupted mid-way resumes rather than restarting, and a failure that needs a human raises its hand instead of failing silently. You should be able to stop watching it, which is the whole point.
It works with what you already have
Your CRM, your database, your ticketing, your inbox — reached directly, each with its own credentials and only the access it needs, read-only wherever reading is enough. No migration, no replacement system to adopt, and no new place for your team to go and look.
It is yours, and it does not need us
It runs in your accounts on your keys from the first day, so the bill is visible to you throughout and nothing has to be moved at the end. You get the repository, the written runbooks for the things that will eventually happen, and a session with the people who will operate it. If you never speak to us again, it keeps running.
The boundary
What the price covers, in numbers
A fixed price with an unbounded scope is not a price. These are generous enough that almost every honest brief fits — they exist so the one that does not is recognised now rather than in week two.
- Processes
- One process, carried end to end and properly. A second is a second engagement, and is cheaper than the first because the platform already exists.
- 1
- Agents in the orchestration
- Specialised steps with distinct responsibilities. More than six usually means the process was not decomposed, and we will say so at the scope stage.
- Up to 6
- Tool integrations
- Each with its own credentials and permission scope. Systems with no API, or that require a bespoke connector, are quotable rather than included.
- Up to 6 systems
- Evaluation cases
- Drawn from your real history and labelled with you. The harness is yours to extend; the first hundred are ours to build.
- 100 seeded, extensible
- Expected volume
- Sensible batching, caching and rate limits. Architecture for a volume you have not reached is a cost with no return and is not included.
- Built for thousands of runs a month
- Rounds of changes
- Within 30 days of handover. Anything that does not match the scope document is a fix, not a round.
- 2
- Model and API costs
- Runs on your provider accounts and your keys from day one, so the bill is visible to you throughout and nothing has to be migrated at the end.
- Yours
The week
What actually happens, in order
- Weeks 1–2Discovery. The process mapped as performed, the agent boundary agreed, the evaluation set labelled with your team. Ends in a scope document naming what is being automated and what is explicitly not. Nothing is built before you approve it.
- Week 3Orchestration skeleton and tool integrations. State, routing and retries running end to end against your systems in a sandbox, with tracing on from the first run.
- Week 4The reasoning steps, against the evaluation suite. Quality is a number from this point on, and you can see it.
- Week 5Guardrails, approval queue and audit. The failure paths: a tool down, a malformed output, a run that must be replayed.
- Week 6Shadow running against live work with a person reviewing every decision, then cutover at whatever autonomy you are comfortable with. Runbooks, handover, training. Balance falls due; the repository transfers.
- Within 30 daysYour two rounds of changes.
Finished means
When it counts as delivered
- — The process runs end to end in production, on your accounts and your keys
- — The evaluation suite passes at the threshold agreed in the scope document, and runs on every change
- — Approval gates, spend caps and the audit trail are working, including their failure paths
- — Tracing shows every step, tool call and token, with cost attributed per run
- — Runbooks exist for model deprecation, tool outage and run replay; a handover session has happened
- — The repository is transferred and deploys from your account
Never at this price
Out of scope, however it is asked for
- — Training or fine-tuning a model on your data
- — A second process, however similar it looks to the first
- — Model, API, and infrastructure costs, which stay yours and stay visible
- — Anything requiring a connector to a system with no API
- — An accuracy guarantee — the threshold is agreed and measured, not promised
- — Ongoing operation of the system after handover
If it changes
How a change is handled
The scope document is the agreement
One page, approved by you before anything is built, naming what is in and what is not. If something is not on it, it is not in the build — not as a refusal, but so that both of us know what was agreed when we are three days in and busy.
A brief bigger than the tier is caught at the scope stage
That is what the stage is for. You will hear it before you have waited a week, not after. Then it is your choice: cut it back to fit, move up a tier and pay the difference, or take a refund. Nothing has been lost but a conversation.
Changes during the build are quoted, not absorbed
Wanting something different once you see it is normal and welcome. It is also new work: it gets an estimate and a date before it starts, and it never quietly displaces something already agreed. A change that fits inside the scope in exchange for something coming out is free — that is a trade, not an addition.
A fix is not a change
If it does not do what the scope document says, that is a defect and it gets fixed at no cost and without spending a round. Rounds are for things you have changed your mind about.
The limits above are the boundary of the price
Not a refusal to do more. Beyond them is simply a bigger job, quoted as one — which is fairer than pretending a five-day week can absorb a five-week brief.
How it runs
01 You pay half and take a slot
Prices are on this page, not behind a call. Half up front reserves a build week — only a couple run at a time, which is why the dates are real and why the slot is what you are actually buying.
02 You send the brief
A few questions, plus anything you already have: designs, reference URLs, a spreadsheet of how it works today, access to whatever it has to connect to. Ten minutes, and it is the ten minutes that decides how this goes.
03 The scope is agreed in writing
One page: what is being built, what is explicitly not, and the date. You approve it before anything is written.
04 You see it early
A working URL well before the end, not a reveal at the finish. Changes are cheap while it is being built and expensive afterwards, which is the entire reason you see it early.
05 Handover
The balance falls due, the repo transfers to you and it goes live under your own account. Then your round or rounds of changes.
What to bring
A clear idea of which part is being built
Not the whole roadmap — the piece. Knowing that this build is the booking flow and not the billing is worth more than any technical vocabulary.
The detail behind it
The rules that live in your head: who is allowed to do what, what happens on the awkward Tuesday, the customer who always asks for the exception. That context is the difference between something that works and something that demos.
Coding knowledge, if you have it
Helpful, never required. It makes the review conversations quicker and it means the handover documentation lands sooner. Plenty of people buy a build having never opened an editor, and it goes fine.
One person who decides
Somebody who can answer a question the same day. Most delays on a short build are not technical.
Start a Agentic Operations
Tell us what it has to do and who uses it. If the brief is bigger than this tier we will say so before you pay, not in week two.