Working with a white-label AI partner

Clients now ask their design, brand, marketing and development agencies for AI work: an assistant on the website, an internal tool, an AI feature in the product the agency designed. Most agencies can't staff it. Hiring AI engineers is slow and expensive for work that arrives in bursts, and saying no sends the client looking elsewhere, sometimes to a firm that will also take the rest of the account. A white-label partner is the third option: the work gets built, under your name, and the client stays yours. It only works if it's set up properly, which is what this guide is about.

01Why are agencies being asked for AI work they can't staff?

Because the agency is the team the client already trusts with its product, brand or site, and AI now touches all three. The request arrives through the relationship you built, often as a line at the end of a call: "can you add AI to this?"

The work behind that line is different from what most agencies do. It needs product judgement about where a model helps and where it doesn't, engineering on real data, and a way to test something whose answers aren't fixed in advance. An agency can learn all of that, but not by next month, and not profitably for one project.

That leaves three options: decline and risk the client, staff up and risk the margin, or partner and keep both. We wrote about the agency side of this in white-label AI product work for agencies.

02How do you choose a white-label AI partner?

Most partners will show you a polished demo. Ask the questions a demo doesn't answer:

• What have you built and run yourselves? A partner that runs its own products has lived with what happens after launch. One that only builds for others may never have.
• What do you turn down? A partner who takes everything will take your client's worst idea too. A clear list of what they won't do is a sign of judgement.
• How do you prove it works before users see it? Listen for an evaluation set, tests and a staged release. A partner who answers with "we test it thoroughly" hasn't answered.
• Who will actually work on it? Names, and whether they stay the same across projects.
• What happens if we stop? The answer should be: you pay for completed milestones, and you keep everything built so far, in your client's accounts.

Two warning signs are worth walking away over: a partner who wants to meet your client early "to understand the brief", and one who can't explain their own past work in plain language. The first is a relationship risk; the second means your team won't be able to explain the work either.

03What does a white-label AI partner actually do?

It builds the AI product or feature your client wants, as part of your team, under your name. In practice that means:

• Deciding what's worth building, with you, before the quote: what the AI should do, what it shouldn't, and what the first release includes.
• Designing and building it, on the client's real data, with the same care as the partner's own products.
• Proving it works, with evaluation, tests and a release in steps, before the client's users see it.
• Handing it over, with code and data in the client's accounts, not the partner's.

What it shouldn't do is appear in front of your client as a separate firm, pitch them, or leave you unable to explain the work you delivered.

04What should stay with the agency, and what moves to the partner?

Draw the line before the first project, and write it down.

The overlap is the product design. Keep it shared: the agency knows the client's users and brand, the partner knows what the AI can and can't do. Decide who has the final say on each screen before you start, so the client never sees you disagree.

05What should the brief to the partner include?

The partner can only build what the brief lets them understand. A good white-label brief is short, and it answers the questions the partner would otherwise have to ask your client, which they shouldn't:

• The client and their business, in a paragraph: what they sell, to whom, and what's changing for them.
• The request, in the client's words, and what you think they actually need, which is often different.
• The users and the moment: who would use the thing, and when in their day it would matter.
• What exists already: the site, the product, the systems it would connect to, the data the client holds.
• The brand and the taste: what it must look and sound like, and who on your side decides.
• The constraints: timing, budget range, where data may be stored, anything regulated.
• What the client must never see: the partner's name, their tools, their invoices.

Write it before the scoping conversation, not after. A brief written after the quote is a justification; one written before is a question the partner can answer properly.

06How do you scope an AI request before you quote it?

By treating the client's request as the start of a conversation, not a specification. "An AI assistant for our website" can mean a search box, a booking flow, a support tool or a sales agent, and each has a different cost and a different chance of working.

Four questions, asked with the partner before any quote:

1. What moment is this meant to change? For whom, in their day, and what does it cost them today.
2. Would rules do? The Remove-the-AI Test: take the model out and see what's left. Often a simpler product does most of the job, and it's cheaper, faster and easier to maintain.
3. Does the data exist? What the AI would learn from or answer from, whether the client has it, and whether you're allowed to use it.
4. What's in the first release? Every idea in one of four trays: build first, later, cut, don't build. That's The Scope Cut.

Then quote the first release, with a fixed scope, in writing. A quote for "the AI assistant" is a promise with no edges; a quote for a first release with named features and a stop line is one you can keep. How to scope an AI product covers this in depth.

07How do you keep the partner invisible to your client?

Invisible to the client, visible to you. Three things make it work:

• Your tools. The partner works in your project tools and your channels, not theirs. Your client never gets an email from another domain.
• A named team. The same people on every project, so what they learn about your client's product stays with the people building it, and you're not re-briefing strangers.
• Your brand on everything. Documents, demos and handover material go out as yours.

Invisible doesn't mean silent. Your team should be able to explain every decision in the build, which means the partner explains it to you first, in plain language, before you're asked.

It also means the partner's habits have to match yours. If your agency writes to clients in a certain way, reviews work at a certain point in the week or names files a certain way, the partner should do the same. Small inconsistencies are how clients notice a second firm, and consistency is cheap to agree at the start and expensive to fix later.

08What should the contract say?

Five terms protect the agency. This isn't legal advice, and your own lawyer should write the contract, but these are the points to insist on:

