Ask a GBS leader where they're starting with agentic AI and the answer usually involves a process with good data, low risk and a willing sponsor. It sounds like discipline. Eighteen months later the same organisation is still describing that work as a pilot, and the business case has never been tested against anything that mattered.

The safe pilot fails in a specific way — it succeeds.

Why the safe pilot ends as a demo

A process chosen for its low risk is, by definition, a process where nobody was losing much. So the result is real and no one in finance can feel it, which means there's no pull for the second phase and no budget for the third.

Meanwhile the team has learned how the technology behaves on documents that were never difficult, which tells them very little about how it behaves on the ones that are.

Start where the organisation hurts

Hypatos CEO Uli Erxleben puts it plainly: start with the highest-volume, most labour-intensive process you have, because it is usually better prepared for this than people assume. The data trails exist, the exception patterns are known, and the rules, even the messy ones, have been written down somewhere. Not the process that is easiest to show — the one that needs the most hours.

CK Taneja of Northern Trust reaches the same place from the pain side on GBS Rewired: don't start from where AI could add value, start from where the organisation hurts, whether that is cost out of proportion to the value produced or growth you cannot staff.

The first process should sit at the intersection. High volume, document-heavy, invisible to everyone except the team that works it every day.

Bounding the first project without shrinking it

Scope by population rather than by capability, which is the distinction most programmes get wrong. Take one entity, one document type and the full complexity of that population, including the awkward suppliers and the messy formats. Don't take a clean subset of five entities.

The reason is simple. A narrow population with full complexity teaches you what the technology does with your actual work. A broad population with the complexity stripped out teaches you nothing you can extrapolate.

What "done" looks like, agreed before go-live

Write these down and get them signed before anyone builds anything. Four lines, one page:

• The population. Which entity, which document type, how many per month, including the difficult ones.
• The operating outcome. Not accuracy. Exceptions per thousand, time to resolution, first-touch closure.
• The decision rights. What the agent decides alone, what it proposes, who accepts, at what threshold.
• The stop condition. What result would make you stop, and who has the authority to call it.

That fourth line is the one that gets left out and the one that makes the exercise honest. A pilot with no stop condition is a purchase with extra steps.

How Hypatos handles the first entity, then the next

Hypatos is built for this sequence, where the second entity has to cost less than the first. The invoice processing workforce carries the same skills to the next ledger, and the integrations mean the connection work doesn't restart each time.

What makes the second entity cheap is that the instructions are text rather than configuration. The rules your first team wrote get read and adapted by the next team, in plain language, without the need to assemble a developer team inhouse.

Whoever accepts a proposal in entity one is accepting it the same way in entity nine, against a rule that reads the same and a record that looks the same. That is what turns a pilot into an operating model.

Hypatos fits when the first process is document-heavy and painful, and when the second entity has to arrive without a second project.

The first result the CFO can see

Pick the number before you start, and make it one your CFO already looks at — days in the close, invoices held at month end, early-payment discounts captured.

The reason this matters more than it sounds is that the second phase is always funded by someone who wasn't in the room for the first. A result they can recognise without explanation sticks. A result that needs a slide to be understood does not, regardless of how good it was.

So when you brief a provider, Hypatos or anyone else, give them that number instead of your requirements list. Ask what it would look like after one entity and one quarter, and ask what would have to be true for that to happen.

If the first phase can't move a number already on your CFO's page, you chose the wrong process, and the time to find that out is now instead of in eighteen months.

‍