# Chapter 03: Prove it: from use case to working agent

> A proof earns the next budget when it runs on real data, inside the real process, and ends with a number the business already trusts.

The AI-Native Playbook for Enterprises · Twistag · 7 min read · Updated: 2026-10-09

## In one minute

1. **Scope is what makes it fast.** One workflow, one owner, data that is already reachable and a person approving what matters. That scope gets an agent into daily use in six to twelve weeks.
2. **Agree the test before the build.** The baseline, the target and the stop criteria are written down in week one. The proof ends with a decision, and the numbers make it.
3. **Plan the hand-over on day one.** The team that will run the agent joins the build from the first week, so the proof turns into daily use without a second project.

## Why most proofs never reach daily use

Every large company now has a drawer of AI pilots. Most of them worked in a demo. Few of them changed how the business runs.

The research on this is consistent. MIT's 2025 study found that only about 5% of custom enterprise AI pilots reached daily use with a measurable return. Gartner expects more than 40% of agentic AI projects to be cancelled by the end of 2027, for three reasons: rising costs, unclear business value and weak risk controls.

Each of those reasons is decided in the first weeks of a proof. Costs rise when the scope grows during the build. Value stays unclear when nobody recorded the number before the change. Risk controls stay weak when the agent was built for a demo and never met the real process.

A proof that avoids all three has a simple shape. One workflow. One owner. Real data. A person approving what matters. A number agreed in advance.

> A proof is a decision tool. Its job is to tell leadership whether to scale, change or stop, with numbers both sides trust.

## Choosing what to prove

The short list from Chapter 1 usually holds three to five candidates. The first one to prove should meet four tests:

- **An owner who wants it.** An executive whose target moves if the agent works, and who will give their team's time.
- **Data that is reachable now.** Read access to the documents, records and history the agent needs, without a new data project. Chapter 4 shows how to check this.
- **A result within a quarter.** Enough volume that a change shows up in weeks.
- **Contained risk.** A person can review the output before it takes effect, at least at the start.

The first proof is also a signal to the rest of the company. A clear win on a modest process does more for the programme than a stalled attempt at the hardest problem in the business.

## The shape of a proof

Twistag runs most proofs in four stages. The exact length depends on the data and the number of systems involved, and most fit between six and twelve weeks.

**Stage 1: Map and measure (weeks 1–2).** Sit with the people who run the process. Map every step, the volumes, the time spent and where errors come from. Record the baseline: cost per item, cycle time, error rate. Collect a set of real past cases, with the right answers, to test the agent against. Agree the target and the stop criteria in writing.

At the UK water utility in Chapter 2, this stage took two weeks of working sessions with communications leads, IT and the people writing the documents.

**Stage 2: Build on real data (weeks 2–6).** Build the agent against real documents and real systems from the first day. Test it every week against the set of past cases. Show it to the people who run the process every week, and let them break it.

**Stage 3: Run with approval (weeks 5–10).** Put the agent into the live process in assist or approve-by-exception mode. A person sees every output or every flagged item. Measure the same numbers as the baseline, on live volume.

**Stage 4: Decide (weeks 8–12).** Bring the numbers to the owner and the leadership team. Cost to run, value measured, risk observed. Then make one of three calls: scale it, change it, or stop it.

## What makes it fast

Speed comes from a short list of choices made early.

- **Real data from day one.** Synthetic data and cleaned samples hide the problems that matter. The awkward invoice layouts, the missing fields and the exceptions are where the design work is.
- **A person in the loop.** An agent that drafts while a person approves can go live long before one that acts alone. Approval also produces the evidence needed to give it more room later.
- **One process, end to end.** Narrow and complete beats broad and partial. A finished agent for one invoice type teaches more than a half-built agent for every document in finance.
- **Deterministic checks around the model.** Prices, totals, dates and IDs are checked in code. The model handles reading and judgement, and code verifies what can be verified.
- **A small team.** One to three engineers working with the process owner every week. Large teams slow a proof down.

Aralab's invoice agent shows how these combine. A language model reads each supplier PDF. Deterministic code re-checks every price, tax line and total against the purchase order. Staff review only the invoices the system is unsure of. The agent went live in six weeks, built by one engineer, handling more than 2,000 invoices a month.

Where we saw it: [An autonomous AP agent handling 2,000+ invoices a month](https://twistag.com/case-studies/ai-invoice-automation-aralab-manufacturing) (Aralab)

MIT's research found the same pattern at the company level: mid-market firms that moved fast went from pilot to full roll-out in about 90 days, while large enterprises took nine months or more and converted the fewest pilots.

## Measuring the proof

The measures for a proof come in three groups, and all three go in front of leadership.

- **Value.** The baseline number against the new one: cost per item, hours, cycle time, error rate. Measured on live volume.
- **Quality.** How often the agent is right on the test set and in live use, how often people override it, and what kinds of errors it makes.
- **Cost to run.** Model usage, infrastructure and the people time to review, all per item. Chapter 6 turns these into a business case.

Stop criteria matter as much as targets. If the agent cannot reach the agreed accuracy after two rounds of changes, or the cost per item stays above the old process, the right call is to stop or change the scope. A proof that stops early with clear numbers is a good result. It saves the budget for a better candidate.

## Planning the hand-over

Many proofs stall after a successful demo because nobody planned who would run the agent. The fix is to plan the hand-over from week one.

- **The running team joins the build.** At least one person who will own the agent day to day takes part in every weekly review.
- **Monitoring is part of the proof.** Logging, cost tracking and error alerts are built in Stage 2 and used in Stage 3. They are not added later.
- **The review screen is designed for the long run.** If people will review flagged items every day, the screen has to be fast and clear.
- **Documentation is light and current.** What the agent does, what it must never do, who to call, and how to switch it off.

Chapter 7 covers the move from a proof to daily operations in full.

## Common mistakes

- **Starting with the model.** Choosing a model or a platform before the process is mapped. The process decides what the agent needs.
- **Testing on clean samples.** The agent looks perfect in testing and fails on the first real week of documents.
- **No baseline.** Without the number before, nobody can prove the number after.
- **Scope that keeps growing.** Each new request during the build pushes the result further away. New ideas go on the list for the next stage.
- **No date for the decision.** A proof without an end date becomes a permanent pilot.

## What to do this month

1. Choose the first proof from the short list using the four tests above.
2. Name the owner, the build team and the person who will run the agent.
3. Record the baseline and collect a set of real past cases to test against.
4. Write down the target, the stop criteria and the date of the decision.

## Questions for the leadership team

1. Which use case on the short list has an owner, reachable data and a result that can be measured within a quarter?
2. What is today's baseline for that process, and who signs off the number?
3. What result would justify scaling it, and what result would stop it?
4. Who in the team that runs the process will join the build from week one?
5. What is the latest date for the scale, change or stop decision?

## Sources

1. [The GenAI Divide: State of AI in Business 2025](https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/), MIT NANDA, 2025-07
2. [Gartner predicts over 40% of agentic AI projects will be canceled by end of 2027](https://www.outlookbusiness.com/artificial-intelligence/over-40-of-agentic-ai-projects-will-be-scrapped-by-2027-says-gartner), Gartner, 2025-06

---

Source: https://twistag.com/guides-and-playbooks/ai-native-playbook/chapter-03