What should an AI agency deliver before you pay for a build?

Ask for a description of the current process

Bring a few examples of the work you want help with. Remove personal information before using them in a demonstration. Include an awkward example as well as an ordinary one, such as an enquiry with two different addresses or a customer changing an appointment.

I'd expect the brief to name the input and where it comes from. It should say what happens next, who currently checks it and where the finished result belongs. If three people use different inboxes for the same job, resolving that may be part of the work.

A proposed brief might read: “Read new quote enquiries from the shared inbox, prepare a summary and flag missing details for a person to review. Save the approved information to the enquiry record.” That gives you a much clearer basis for a discussion than “add an AI agent”. It also leaves the approval decision with an identified person.

The government's AI adoption guidance starts from an identified business problem and asks whether generative AI is suitable when compared with other options. Its guide concerns organisational adoption; the small-project approach here is my suggested way to apply that principle.

Source: The People Factor: government guidance on adopting AI tools

Compare a build with the tools you already have

Ask the agency to explain the alternatives. A booking form might need an extra field. An existing system might already send the reminder you are typing by hand. A fixed rule can route messages when the decision is straightforward.

An AI step may be useful when information arrives in varied wording and needs interpreting. That still leaves practical choices about where it runs, what it can access and how a person checks its output. The agency should be able to explain those choices using one of your examples.

I would ask which part of the proposal is essential for the first useful version. Keep later ideas in the brief, with their own costs, so they do not quietly become part of the initial build.

Agree what a successful test will show

Write down a result you can inspect. For an enquiry summary, that might be the correct contact details, the requested service and a clear indication that the address is missing. For a booking, inspect the actual calendar entry and the confirmation, as well as listening to what the assistant says.

Choose test cases before the demonstration. Include a correction, an unsupported request and an unavailable connection. Ask what the system does when it cannot complete the action. A message for a person to review may be the right outcome, provided that person receives it and knows what to do.

The acceptance record can be small: the example, the expected result, the observed result and any change needed. Agree which failures prevent launch. Keep the examples so you can repeat them when booking rules or business information changes.

Make access and supplier responsibilities clear

Ask which accounts and information the build needs. Find out who controls those accounts, who can change the settings and how access is removed if the arrangement ends. Use a test environment or sample data for the first demonstration where possible.

The NCSC recommends assessing suppliers in proportion to their importance and the risk they present. It also treats assurance as something to keep current as a relationship changes. That is useful context for an AI service connected to your business systems.

I would want the proposal to name the services involved and explain where to raise a problem. A supplier's broad security statement still leaves questions about your particular setup, its access and the information it handles.

Source: NCSC: supplier assurance

Get the running costs and handover in writing

Ask for the build price and the ongoing bill separately. The quote should explain any usage allowance, what happens when you exceed it, and whether support or changes cost extra. Find out who pays the underlying software subscriptions.

Ask what you receive at handover: account access, configuration notes, the test record and instructions for pausing the workflow. Agree who updates prices, service details or booking rules after launch. If you need help leaving later, establish what can be exported and what work that involves.

During a small pilot, record time spent checking and correcting the result alongside time saved doing the original job. Review the exceptions with the person using it. That gives you something concrete to discuss before expanding the work or adding another integration.