White label AI agents: what agencies should check

White label AI agents are agents an agency can offer under its own brand, usually as part of a service the client already buys. The branding is the easy part. Before reselling one, an agency needs clear answers about who can make an external change, who accepts responsibility for that change, where client data is kept, what the client can inspect, and where a person must approve the work.

That matters because an agent can move beyond drafting. It may prepare an email, update a record, trigger a payment or publish something. Once the work can affect a client's systems or customers, the agency is no longer choosing a clever piece of software. It is choosing an operating model that its own name will sit on.

Start with liability, not branding

Suppose an agent prepares a refund for the wrong amount. Who is expected to catch it? If it is sent, who owns the mistake? The agency, the client, the software provider, or the person who approved it?

A reseller agreement can answer part of that, but the product design matters just as much. An agency should map each kind of action to a named decision maker before it sells the service. Drafting a proposed refund is one kind of work. Issuing the refund is another. The second action has an effect outside the workspace, so someone needs clear authority to approve it.

Ask what happens when nobody responds. Does the action expire? Does the agent retry? Can it continue with related work while the decision is open? A system that treats silence as consent creates a very different risk from one that stops.

This is also where agencies should separate responsibility for the brief from responsibility for the action. If the agency writes a bad instruction, that is one failure. If the agent takes an irreversible action without a person seeing it first, that is another.

Check exactly where approval sits

The word "approval" can cover several very different designs. A Slack message saying "OK?" is an approval process of sorts. So is a dedicated card that shows the exact action, its cost so far and a deadline. Those are not equivalent when a client disputes what happened later.

For every white label agent, ask which actions stop automatically and which can proceed on the original brief. Then test concrete cases: first contact with a prospect, deleting a client record, connecting a new integration, widening permissions, sending money, publishing a post, or accepting terms.

In Delagents, eight kinds of action always need a person, including first contact outside the workspace, moving money, deleting or overwriting records the agent did not create, changing roles or policy, connecting integrations or widening scopes, accepting terms, publishing publicly, and acting in another workspace. Those actions wait in the approvals inbox, where a person can approve, change or reject the exact action.

Even if an agency uses another system, this is the level of specificity to look for. "Human approval available" is too vague. You want to know what is blocked by policy, what the reviewer sees, and whether the agent can work around a rejection by taking a different route.

Decide what the client can see

White label often gets discussed as a question of logos, domains and colours. Client visibility is the harder question. If your agency presents the agent as part of its own service, what evidence will the client see when they ask why something was done?

There are several useful layers to separate. The client may see the final deliverable but not the working notes. They may see approval requests but not every tool call. They may need a complete activity record for work that touches finance or customer records. These choices should be deliberate rather than inherited from a generic admin dashboard.

This also affects account management. If a client can inspect the work, the agency needs to be comfortable with what that view says about its process. Hiding every intermediate step may make the service feel tidy until something goes wrong and nobody can reconstruct the decision.

Find out where the client's data goes

Before putting an agent inside a client service, write down every place client information may pass through. That includes the workspace, connected tools, files, logs, agent context and any system used to produce the deliverable.

Do not stop at a provider saying data is "secure." Ask where it is stored, which integrations can access it, what permission scopes those integrations receive, what gets retained in activity logs, and who can change those permissions. Check whether connecting a new system is treated as routine configuration or as an action that needs a person to approve it.

For an agency, this should become part of client setup. A campaign research agent may need access to a shared folder and nothing else. A bookkeeper may need financial records but should not inherit permissions from an owner's entire account. The useful question is not "Can the agent connect to this?" It is "What is the smallest access this delegation needs?"

You should also decide what happens when the client leaves. Work out which records must remain for the agency's own audit trail, which client data should be removed, and which connected permissions must be revoked.

Test the service when the agent is wrong

A polished demonstration usually shows the agent completing a task correctly. That is not the test an agency should rely on before putting its name on the service. Give it an awkward brief. Change a fact halfway through. Reject an approval. Let a budget run close to its cap. Remove access to a tool it expected to use.

Watch what happens next. Does it stop and explain the block, or improvise? Can it request a changed action after a reviewer rejects the first one? Does a hard budget limit actually stop more spending? Can you see the tool calls and policy changes that led to the result?

These tests tell an agency far more than a list of supported agent roles. A research analyst and a support triager may look like different products, but the same operating questions apply to both: what can they access, what can they change, where do they stop, and who signs off?

Define the offer before you resell it

Do not start by promising a client "an AI employee." Write a one-page service boundary instead. Name the jobs the agent can take, the systems it may use, the actions that always require approval, who receives those approvals, the budget cap for each delegation, and what evidence the client can inspect afterwards.

Then run one representative task through that boundary. For an outreach service, have the agent research a lead, prepare the first message and stop before contact. For a finance service, have it prepare a payment or refund and stop before money moves. For content work, have it produce the piece and stop before publication.

If you are designing that offer around Delagents, the agency workspace is built around briefs, agent work, sign-off checkpoints and delivered outputs. Use the first pilot to write down every point where your agency, your client or the agent has authority. If any action still has two possible owners, fix that before you put your brand on it.