A production agent system running in your own cloud account, owned by you, tested against a written standard before you are asked to sign anything off.

Before anything is built or billed, we write down what working means as numbers: task success rate against an eval set built from your real cases, p95 latency, cost per task, uptime target, and the required behaviour when a model or an upstream API misbehaves.

That document is the scope. If it is not on the document it is not in the build.

$9,000 is the price for a scope of that shape. A wider one is quoted the same way, from the same written process, before anything starts.

One workflow, a named set of agents, and a named list of integrations, endpoint by endpoint

Agent architecture: responsibilities, handoffs, shared state, escalation to a human

The backend services, queues and data stores that workflow needs

Integrations against the named systems, through the APIs they already expose

Containerised deployment defined entirely in infrastructure-as-code

Tracing on every step, plus an eval and regression suite you run yourself, wired into CI

Fixing anything that misses the written acceptance criteria. That is mine, not an extra

A second workflow, or a second agent set. Each is priced as its own build

Integrations not named in the scope document, including ones discovered part-way through

Building or changing an API on your side that the agents need to call

Frontend and UI beyond what the workflow itself requires, and design work

Model training, fine-tuning and data labelling

Migrating your existing systems, data or infrastructure

Ongoing operation after handover, which is the retainer

Anything on that second list can be added. Change orders are written, not whispered: an addition is scoped, given its own acceptance criteria and its own fixed price, and put in front of you before it is built. It is priced on the same basis as the original scope — additions do not carry a mid-build premium for being inconvenient — and the quoted price does not move once you have agreed it.

If an addition is large enough to change the shape of the build, work pauses and the remaining scope is repriced in writing rather than absorbed quietly. Nothing is ever billed to you afterwards as an overrun. Overruns inside the boundary are mine.

The repository, in your organisation, with the full history

Infrastructure-as-code and deploy scripts. The whole system redeploys from that repository into a clean cloud account; nothing lives only on my machine

Architecture decision records: every trade-off taken, the option rejected, and why. This is the part that lets a stranger pick the system up

A runbook for the failure modes that are actually likely, written against the alerts you will really get

The eval suite and the acceptance document, so you can re-run the exact test that signed the work off, whenever you want, without me

A recorded end-to-end handover walkthrough, so the reasoning survives the people who happened to be in the room

A 30-day stabilisation window after sign-off: bug fixes on delivered scope, included. This is part of the build, not a reason to buy the retainer

Three phases, each ending in a working demo and a test against the criteria that phase was meant to satisfy: the standard and the environment agreed, then the system running end to end against your real cases, then the measured pass, the cost tuning and the handover.

Milestones are funded through escrow one phase at a time, so you are never exposed for more than a single phase.

It is not signed off and that milestone is not billed. I keep working until it passes, at no additional cost. The price is fixed because I carry that risk, not you.

Two honest limits on that. If a target turns out to depend on something outside the system I built — an upstream API's latency, a provider repricing, data quality on your side — it is re-baselined in writing rather than quietly missed. And if a criterion cannot be met at all, you stop, you owe nothing further, and you keep the repository, the infrastructure-as-code, the decision records and the eval suite built to that point.

I am one engineer, and the person who reads your code is the person who writes it. You should assume I could become unavailable mid-build, and you should not have to take my word that it would be fine. The answer is not a promise. It is the list above, in your repository, from the first commit, plus escrow.

To start: message me with the workflow you want automated and what "working" means for it in numbers. If you cannot put numbers on it yet, start with the audit — that is what it produces.