• Non-solicitation. The partner never approaches your clients, during the project or after it. In the contract, not in a promise.
• Ownership. The work and its IP transfer to you, or to your client, on payment.
• Where the code and data live. In the client's accounts from the first day, so nobody is ever locked out.
• Stopping rights. You can stop at any milestone and pay only for the milestones completed.
• Confidentiality. The partner doesn't show your client's work as its own without permission.

A partner who hesitates on any of these is telling you how they see your clients.

09How do you price it without guessing?

By getting the partner's fee in writing, for a scoped first release, before you quote the client. Then your quote is the partner's fixed fee plus your own work and margin, and you know your margin before you sign.

What goes wrong is quoting the client first, from a guess, and then finding the partner's number doesn't fit. The fix is sequence: scope with the partner, get their fixed fee, then quote. If the client's budget doesn't fit a sensible first release, you'd rather find that out before the contract than after it.

10How do you know the partner's work will hold up?

Your name is on it, so ask how they prove it works before your client's users see it. A good answer includes:

• An evaluation set: real inputs with good outputs, scored before every release, so a change that fixes one case and breaks others never ships.
• Tests for what AI products usually skip: inputs designed to mislead the model, attempts to extract data it shouldn't share, and checks on speed and cost.
• A staged release: internal, then beta, then soft launch, then live, which is Graduated Launch.
• Traceability: every step the AI takes recorded, so when something goes wrong, someone can find out why.

If the answer is a demo and a promise, you'll be the one explaining the first failure to your client. What breaks when a prototype meets real users covers why.

11How do you run the first project together?

Small, and with a stop line. The first project with a new partner tests the partnership as much as the product, so choose one where a wobble won't cost you the client.

• Scope a first release, not the whole product. A defined output with named features and a result that would make you stop.
• Agree the rhythm. A regular review in your tools, where the partner shows what's working and what isn't, before your client asks.
• Rehearse the client moments. Before every client meeting, the partner briefs your team on what's been built and why, so your people present it as their own.
• Hand over properly. Code and data in the client's accounts, documentation your team can read, and a short walkthrough for whoever looks after it next.
• Review the partnership, not just the project. After the first release, decide together what to change before the second.

12What shouldn't you white-label?

Anything the partner doesn't do well, and anything nobody on the client's side can decide. Ask the partner what they turn down; a good one will have a clear answer. Ours: workflow automation as a standalone service, internal IT tooling, and equity-only builds.

Be wary too of requests with no decision-maker on the client's side. AI work needs someone who can say yes to a first release and no to the rest. Without them, the scope grows every week and the project never finishes.

Telling a client early that part of a request isn't worth building is one of the most valuable things an agency can do. It's the conversation that makes them trust the next quote.

13How do you grow it into a service line?

After a few projects, the agency usually faces a choice: keep partnering project by project, or turn AI work into a named service line. Three things make the second work.

• A clear offer. Not "AI", which clients can't buy, but a specific outcome for the kind of client you already serve: a booking assistant for clinics, a product search that understands questions, launch creative for AI features.
• A repeatable scope. The same first-release shape, the same questions before the quote, the same evaluation before launch. Repeatability is what protects the margin.
• Proof you can show. White-label work usually stays private. Ask clients for permission to show what you built, even anonymised, and label it honestly. One real example beats a page of promises.

The partner's role doesn't change as the service line grows. What changes is how much of the scoping your own team can do before the partner joins, which is where your margin and your client's trust both grow.

14Worked example: "can we add an AI assistant to the website?"

Illustrative example A made-up agency and client, run the way we'd run a real request. Not client work.

A brand agency redesigned the website for a chain of physiotherapy clinics. At the handover, the client asks for "an AI assistant on the website".

• The moment. Asked what the assistant is for, the client describes patients phoning to ask which clinic treats their problem and when the next appointment is. The front desks spend much of their day on those calls.
• Would rules do? The appointment question: yes. It's a booking flow connected to the clinics' calendars, with no model at all. The "which clinic treats this" question is where a model helps, answering from the clinics' own treatment pages.
• The data. The treatment pages exist, because the agency wrote them. The calendars exist in the clinics' booking system, which has a way to connect.
• The first release. Build first: online booking, and an assistant that answers treatment questions from the clinics' pages and hands over to booking. Later: follow-up messages after appointments. Don't build: symptom diagnosis, which the clinics shouldn't offer through a website at all.

The agency gets the partner's fixed fee for that first release, adds its own design work and margin, and quotes the client a first release with named features and a stop line. The client sees the agency's name on everything, and the agency is the one who told them not to build symptom diagnosis, which is the conversation they'll remember.

15The white-label checklist

1. The line between what the agency keeps and what the partner owns, written down.
2. Every AI request scoped with the partner before any quote: the moment, rules or a model, the data, the first release.
3. The partner's fixed fee, in writing, before you quote the client.
4. Your tools, your brand and a named team that stays the same.
5. Non-solicitation, ownership, data location, stopping rights and confidentiality in the contract.
6. An evaluation set, tests and a staged release before the client's users see it.
7. A decision-maker on the client's side who can approve the first release.
8. A clear list of what you won't take on, and a partner who knows theirs.

16Questions agencies ask