Step 01 · Discovery
Read the estate
Before anything is designed we establish what actually runs the business: which systems hold the system of record, what they cost to run, where the data physically lives, which integrations are load-bearing, and what may not be touched under any circumstances.
This is deliberately unglamorous and it is where most of the risk gets removed. A transformation that surprises itself in month three usually skipped this. We write it down and hand it over, because it is useful to you even if we never work together again.
You keep an estate map — what runs, what it costs, what is untouchable
Answers the question every later step depends on
Step 02 · Data engineering
Provision the data
The pilot ran on an extract somebody built by hand. Production cannot. This step builds the data layer the system will actually read: pipelines with contracts on the fields that matter, a retrieval path designed for the question being asked rather than for a demo, and lineage from the answer back to the row it came from.
Crucially, it also assigns ownership. A data contract names who decides what a field means. Without that, every disagreement about a number becomes a meeting instead of a lookup.
You keep data contracts, a pipeline spec, a retrieval path, named field ownership
Answers failure 1 — the data was never provisioned
Step 03 · System architecture
Architect the system
The target architecture gets drawn beside the legacy one, with the boundary between them named explicitly. Services, gateways, and the seams where the new system reads from and writes back to the estate.
Then the numbers, before the build rather than after: throughput, p99 latency, capacity ceiling, cost per request, and what the system is supposed to do when it exceeds any of them. Ten questions a day and ten thousand a day are different systems, and which one you are building is a decision, not a discovery.
You keep a migration architecture note with capacity, latency and cost budgets on the page
Answers failure 2 — the infrastructure cannot hold it
Step 04 · Agent harnessing
Harness the agents
An agent is scoped to one job with a stated boundary, given a tool and authority model that says exactly what it may reach and who approved that, and wrapped in an evaluation harness that runs before every change rather than after every incident.
Anywhere the action is irreversible, a named human checkpoint sits in front of it. Not a review queue in principle — a person, named, with the authority to stop it. Every run can be replayed from its inputs, so a failure can be reconstructed instead of guessed at.
You keep agent design, an authority model, an evaluation harness, named checkpoints
Answers the question you will be asked in month two — what happens when it is wrong
Step 05 · Security engineering
Secure the boundary
Application security assumes a user behind every action, and an agent breaks that assumption. It is a principal with credentials, a tool list, and an input channel an attacker can write to directly.
So: least privilege on every tool grant, reviewed as a change rather than issued as a default. A threat model that includes the prompt that is itself the attack. Identity for software, separate from the human identity it acts on behalf of. Model provenance — what ran, which version, on what. And keys you hold, in your infrastructure.
You keep a threat model for software that acts, least-privilege grants, provenance records
Answers failure 3 — security has no model for software that acts
Step 06 · System architecture
Run it under load, with a way back
The system is load-tested against your real traffic shape, not a synthetic average. Observability goes on before launch rather than after the first incident. Cost per decision is measured and known, so the inference bill stops being a surprise.
And the rollback to the legacy path is built, tested, and left in place. Cutover is not a date on a plan; it is a switch that keeps working after it has been thrown. This step is the entire reason the sentence below is allowed to exist.
You keep load-test results on your system, observability, cost per decision, a rollback and cutover plan
Answers failure 4 — the legacy estate does not move
