HOW WE WORK
Our AI agent implementation process runs in seven stages, and you can stop after any of them. Each stage ends in something you can hold: a document, a working prototype, a measured baseline. Nothing moves forward on enthusiasm.
What an AI agent implementation process should look like
An AI agent implementation process is the sequence that takes a business workflow from “we think this could be automated” to an agent doing it in production under a written autonomy boundary. Ours has seven stages, four of which end in a decision you make rather than a deliverable we hand over.
Most AI projects fail somewhere between a working demo and a system anyone trusts. The demo is easy, because a demo runs on chosen inputs and a forgiving audience. Production runs on your real queue at 3 a.m.
So the stages below are arranged around the two things that decide the outcome: measuring on real data early, and agreeing what the agent may do alone before anyone writes the code that lets it.
Seven stages, and what each one owes you
Stage 0 · Scout - readiness audit
timing: Typically 3-10 days what happens: We map the workflows you are considering, the data behind them and the systems they touch, then score every candidate on value, feasibility and risk. We interview the people who actually run the process, because the documented version and the real version are rarely the same document. deliverables: Readiness report · scored automation backlog · recommended first agent · a “not yet” list your decision: Whether to build anything at all, and which process goes first. link: AI Readiness Audit
Stage 1 · Blueprint - architecture and boundaries
timing: Typically 1-2 weeks what happens: We write down the agent roles, the orchestration flow between them, the autonomy boundary for each one, the escalation paths, the integration map, the eval criteria and the success metrics. All of it is agreed before any code exists, because a boundary added after an incident is a policy, not a design. deliverables: Agent architecture · integration map · governance model · success metrics your decision: What each agent may do alone, and what always comes to a person. link: Agent Orchestration
Stage 2 · Prototype - prove it on real data
timing: Typically 2-4 weeks what happens: One agent, running on your actual inputs, measured for accuracy, latency, cost per task and behavior at the edges. This is where a plausible idea becomes a number. It is also where we have told clients to stop, because the measured accuracy did not justify the build. deliverables: Working prototype · feasibility report · accuracy and cost baseline your decision: Whether the measured result is worth the production build.
Stage 3 · Forge - production build
timing: Typically 3-8 weeks what happens: Production integrations, the orchestration layer, retries and fallbacks, observability, secrets handling and the deployment pipeline. The unglamorous half of this stage is error handling for systems that fail in ways their documentation does not mention. deliverables: Production hive · CI/CD · monitoring · runbook your decision: Sign-off on the integration surface and the credentials each agent holds. link: See the platform underneath
Stage 4 · Guard - evals and governance
timing: Runs in parallel with stage 3 what happens: Eval suites, quality gates, approval workflows, audit logging, drift detection, cost ceilings and kill switches. Built alongside the system rather than after it, so the gates exist on the day the agent first touches production. deliverables: Eval suite · audit trail · governance dashboard · escalation policy your decision: The pass rate an agent must hold to keep its autonomy. link: Trust and governance
Stage 5 · Release - controlled rollout
timing: Typically 1-2 weeks what happens: Shadow mode first, where the agent does the work and a person does it too, and the two are compared. Then assisted, where the agent proposes and a person approves. Then autonomous, once the pass rate holds across a full cycle of your real volume. deliverables: Staged rollout · performance baseline · training for your team your decision: When each agent moves up a rung, based on its own numbers.
Stage 6 · Tend - run and improve
timing: Ongoing what happens: We watch the evals, swap in cheaper models that still clear the bar, repair drift, and add agents as new candidates surface from the backlog. Models change under you whether or not anyone is watching, which is the entire argument for this stage existing. deliverables: Monthly performance report · optimization log · roadmap for the next agents your decision: Whether to keep this with us, take it in-house, or split it. link: Managed AI Workforce
DECISION POINTS
Four places you can stop
The process is designed to be exited. Each gate below is a real off-ramp with a deliverable already in your hands, not a renegotiation.
| Gate | After | You are deciding | What you keep if you stop |
|---|---|---|---|
| Go / no-go | Stage 0 | Whether any process here is worth automating | The readiness report and the scored backlog |
| Design sign-off | Stage 1 | Whether the architecture and the boundaries are right | The blueprint, which another vendor could build from |
| Feasibility | Stage 2 | Whether the measured accuracy and cost justify a build | The prototype and its measured baseline |
| Autonomy | Stage 5 | Whether an agent has earned the next rung | Whatever level of autonomy it has already held |
WHERE YOU ARE NOW
Five levels between manual work and an autonomous hive
- What it means
- Skilled people do the whole process by hand, in whatever tools they already have.
- What it requires
- Nothing. This is the starting point for most teams.
- What it returns
- Full control, no leverage. Capacity rises only when you hire.
- What it means
- People still own the process, but a model drafts, summarises or classifies inside it.
- What it requires
- Access to the tools people already use, and a written limit on what the model may draft.
- What it returns
- Hours back on drafting and reading. The queue is still cleared by a person.
- What it means
- One narrow task runs end to end without a person, with an approval gate on anything irreversible.
- What it requires
- A readiness audit, one integration, an eval suite and an escalation path.
- What it returns
- One task type off the queue permanently, with a measured cost per task.
- What it means
- An orchestrator splits a whole process into tasks, dispatches specialist agents and retries what fails.
- What it requires
- Agent roles, autonomy boundaries, observability and a repair path agreed at the blueprint stage.
- What it returns
- A process that finishes rather than a step that completes. Coverage stops depending on shifts.
- What it means
- Agents watch themselves and each other, detect drift, repair known failures and escalate the rest.
- What it requires
- Continuous evaluation, cost ceilings, kill switches and a monthly review of what changed.
- What it returns
- Most failures are repaired before anyone notices. People handle exceptions and judgment calls.
YOUR SIDE OF IT
What the process asks of your team
One process owner
The person who knows how the work actually runs, for a few hours a week. This is the single largest predictor of whether a build lands on time.
Read access, early
Sample data at stage 0 and real data at stage 2. Redacted is fine.
Someone who can approve credentials
Integration work stalls on access, not on engineering.
A reviewer during release
Shadow and assisted modes need a person comparing outputs. It is a few hours a week for a few weeks, and then it stops.
A decision at each gate
We will bring the evidence. We cannot make the call.
HONESTLY
The limits, stated up front
We do not start building in week one. The audit exists because the expensive failure in this field is a well-built agent doing the wrong job, and that failure is invisible until month four.
We do not promise a percentage before stage 2. Any number offered before your data has been measured is a guess with a decimal point on it.
We do not automate judgment. Where a task turns on relationship, negotiation or a call a person has to own, the honest recommendation is L1 or L2, and we will say so at the gate rather than after the invoice.
We also cannot move faster than your access approvals. If credentials take six weeks, the build takes six weeks longer, and no amount of engineering changes that.
Frequently asked questions
How long does the whole process take?
Typically under 30 days from the start of the audit to an agent doing real work on a narrow task, and 3-6 months for a broad, cross-system process with several agents. The variables are your data access, the number of systems involved and how many exceptions the process carries. Stage 0 gives you your own figure rather than this one, which is most of the reason it exists.
Can we start at stage 3 - we already know what we want?
Sometimes, and we will say so if the case is clear. What we will not skip is stage 2. Measuring one agent on your real data costs a few weeks and has repeatedly changed what gets built. Skipping the blueprint is the more expensive shortcut, because autonomy boundaries retrofitted after a release tend to be written by an incident report.
What happens if the prototype fails?
You get the feasibility report, the measured baseline and a recommendation, and the engagement ends there if that is the right answer. A failed prototype is a cheap result. It tells you the process is not ready, or the data is not reachable, or the accuracy bar cannot be met at a cost that makes sense yet.
Who owns what we build?
You own the agents, the configuration, the eval suites and the runbooks, and they are yours whether or not we keep operating them. We build to hand over by default. Ownership terms are set in the engagement agreement, which is where they belong rather than on a marketing page.
Do you work alongside our engineers?
Yes, and it is the usual shape after stage 2. Your engineers know the systems, the failure modes and the politics of the integration surface. We tend to own the orchestration layer, the evals and the agent design, and hand over progressively during stage 6.
What does "self-optimizing" actually mean in stage 6?
Something narrow and measurable. We hold an eval suite for each agent, sample live traffic against it, and try cheaper or faster models on that suite before switching anything. When a smaller model clears the bar, it takes over and cost per task falls. When quality drifts, the alarm fires before anyone opens a ticket. It does not mean the system rewrites itself.