First 90 Days of an AI Agent Rollout: A Practical Playbook

Most agent systems that get built never make it to production. The ones that do, almost always take longer than the team planned, cost more than the budget allowed, and ship with a smaller scope than the original proposal.

This is not because the technology isn't ready. It is because the rollout is treated as an engineering project when it is, at least as much, a process and an organizational change. The teams that ship agent systems in production are the ones that treat the rollout as a structured 90-day programme with clear phases, clear deliverables, and clear failure modes at each stage.

This is the playbook we use when we run a rollout with a client. It is opinionated. It will not fit every organisation. It is the pattern that has produced the most reliable results.

The pattern that fails

Before describing the playbook, it is worth describing the pattern that produces the failures. It looks like this.

The team identifies a workflow. It looks like a good candidate — repetitive, document-heavy, frustrating for the operators. Someone writes a proposal. The proposal is approved because the workflow is real and the projected ROI is plausible. Engineering starts building. Six weeks in, the demo works. Eight weeks in, the pilot starts. Ten weeks in, the pilot is producing more exceptions than the original manual process, the operators are working around the system, and the eval suite shows the model is making confident wrong decisions on 12% of cases that everyone agrees are routine. Twelve weeks in, the project is "paused for re-evaluation."

The pattern is consistent: weak scoping, a demo that is not a system, no review path, no eval suite, no operator voice. Each of these is a fixable mistake. Together, they reliably produce a rollout that does not stick.

Phase 1: Days 1–30 — Scoping and process mapping

The first 30 days are not about building. They are about making sure the thing you are about to build is the right thing.

Pick one workflow. Not three. Not a platform. One workflow, end to end. The teams that try to ship a "foundation" plus multiple workflows in the first quarter reliably ship neither. Pick the workflow with the highest ratio of value to complexity, where value is measured in operator hours saved or error rate reduced, and complexity is measured in the number of systems the workflow touches and the number of exception cases it has.

Document the actual process. Not the documented process — the actual one. Interview the operators. Watch them work. Map every step, every decision point, every exception case, every workaround. The output is a process document that any two operators on the team would agree on. If you cannot produce that document, the workflow is not ready to be automated, and Phase 1 should not end until you can.

Map the exception paths. Every operational workflow spends most of its time on the exception cases, not the happy path. Identify the top 20% of cases that account for 80% of the operator effort. The agent system will handle the easy cases automatically. Those exception cases are what the system needs to route to a human — and the routing is what the system is. If you have not mapped them, you have not understood the workflow.

Define what success looks like. Write down, in numbers, what the rollout is supposed to achieve. Operator hours saved per week. Error rate reduction. Time-to-completion. Whatever the metrics are, they should be measurable from existing data, and they should be agreed on by the people who will own the outcome. If success is defined as "the operators like it," it will never be measurable. If success is defined as "we reduce review time from 4 hours to 30 minutes per case, and the team can absorb 30% more volume without hiring," it can be measured and tracked.

By the end of Phase 1, you should have a workflow document, an exception map, a definition of success, and a clear answer to the question: is this workflow actually a good candidate for an agent system? Sometimes the answer is no. That is a successful Phase 1.

Phase 2: Days 31–60 — Build the smallest system that works

The second 30 days are about building the smallest end-to-end system that can handle a real case in production. Not a demo. Not a prototype. A system that runs against real data, produces real output, and has a real review path.

Build the review UI before the automation. The instinct is to build the agent first and the review interface later. The instinct is wrong. The review interface is the system. The operator's job is to handle the cases the agent cannot, and that interface is what they will use to do it. If the interface is good, the system works. If the interface is bad, the system does not, regardless of how good the agent is.

Write the eval suite before the demo. The eval suite is the contract between the engineering team and the operations team. It specifies what the system has to do to be considered ready for production, on the cases that actually matter. It should be runnable in CI, with a defined pass threshold, and it should be reviewed by the operators who own the workflow. A demo that does not pass the eval suite is a prototype, not a system. A system that passes the eval suite is ready for the pilot, even if the demo is rough.

