Your agency sold the AI build. The delivery risk is still yours.
Under a white-label agreement, you are usually buying capacity and a delivery process more than a standalone product. Agree three things before anything starts: the shape of the scope, who talks to the client, and what happens when the work has to be redone. The four risks worth documenting in your agreement are client contact, publication, staffing and who owns the code at the end.
By Reynier RiveroSoftware engineer
The Monday promise
At 9:07 on Monday, a client messages an agency: “Can we still launch the AI assistant this month?” The agency has sold the outcome, but its internal team is already committed.
This is a hypothetical composite scene, not a report of a specific project.
In the model described, the agency remains the client-facing party and carries the commercial exposure of the promise it sold; that does not, by itself, determine legal responsibility to the client. The partner agreement should mirror the client-facing obligations and state who owns each decision, approval and failure path.
What you are actually buying
White-label delivery covers work you have sold, or could sell, but do not have the internal capacity to build: AI assistants and agents for your clients, automations and integrations, a full product when the brief is bigger than your team, or simply extra hands when the deadline will not move.
What you are buying is more than code. It is the ability to say yes to a brief without hiring for it, and to say it with a straight face because someone senior is actually going to do the work.
Aim for a client experience with one agreed process, cadence and point of contact.white-label development service is the relevant delivery context.
When the brief is bigger than your team's capacity, it may become a custom software build rather than a narrow automation. That distinction affects discovery, staffing and handover.
Agree the scope shape first
There are two useful shapes and they behave differently. A fixed scope — a defined outcome, included workflows and integrations, assumptions, acceptance criteria, a review window and a written boundary for changes — gives both sides a clearer boundary when the deliverable is understood. “An AI assistant” is not enough by itself; define the behaviors and test scenarios that make the deliverable acceptable.
Capacity, priced by time, can fit when the brief is genuinely going to move: a discovery phase, an unclear product, a client who is still deciding. Set a timebox and a decision point so discovery does not become an open-ended promise. It can be a risky shape when the launch date is fixed, because you carry the risk your client thinks you sold them.
Do not mix them casually. A fixed price on a moving scope can put the partnership under strain. Whichever shape you choose, define how a change is requested, assessed, approved and scheduled. Scope is not complete until the agreement says what happens when the client's brief changes.
Decide what rework means
Rework is not one thing, and the agreement should allocate each type explicitly. Whether a defect against the agreed acceptance criteria is fixed within delivery or treated as a change depends on that allocation; define it before kickoff. A changed preference, new integration, new data source or new approval path can be treated as a scope change, but the contract should say how it is assessed and approved.
Agree who reviews each milestone, what evidence counts as acceptance, how long the review window stays open, and who can approve a change. If the client delays feedback or changes direction, define what happens to the timeline and capacity. If the partner misunderstood an agreed requirement, document how that correction is handled; if the requirement changed, route it through the change process.
Delivery your client barely notices
The delivery team should work inside your process — your tools, your meetings, your naming conventions — not the other way round. If your client sees a different project tracker appear, that is a sign the arrangement is leaking into the client experience.
Insist on something real to review every week. Working software, not a status report. On a subcontracted build this matters because early working software gives you a chance to fix a misunderstanding before it becomes expensive.
And agree who is on the call. Some agencies want a technical person present as their own; some want no contact at all. Both can work when it is decided before the kickoff rather than during it.
The same discipline matters when you are splitting provider and deployer responsibilities in a white-label AI deployment: the handoffs between systems and people need to be agreed before the demo, not discovered after a client asks what happens next.
Separate the architecture before the handoff
Treat the build as several boundaries, not one black box: a client-facing layer, the agent or orchestration logic, connectors to business systems and the data stores behind them. Give each component only the credentials it needs, keep production access in scoped service accounts, and make write actions pass through a human approval gate when a wrong action could create a client commitment. That lets the partner build and test without default access to every CRM record or cloud secret.
Make the handoff a contract between components as well as between companies. For each connector, write down its inputs, outputs, failure behavior, retries, owner and escalation path; for each data store, record what the agent may read, write or retain. Then the agency can review a change in one layer without guessing what it breaks in another, and transfer access at handover instead of sharing credentials informally.
The four risks worth writing down
Client contact. Decide whether the delivery team may contact your client during or after the project. If direct contact is off-limits, document that boundary and its duration in the agreement.
Publication. If the work appears as your case study, agree whose name is attached. If the other side wants to write about it, set the permission requirement in the agreement rather than assuming permission.
Staffing. One risk to plan for is a partner taking on work they cannot staff and saying so only after the project is underway. A partner who sometimes declines a brief can be more useful than one that promises every brief.
Ownership is not one generic promise. Copyright initially belongs to the author or authors, subject to specific work-made-for-hire rules; a later holder needs a valid chain of transmission. In the United States, 17 U.S.C. §101 defines work made for hire and lists nine categories of specially ordered or commissioned works; ordinary software does not appear among those nine categories. 17 U.S.C. §201(a) places initial ownership in the author or authors, while 17 U.S.C. §201(b) treats the employer or other person for whom a qualifying work was prepared as the author for work made for hire. For a specially ordered or commissioned software work, there is no automatic transfer: a transfer still needs a written instrument signed by the copyright owner or a duly authorised agent under 17 U.S.C. §204(a). Use work made for hire only to the extent the law permits, and add a present assignment (“hereby assigns”) for anything it does not cover, plus a fallback licence. In the United Kingdom, CDPA s.11 provides that the author is generally the first copyright owner, subject to the employee exception, and CDPA s.90 requires an assignment to be in writing and signed by the assignor or on the assignor’s behalf; commissioning or payment alone does not by itself transfer ownership. Separate project-specific deliverables — source and object code, documentation, designs, databases, scripts, infrastructure-as-code and project data — from the partner’s pre-existing libraries, templates, tools and reusable components; identify those carve-outs and grant the client a perpetual, irrevocable licence where the deliverable depends on them rather than promising an assignment the partner cannot make. Finally, list third-party code, models, APIs, assets and other materials, along with their licences, permissions, attribution requirements and limits, so the agency does not promise rights it cannot grant.
Recommendation: add a separate responsibility matrix for client-facing commitments, approvals, data and security incidents, third-party model or API failures and changes, IP claims, acceptance and rework, incident notice, indemnities, liability caps and insurance. Treat these as contract decisions, not as promises that a white-label label resolves automatically. These are contract decisions subject to applicable law and non-waivable obligations; the white-label label does not resolve them automatically.
How the money usually works
Partner rates are agreed inside each partnership and may not be published. We do not publish a rate figure here; the relevant rate depends on the engagement, and partner terms are a separate conversation.
What you should ask for regardless of rate: a written scope and a price range before you commit anything, invoices to you rather than to your client if that is how the arrangement is structured, and no surprise line items. If a partner cannot give you a range after a discovery call, treat that as a signal that the brief may not be understood yet.
We have no published benchmark for what agencies resell this work at, so we will not quote you one. Price it against what the outcome is worth to your client and the overhead your agency needs to cover, not against a number someone put in a blog post.
A sensible next step
If you want a second pair of eyes before the proposal goes out, bring the client outcome, scope boundary, review cadence and handover plan to a short architecture conversation with us. The goal is simple: decide whether the brief calls for a fixed-scope build or capacity for discovery.
Disclaimer: This is practical operating guidance, not legal advice. The right contract language depends on the governing law, client agreement, project and the people who created the work; have counsel review those terms before you sign. Last reviewed: 17 September 2026.
The service this article is about: Your brand. Our build. Your client never meets us.