What will you have when the AI pilot ends?

A finance team wants help preparing unusual invoices for review. One consultancy proposes a study using sample records; another offers a limited live workflow. Both might call it a pilot. Put the promised result next to the date: an answer about whether the idea works, a prototype you can try or a service people can use. Compare the weeks only after you know which of those you are buying.

Nexus quotes four weeks for the first live agent within a three-month proof of concept. This is a company-confirmed target, not a delivery measured by Lowther Register.¹

Fifty One Degrees quotes two to four weeks for a working proof of concept and typically eight to sixteen weeks for production. Brainpool describes a fixed-price test of project feasibility lasting four to six weeks.^2,3,4

Finding out that an idea should not be built can be a useful result. A production service has a different finish line: someone must run it, control access and deal with failures. Ask what your colleagues will be able to use on the final day, and what still stands between that result and everyday work.

Nexus says its deployed agents have a business performance measure. Mercury’s IfATE case describes experts reviewing work with the evidence in view.^5,6

Both are useful prompts: decide how you will measure the result and what the reviewer needs to see before judging it.^5,6

For the invoice example, choose ordinary exceptions and incomplete records before the supplier prepares its demonstration. Keep the original input, proposed answer, reviewer’s decision and any correction. Compare them with the current process, including the effort spent checking. Your notes should show where the system helps, where a person steps in and which cases it was never meant to handle.

Agree the conditions for a pass before seeing the results. Quicker preparation may create more checking work elsewhere. Have the person running the process accept the workflow and the technical colleague accept the controls. If a condition fails, decide whether to stop, change the scope or repeat a named test. An extension should have a reason, not simply another end date.

The dated source records include Brainpool’s prototype and enterprise-MVP price ranges, alongside Fifty One Degrees’ proof-of-concept and implementation prices.^7,8,9,10

Those prices cover different work. They are starting points for a discussion, not matching quotations for your project.^7,8,9,10

Nexus confirms that it charges per role automated, without billing for consultant time.¹

Valliance describes a shared-success arrangement: most fees are paid when it creates value.^11,12

Write down the first fee, the next approval to spend, recurring charges, outside services, support and changes. Keep each quoted assumption beside the price it affects. For success-linked fees, agree the starting measure, how you will tell what value the supplier created and when payment becomes due. For a role-based fee, define the role and what happens when workload or responsibilities grow. If a dependency is still uncertain, ask for written alternatives before treating one price as settled.

Agree what you receive if the work stops: findings, assumptions tested, remaining risks, usable assets and a list of access to remove. In the invoice example, a useful negative result could identify unreliable source fields and what would be needed to improve them. That evidence can guide the next decision even if no workflow goes live. Ask for it while agreeing the pilot, not after deciding to leave.

Before continuing, list the new connections, users, types of data and support duties in the proposed live service. Approve that extra work deliberately. Ask for current written terms covering cancellation and transition; website language is not the contract for your project. Leave a short decision note saying why the next purchase is justified, which questions remain and who must answer them.