Build for the exception, not the happy path. The happy path is the easy part. The exception path is where the system earns its keep. Every exception case identified in Phase 1 should have a defined handling: does the system route to a human, does it ask the operator a clarifying question, does it return a structured error, does it escalate to a senior reviewer? If the exception handling is not designed, the system will fail on the cases that matter most.

Tighten the policy envelope. The agent should only operate inside a defined envelope: specific cases, specific actions, specific outputs. Anything outside the envelope pauses and routes. The envelope is enforced in code, not in the prompt. A prompt that says "be careful" is not a policy. A function that rejects out-of-envelope actions is a policy.

By the end of Phase 2, you should have a system that runs against a real environment, with a real review interface, a passing eval suite, and a defined policy envelope. It does not need to handle every case. It needs to handle the easy cases correctly, route the hard cases to a human, and produce a record of every decision it makes.

Phase 3: Days 61–90 — Pilot, measure, and tighten

The third 30 days are about running the system in production, on real cases, with real operators, and learning from what it does.

Run on real cases, not curated ones. The pilot has to be on the actual cases the operators see, not a curated set that makes the system look good. The point of the pilot is to find the cases the system cannot handle, the cases where the review interface is awkward, and the cases where the model is confident and wrong. Those cases are the work for the next quarter.

Measure disagreement, not just errors. A system that produces 95% correct output and 5% wrong output is not the same as one that produces 95% correct output and 5% contested output. The first is a model that fails on a defined subset. The second is a model that fails on the cases operators disagree about, which are the cases where human review actually adds value. Both numbers matter. The disagreement rate is the more useful one for tightening the review path.

Tighten the envelope based on data. The policy envelope at the end of Phase 2 is a hypothesis. The pilot data tells you where the hypothesis is right and where it is wrong. Some cases the system handled automatically should have been routed to a human. Some cases that were routed to a human could have been handled automatically. Both are useful. The envelope gets tightened based on the evidence, not on intuition.

Resist the urge to scale. The end of the 90-day programme is not the time to roll the system out to the whole organisation, or to add the second workflow, or to declare victory. It is the time to consolidate: fix the rough edges, update the documentation, train the next group of operators, and make sure the system is operating reliably at the current scope. Scaling before consolidation is how good agent systems become fragile ones.

By the end of Phase 3, you should have a system in production, operating at defined scope, with a defined review path, a maintained eval suite, and a clear picture of what it does well and what it does not. That is a successful 90-day rollout.

The common failure modes

These are the failure modes that show up across rollouts, regardless of industry or workflow.

Picking the wrong workflow. The workflow was picked because someone senior flagged it, not because the operators agreed it was the right candidate. The result is a system that solves a problem the operators do not have. Fix: pick the workflow with the operators, not for them.

Optimising for the demo. The team builds what looks impressive in a sales demo, not what works in production. The demo flows. The production cases include edge cases, malformed inputs, and ambiguous language. Fix: write the eval suite first, run the system on real data, and refuse to ship a system that does not pass.

No operator voice. The system was designed by engineers for operators, with limited operator input. The interface is built around the data model, not the workflow. The operators work around it. Fix: the operators are part of the design process from Phase 1, not a stakeholder to brief at the end.

Hiding errors. The system produces errors. The team hides them, smooths them, routes them silently. The operators find out about a problem only when it shows up in a customer interaction. Fix: every error is logged, every error is reviewed, every error feeds back into the eval suite.

Scaling before consolidating. The 90-day programme ends. The team rolls the system out to the whole organisation before the rough edges are fixed. The rough edges become incidents. The incidents become distrust. The system gets paused. Fix: consolidate at current scope before expanding.

The compounding effect

A successful 90-day rollout is not the end of the project. It is the foundation for the next one.

The eval suite becomes the contract for the second workflow. The review interface becomes the pattern for the next one. The operator trust that was built becomes the basis for the next rollout. The technical debt that was avoided becomes the capacity for the next round of work.

Teams that ship one agent system well ship the second one in half the time, and the third in a third. Teams that ship the first one badly often cannot ship a second at all, because the organisational trust that the first rollout consumed is not available for the next attempt.

The 90 days are not a delay. They are the work. The teams that do the work are the teams that keep doing it.