The first credible AI project is not a strategy deck. It is a bounded workflow with a baseline, a reviewer, and a decision rule.

Most companies do not have an AI-readiness problem. They have a decision problem.

They have bought the tools, circulated the policy, run the workshop, and collected a small museum of prompts. Then someone asks the only question that matters: which workflow earned the right to continue?

The answer is usually an activity report: people are experimenting, the pilot is going well, the team is saving time. None of that tells a manager how much trust to grant, what to fix, or when to stop.

The first AI project should not be another strategy deck or broad readiness assessment. It should be one bounded workflow that produces a reviewable decision in five working days.

AI readiness is too broad to be useful

Readiness checklists, prompt packs, workflow bundles, and automation demos are easy to buy. They are also a poor substitute for evidence.

A checklist can tell you to think about governance, data, talent, infrastructure, and process integration. It cannot tell you whether a meeting-recap workflow is safe enough for one coordinator to use next week. A demo can show an impressive output. It cannot show what happens when the source material is incomplete, contradictory, or outside the approved scope.

That is the gap between “we started using AI” and “this workflow earned another dollar of trust.”

Most pilots die in that gap. The use case was too broad. Nobody recorded the baseline. Nobody named the reviewer. Nobody tested the weird case. When a bad output arrived, the team had no decision rule beyond optimism or panic.

The answer is not a bigger pilot. It is a smaller proof.

The five-day workflow-proof sprint

A proof sprint asks one narrow question:

Can one real workflow be used safely, reviewed consistently, and released narrowly enough to create useful work?

It is not meant to make a company “AI-ready” in a week. It is meant to produce enough evidence for a sensible next decision.

Day 1: Select one workflow

Choose a recurring workflow with a clear owner and visible output.

Good candidates include drafting a meeting recap from approved notes, preparing a first-pass internal research memo, creating an initial SOP, or drafting customer follow-up from a defined source pack.

Avoid “improve operations with AI.” That is a department aspiration, not a test.

Write down the workflow name, its owner, what the output must contain, and what acceptable work looked like before AI. If the team cannot describe the baseline, it cannot honestly claim improvement.

Day 2: Define the input contract

Before anyone writes a clever prompt, define the input and judgment contract—the minimum context the workflow may trust and the decisions it must hand back to a person.

What sources may the system see? Which tool will it use? What may it produce? What must a human decide? What is it never allowed to decide? What happens when a source is missing, contradictory, or outside the approved scope?

Name the reviewer and the stop rule now. These are operating controls, not paperwork to add after the first embarrassing result.

The boundary matters more than the prompt wording. A mediocre prompt inside a defined process can be improved. A brilliant prompt inside an undefined process just produces confident ambiguity faster.

Day 3: Test three normal cases and one weird case

Run at least three ordinary examples and one case designed to expose the workflow’s limits.

The normal cases show whether the process works when the inputs behave. The weird case shows whether the process knows what to do when they do not.

For a meeting-recap workflow, the weird case could include incomplete notes, conflicting action items, or a decision that was discussed but never approved. The correct output is not a smooth paragraph that hides the conflict. It is a visible flag for human review.

A workflow that performs only on the happy path has not proved itself. It has performed a demonstration.

Day 4: Review the review

Keep a correction log. Record unsupported claims, missing context, formatting errors, wrong decisions, unnecessary edits, and cases that should have stopped the run.

The correction log is more useful than a satisfaction survey. It tells you whether the review burden is light and repeatable or whether the supposedly efficient workflow has merely moved the work downstream.

Price the hidden labour. Review, cleanup, correction passes, reruns, manager coaching, and support questions all count. If the first draft is faster but the approved output takes longer, gross time saved is a misleading metric.

The question is not whether AI generated something quickly. It is whether the workflow produced net useful work after review and cleanup.

Day 5: Make a release decision

End with a decision card, not a celebratory adjective.

There are three honest outcomes:

  • Go narrow: release the workflow to a named role, with the current controls and review process.
  • Revise: change the input contract, test set, ownership, or review rule and run the proof again.
  • Stop: the quality risk, cleanup burden, or support cost is not worth the claimed benefit.

“Pilot successful” is not a decision. It is what gets written when nobody has decided how much trust to grant.

A worked example: internal research memos

Imagine a three-person operations team that turns approved source material into internal research memos.

On Day 1, the owner defines the workflow: produce a one-page memo from a named folder of source documents. The baseline is the existing average completion time, with a quality rule that every material claim must be traceable to an approved source.

On Day 2, the team writes the input contract: the system may summarize and structure the supplied documents, but it may not invent facts, browse for unapproved evidence, or make the recommendation itself. A manager is the reviewer.

On Day 3, the team runs three ordinary memos and one awkward source pack containing a missing date and two conflicting figures. The workflow produces useful drafts on the ordinary cases and correctly flags the conflict on the weird case.

On Day 4, the reviewer finds that the drafts are faster to shape but still require a source-traceability check and one recurring correction to the executive-summary format. Those are manageable controls. If the reviewer had to rewrite every memo, the answer would be different.

On Day 5, the team chooses “go narrow”: one role, one source folder, one reviewer, and a two-week measurement period.

It has not proved that AI can transform research. It has proved something more valuable: this specific workflow can be trusted within a defined lane, subject to evidence.

Measure the work, then make the decision

Do not measure only minutes saved. Keep a simple scorecard:

  • Throughput: eligible cases, AI-assisted cases, and useful outputs kept.
  • Net value: gross time saved minus review, cleanup, corrections, and reruns.
  • Quality: claims or decisions that passed, failed, or required escalation.
  • Operating cost: support questions, manager coaching, and recurring correction patterns.

Set the decision threshold before the sprint ends. If the workflow cannot produce net useful work at an acceptable quality level inside its named boundary, it does not earn a wider rollout.

Then ask where the reclaimed capacity goes. Time saved but allowed to evaporate into more low-value busywork is weak business value. A workflow earns wider trust when it creates net useful work, not when it generates an impressive demo.

The better first question

Stop asking whether your company is “AI-ready.” It is too broad to guide a decision and too flattering to expose a weak process.

Ask whether one real workflow is specific enough to test, bounded enough to control, and useful enough to release.

In five days, a lean team can have a named owner, a reviewer, a baseline, a weird-case result, a correction log, and a go/revise/stop decision. That is not the whole AI strategy. It is the first piece of evidence a credible strategy should contain.

The next workflow should have to earn its turn.

---

Editorial source notes: Lean-Team Workflow Proof Gap Market Readout (2026-08-08); Cortex AI Workflow Control Starter Pack Improvement (2026-08-10); Cortex AI Useful Work Per Dollar Proof Sheet (2026-07-30).