Clients are asking their agencies for AI work: a chatbot on the website, an assistant that drafts proposals, an automation that reads incoming documents. Many agencies don’t have the engineers to build these, so they look for a white-label partner. That can work well. It can also go badly in ways that are harder to fix than a broken website, because AI systems have ongoing costs, change behaviour over time and handle client data.
These are the questions we think an agency should ask any development partner, including us, before putting their name on the work.
Commercial and contractual
Who owns the code, prompts and evaluation data? The answer should be you or your client, transferred on payment. Prompts and test sets are part of the product. If the partner keeps them, you can’t maintain or move the system later.
Will you ever contact my client directly? The usual answer is “only if you ask us to”. Get it in writing, along with a non-solicitation clause covering a reasonable period after the project.
Whose name appears anywhere? Code comments, commit authors, admin screens, email footers, documentation and support portals should all be unbranded or carry your brand.
How are estimates structured? You need estimates you can mark up and quote against, with assumptions listed. Ask how change requests work and who approves them. The answer should be you.
Running costs
Whose accounts pay for the model usage? LLM features have per-request costs that don’t exist for a normal website. The model provider account should belong to your client, or to you if you are reselling usage. A partner holding the API keys means a partner holding the bill and the access.
What will it cost per month to run? Ask for an estimate based on expected volume, and ask what happens at ten times that volume. A good partner will have measured cost per request during the prototype and will set spending limits.
What happens when the model provider changes something? Providers update and retire models regularly. Someone needs to rerun tests when that happens and adjust prompts if behaviour changes. Decide in advance whether that is in a support retainer, billed as needed, or your team’s job.
Quality and reliability
How will we know it works? This is the most important question. The answer should involve an evaluation set: real examples of inputs with known correct outputs, run automatically whenever the system changes. If the partner’s plan for quality is “we tested it and it looked good”, that is a warning sign.
What does it do when it doesn’t know? A support assistant that invents a refund policy is a reputational problem for your client and for you. Ask how the system handles questions outside its scope, and ask to see examples of it refusing or escalating.
What can it do without a person approving? For agents that take actions (sending emails, updating records), there should be clear limits on what runs automatically, and a review step for anything consequential. Ask how those limits are enforced in code, not just in the prompt.
What is logged? You’ll want a record of inputs, outputs, tool calls and costs for every request, both for debugging and for answering the client when they ask why the system did something.
Data and security
Where does client data go? Map it: which systems the data is read from, which model provider receives it, where it is stored, and for how long. Check the provider’s data retention and training policies and make sure they match what your client expects.
How is access controlled? If the system searches internal documents, it must only return what the current user is allowed to see. This needs to be handled in retrieval, before the model sees anything, not by asking the model to be careful.
What about personal data? If the system handles personal data, ask how it is minimised, whether it can be redacted before reaching the model, and how deletion requests would be handled. Your client may need a data processing agreement covering the partner and the model provider.
Has prompt injection been considered? Any system that reads untrusted text (emails, web pages, uploaded files) can be manipulated by instructions hidden in that text. Ask what the system is allowed to do if it is tricked, and how that is limited.
Working together
Will you work in our tools? A white-label partner should join your Slack or Teams, use your project tracker and commit to repositories you own. If they insist on their own portal, your client experience fragments.
Can you join client calls as part of our team? Some agencies want the partner fully hidden; others want them on calls under the agency’s name. Both are fine. Agree which, and agree who speaks to what.
What does handover look like? Ask to see an example of documentation and an admin guide. It should be written so that you could brand it and give it to the client as-is.
Who supports it after launch? AI features need more ongoing care than a typical site. Decide whether the partner provides unbranded support, at what response times, and how that is priced so you can include it in your retainer.
Questions to ask yourself
Finally, a few for the agency:
- Can we explain to the client what this system does, what it doesn’t do, and what it costs to run?
- Are we comfortable being the first call when it gets something wrong?
- Do we have someone who can review the partner’s work at a basic level, or do we need them to provide that transparency?
If the answers are yes, white-label AI work can be a strong addition to what you offer. If the partner can’t answer the questions above clearly, it is better to find out before the client does.
