pq
Free Playbook · Kickoff → Production

Our entire 90-day playbook. Free.

Perpetual Quest · 2026

The 90-Day
Deployment
Playbook

Day 1 → Day 90: live in production. Not a pilot. Not a deck.

Scoping week, build sprints, training cadence, hypercare, handoff — the exact structure we use to take an AI system from kickoff to production. Use it with us or without us.

Instant access · Also sent to your email · No spam

Dear Operator,

This is the entire method. Not a teaser, not chapter one of a sales funnel — the actual phase-by-phase structure we use to take an AI system from kickoff to live-in-production in 90 days. We’re giving it away because we deploy, we don’t describe — and because operators respect the real method, and most won’t execute it alone anyway.

One framing rule before the phases: the goal is not a prototype, a pilot, or a proof of concept that dies in a sandbox. The goal is a system your team uses every day, owns outright, and can operate and extend without us. Choosing Run later for managed assurance — evaluation, governance, optimization, incident support — is a choice, not proof of a failed handoff. Every decision below serves that.

The five phases

Days 1–7

Scoping week

One week, not twelve. We map the target workflow end-to-end: who touches it, what systems it crosses, where the hours go, where judgment is genuinely required versus where it’s habit.

Three artifacts come out of scoping week, and nothing gets built until they exist:

  • A written scope — one workflow, defined boundaries, and an explicit “not in this deployment” list. Scope creep is the #1 killer; this document is the guardrail.
  • A success metric — the number we’ll be judged on at day 90: hours saved, cycle time, error rate. Agreed before a line of configuration.
  • A named internal champion with reserved bandwidth — 4–6 hours a week, on their calendar, approved by their manager. We’ve watched deployments die because the champion had no bandwidth, so we settle this before we scope anything else.

Days 8–49

Build sprints

Six weeks of one-week sprints. Each sprint ends with something the champion can actually run against real work — not a slide about progress, a system state they can touch.

  • Sprints 1–2: integrations and data plumbing. The unglamorous part that determines whether everything else works.
  • Sprints 3–4: the agent workflow itself, run against historical/live-shadow data, with humans still doing the real work in parallel.
  • Sprints 5–6: edge-case handling and escalation routes. The rule: agents handle volume, humans handle exceptions — so the exception paths get built with the same care as the happy path.

Scope-change requests during sprints go through one filter: anything added pushes something out. Written down, every time. This is the discipline that gets you to production while everyone else’s pilot is still “evolving.”

Days 22–77 (overlapping)

Training cadence

Training is not a phase that happens after launch — it runs alongside the build, starting week three. Teams trained after the fact treat the system as something done to them; teams trained during rollout treat it as something they own. That difference is the whole adoption game.

  • Weekly working sessions with the people who’ll actually operate the system — on their real work, not demo data.
  • The champion learns configuration, not just usage: how to adjust prompts, thresholds, and routing. Material prompt, tool, or permission changes after go-live follow the Agent Change Control Standard (especially under Run) — not silent production edits.
  • By launch, the team has already used the system for weeks. Day one of production is nobody’s first day.

Days 50–83

Production launch + hypercare

The system goes live only after the production-ready evidence gates below are met. At launch, a human review loop covers every output at first, then progressively samples as trust is earned with evidence. We call the first few weeks after launch hypercare:

  • Daily monitoring of agent decisions, escalations, and misses.
  • Fast tuning cycles — same-week fixes, not a backlog for next quarter.
  • The success metric from scoping week tracked publicly, so everyone can see whether it’s working — including when it isn’t yet.

Days 84–90

Handoff

The deployment ends with your team holding the keys: runbooks, admin access, the full configuration, and a champion who can extend the system without calling us. The exit test is simple — if we disappeared on day 91, the system keeps running and improving.

Most consultancies structure engagements so you need them forever because the system only works with them. We structure them so you can run without us — day 91 is the proof. Operators who continue with Run do it for ongoing evaluation, governance, optimization, and carefully managed expansion by choice — not because the system is intentionally dependent on us.

What “production-ready” means before go-live

Going live is not the definition of production-ready. Before we call a system production-ready, these evidence gates are met. Thresholds for the metric gates are agreed in scoping week — we do not invent universal pass rates; we define them with you, then prove them.

  • Evaluation pass rate — agreed threshold met on a fixed eval set before go-live.
  • Critical failure rate — within the agreed bound on shadow/parallel runs.
  • Escalation accuracy — exceptions route correctly at the agreed rate.
  • Tool-call accuracy — tool use succeeds within agreed bounds.
  • Maximum retry limits — hard caps documented and enforced.
  • Rollback mechanism — documented, tested path to last-known-good.
  • Kill switch — named owners and time-to-pause (see the governance checklist).
  • Audit completeness — reconstructible action history for the workflow (same checklist).
  • Cost-per-completed-workflow — baseline measured; within the agreed envelope.
  • Performance under realistic volume — validated at expected peak, not demo load.
  • Named owner for every failure class — map of failure modes to accountable humans.

Why 90 days holds (and when it doesn't)

The honest caveat: 90 days holds when scope holds. The two things that break the timeline are scope creep (solved by the written scope and the trade rule) and discovering mid-build that the underlying process is broken. AI doesn’t fix broken operations — it accelerates working ones. If scoping week reveals chaos underneath, the right move is a process redesign first, and we’ll say so directly rather than deploy on sand.

What this produced in our own businesses

This structure isn’t theory — it’s how we run our own companies. It’s the method behind Grademate scaling enrollment 3× with zero added delivery headcount, NamingForce compressing a review cycle from hours to under 20 minutes per project, and EchoTexting absorbing a workload that would otherwise have required two to three additional ops hires. We broke it ourselves first. That’s the point.

Use it — with us or without us

Everything above is enough to run a deployment yourself if you have the internal muscle. If you’d rather have the people who’ve run this loop dozens of times do it with you, that’s a Forge engagement: 90 days, one system in production, your team trained and owning it.

Book the 30-minute call — we’ll map your first deployment →

— Perpetual Quest
perpetualquest.com · [email protected]