How to fix a stuck Claude pilot in 21 days.

The instinct on day one is to start writing code. Resist it. Spend the first week understanding why the pilot stalled. Three artifacts come out of week one:

1. Failure mode map. Every place the pilot can break, written down. Auth boundary, tool side effects, prompt drift, retrieval recall, token cost. Each one ranked by likelihood and blast radius.
2. Eval baseline. Twenty to fifty regression cases that represent the pilot's actual job. If you can't write them, the pilot's job isn't defined yet, and that's the real bug.
3. Go/no-go memo. One page. Should this pilot ship? If yes, what gets cut. If no, what to do with the half worth saving.

The go/no-go is the most important deliverable of the week. Some stuck pilots shouldn't ship at all, and saying so early is worth more than weeks of pretending.

Assuming the pilot earned a go, week two is hardening. Most stuck pilots are stuck because the foundation is soft. Specifically:

• Scoped MCP tools. Every tool gets typed inputs, typed outputs, scoped OAuth, and a kill switch. A tool that can write should require a reviewer queue before any production-grade side effect.
• Auth boundary. Claude never holds raw credentials. It calls a thin server you own. Your server enforces row-level security, not the prompt.
• Token guardrails. Per-session caps, per-day caps, fallback to a cheaper model when context exceeds threshold. Cost dashboards wired up before launch, not after.
• Output validation. Structured outputs validated against a schema. If the parse fails, the request retries with a corrective prompt, then fails closed.
• Audit logs. Every tool call logged with prompt, response, user, timestamp, latency, cost. Pipe to your existing observability stack.

By the end of week two the foundation is boring. Boring is the goal. Boring foundations let the model do interesting work. The tool-surface half of that work follows the same checklist we use in MCP server hardening.

Week three is restraint. The single most common reason pilots stall is scope creep: five workflows half-built, none in production. Pick the one workflow with the clearest ROI, ship it, and let the rest wait.

One shipped workflow looks like this:

• Eval suite green on the regression baseline.
• Canary rollout to 5%, then 25%, then 100%, gated on the eval pass rate and cost-per-call ceiling.
• Runbook checked into the repo: rollout, rollback, on-call escalation, known failure modes.
• Dashboard live in your existing observability stack.
• One pair-programming handoff session per week from week one through week three, so your engineers own the build.

By day 21 the workflow is in production. The pilot is no longer stuck. The rest of the roadmap is sequenced on the runbook your team now owns. Keep the regression baseline growing after launch, the way we lay out in building an agent eval suite, and wire the tracing described in agent observability before you scale past one workflow.

Some engagements end with a written "do not ship" recommendation. This is a feature, not a failure. Months of engineering time saved by an early, honest memo is the highest-leverage deliverable we have. The half worth saving usually becomes a smaller, bounded workflow. The half not worth saving becomes a one-page postmortem the team can use to reset expectations with the board.

If you're three months past your original launch date and you still can't answer "is this ready," that's the signal. Start with AI Production Systems. You'll get a written answer.