A 12-person agency can sell a convincing AI assistant in a week, then lose a regulated European prospect during the security review. The problem usually isn't the model's quality. It's that the agent can't run on the client's domain, the tenant boundary is unclear, inference leaves the EU, or nobody can explain which logs contain customer data.
That gap defines white label AI agents in practice. You aren't merely changing a logo. You're operating a branded runtime, managing client environments, controlling access, handling billing, and proving that one customer's data can't leak into another customer's workspace. Market forecasts indicate that the broader AI agents category is still early but expanding rapidly. One 2026 market estimate places the global market at USD 7.63 billion in 2025, with a projection of USD 182.97 billion by 2033, while another estimate puts it at USD 8.29 billion in 2025 and USD 53.2 billion by 2030. Those figures are useful context, but they don't remove the operational work.
This guide is for agency founders, platform engineers building multi-tenant products, and MSP operations leads. It focuses on isolation, custom domains, managed SSL, model-key ownership, shared memory, integrations, EU residency, pricing, and fleet operations. It doesn't cover custom model training, voice agents, or on-device inference.
Table of Contents
What White Label AI Agents Actually Mean in 2026
A white label AI agent is a deployed runtime that an agency or operator brands, hosts, and bills under its own identity. A third party may provide the underlying model, orchestration layer, machine, connectors, or observability stack, but the client experiences your product. They see your domain, your support process, your invoice, and your access controls.
That distinction matters because buyers don't purchase branding in isolation. They purchase a working service with a clear owner. If an agent sends a report to Slack, opens a GitHub pull request, searches a knowledge base, or handles an internal request, your team is accountable when it behaves incorrectly.
A useful operating model has three layers:
Branded surface: The client uses a domain, login screen, email identity, favicon, and legal footer that belong to your agency.
Managed runtime: You provision, patch, monitor, and version the agent rather than handing over an unmanaged prompt.
Commercial wrapper: You decide whether the client pays for seats, usage, a managed service, or a combination.
This is why the category sits inside a broader white-label software economy. A 2026 industry overview of white-label AI agents reports a USD 99.19 billion white-label AI market in 2026 and says 73% of agencies use white-label services in some form. A separate estimate places white-label SaaS at USD 235.9 billion in 2025 and projects USD 278 billion in 2026, a 16.2% year-over-year increase. Those figures describe adjacent categories, not a precise white-label agent market, but they show why agencies are treating managed AI as a service line rather than a one-off experiment.
If your buyer expects a private assistant, a client-facing portal, or a set of connected workplace agents, the operational framing fits. If the project depends on training a proprietary foundation model, running inference on a device, or building a phone system, it needs a different architecture and sales process. The enterprise AI agent platform perspective is a useful reference point for thinking about the runtime rather than just the interface.
Choosing the Runtime and Isolation Architecture
The isolation model determines your long-term blast radius. You need to decide where the agent process runs, how state is partitioned, who can reach the network, and what evidence you can provide when a client's security team asks for a tenant-boundary explanation.
A dedicated machine or container per client gives the cleanest boundary. The client gets separate compute, storage, credentials, logs, and network policy. That costs more to operate and can make fleet-wide upgrades slower, but the audit story is straightforward. A shared cluster with namespace-level isolation uses resources efficiently, yet the burden shifts to policy enforcement, secret management, storage controls, and evidence that a compromised workload can't reach another tenant.
Most agencies eventually use a hybrid. The control plane is shared, while each client receives its own worker pod, credentials, queue partition, and vector store. This avoids duplicating every management service while keeping the data plane easier to inspect. It works only if the shared control plane never becomes a back door into tenant data.
The failures that appear after launch
Production failures rarely come from the headline architecture. They come from forgotten shared components:
Noisy-neighbor latency: One client's crawling or indexing job consumes CPU, memory, queue capacity, or model concurrency, and another client's agent becomes slow.
Token-budget bleed: A global budget or retry counter lets one tenant consume capacity assigned to another, making usage reporting and margin control unreliable.
Cross-tenant observability leakage: Shared logs include prompts, tool arguments, document names, or trace metadata from the wrong client.
Give every request a tenant identifier at ingress, carry it through queues and tool calls, and enforce it again at storage and log query time. Don't rely on a dashboard filter as a security boundary. Test deletion, export, backup restoration, and incident access with the same tenant context.
| Dimension | Dedicated VM per client | Shared cluster with namespaces | Hybrid control plane |
|---|---|---|---|
| Isolation boundary | Strong machine and storage separation | Logical separation enforced by cluster policy | Shared management, separated client workers and data stores |
| Operating cost | Higher | Lower | Moderate |
| Upgrade experience | Client-specific rollout | Centralized rollout | Shared control updates, staged worker updates |
| Audit explanation | Easy to describe | Requires detailed evidence | Clear if data-plane boundaries are enforced |
| Blast radius | Usually limited to one client | Potentially broader after a control failure | Depends on control-plane privileges |
| Best fit | Strictly regulated or high-value tenants | Lower-risk, high-volume deployments | Agencies balancing control and efficiency |
The multi-tenant AI agent isolation guidance is relevant here, but the decision still belongs to your risk model. Choose isolation by the strictest compliance regime you'll ever serve, not the easiest prospect you can onboard this month. If a European regulated client would reject shared storage or ambiguous inference routing, build that constraint into the platform before a sales commitment makes it expensive to change.
Setting Up Custom Domains and Managed SSL
A custom domain turns a vendor-hosted tool into a service your agency can own. Start with a hostname such as portal.client-domain.example, point it to the white-label ingress through a CNAME record, and let the platform terminate TLS at the edge. Keep the client domain separate from your internal management domain so a branding change can't expose operational endpoints.
For certificate automation, use an ACME-compatible issuer with automatic renewal. A DNS-01 challenge is the practical choice when you need wildcard coverage or when the agent's routes may change. It proves control through a DNS challenge rather than requiring a public HTTP path, which makes it more flexible for private deployments.
A reliable onboarding sequence
Create the tenant hostname: Record the client domain, expected redirect behavior, and whether the service is public or private.
Publish the CNAME: Ask the client to add the CNAME through its DNS provider, then verify the record before issuing the certificate.
Issue and renew TLS: Store certificate status in the tenant dashboard and alert before renewal failure. A forgotten renewal loop can take down a perfectly healthy agent.
Test the complete surface: Check login, redirects, API callbacks, email links, mobile rendering, and certificate coverage from outside your own network.
The access model deserves the same attention as DNS. Public invite-only access works for broad SaaS distribution when paired with email allowlists and SSO. A Tailscale-private mode is often a better default for legal, healthcare, and EU mid-market workloads because only nodes on the client's tailnet can reach the agent. Private access reduces exposure, but it also adds onboarding work and requires a clear plan for external users.
Don't stop at the logo. Review the login subdomain, outbound From address, favicon, support address, privacy policy link, terms link, and legal footer. Clients notice inconsistent identity during procurement, and users notice it when an email sends them to an unfamiliar domain.
One practical trap appears during concentrated onboarding. Issuing many certificates against a production ACME endpoint in the same week can trigger Let's Encrypt rate limits. Use the staging endpoint while validating DNS and certificate automation, then issue production certificates only after the records and renewal path pass your checks.
Deciding Between Bring Your Own Keys and Hosted Billing
Model credentials determine who owns usage risk. They also determine how easily you can answer a client asking which organization paid for a request, where the prompt was processed, and whether a departing administrator still has access.
The three common patterns are bring your own keys, hosted credits, and ChatGPT plan sign-in. BYOK gives each client control of its OpenAI, Anthropic, or other provider credentials. Hosted credits put you in the middle, so you meter usage and charge the customer. OAuth sign-in lets an end user authenticate with a consumer ChatGPT subscription where the runtime supports that flow.
| Dimension | BYOK | Hosted Credits | ChatGPT Sign-in |
|---|---|---|---|
| Cost pass-through | Client pays the model provider directly | Agency pays first and rebills usage | End user uses an eligible consumer plan |
| Rate-limit isolation | Strong if keys are truly tenant-specific | Depends on your metering and provider account design | Depends on account and provider limits |
| Billing complexity | Lower platform billing, higher credential support | Highest, because you need metering, limits, invoices, and disputes | Simple for the agency, less suitable for managed enterprise billing |
| Audit trail | Clear provider account ownership when configured correctly | Centralized, but attribution depends on your telemetry | May not match enterprise procurement or retention requirements |
| Compliance fit | Usually strongest for regulated clients | Useful for prototypes and smaller teams | Often unsuitable where enterprise control is required |
| Main operational risk | Rotated, expired, or incorrectly scoped keys | Margin erosion and unexpected usage | Account eligibility, policy, and ownership ambiguity |
BYOK sounds clean until a client rotates a key without telling you. The agent starts failing, support receives an application error, and nobody knows whether the provider rejected the credential or the runtime lost access. Shared provider keys create a different failure: you can no longer attribute cost, rate limits, or abuse to a specific tenant with confidence.
Hosted credits are convenient during a prototype or for smaller clients that don't want a provider relationship. Put hard limits around them. Meter requests by tenant, model, tool, and environment, expose usage to the client, and stop or degrade gracefully when a budget is exhausted.
Commercial rule: If you can't show a client exactly how model usage is attributed, don't promise transparent usage billing.
For regulated clients, BYOK is often the more defensible arrangement because the customer controls the provider account and can review its own relationship with the model vendor. It isn't automatically compliant, though. You still need to control secrets, prevent logs from capturing them, restrict which workers can read them, and revoke access when the contract ends.
Wiring Up Slack, GitHub, Notion, and Shared Memory
Treat integrations as infrastructure, not agent features. If every bot has its own Slack handler, GitHub client, Notion token, and retry logic, the fleet becomes a collection of small products that fail differently.
A better pattern uses one integration layer. Register one OAuth app per client workspace where the platform allows it, store the resulting credentials inside that tenant, and expose normalized events to every agent. The connector handles authentication, retries, rate limits, webhook validation, and revocation. Agents consume events and call tools through a stable interface.
Shared memory belongs beside that integration layer. Create one memory store per client tenant, then route reads and writes by workspace, channel, repository, project, or user context. A Slack agent answering a deployment question and a GitHub agent reviewing the related pull request should be able to use the same approved client context. That doesn't mean every agent should see everything. The router should select the narrowest permitted memory slice.
The integration details that matter
Slack: Track installation state and scopes. If a user revokes the installation mid-conversation, stop retrying, mark the connection as revoked, and return a clear reauthorization path.
GitHub: Use an installation identity where possible, record repository permissions, and revalidate after repository transfers or organization policy changes. App permissions can drift after a repo move.
Notion: Put rate-limit handling in the connector, not in each agent. Cache stable page metadata, queue writes, and preserve cursor state so a temporary limit doesn't produce duplicate updates.
Discord, Linear, and other channels: Normalize sender identity, tenant identity, and source object before the event reaches the agent. The source determines which memory slice is legal to read.
Memory needs lifecycle controls too. Give clients an export path, support deletion by source record, and record whether a memory item came from Slack, GitHub, Notion, or an operator edit. Otherwise, a client may delete the original document while the agent continues retrieving an untraceable copy from its index.
Meeting EU Data Residency and Compliance Requirements
EU residency isn't a dropdown that says “Europe.” It covers several data paths, and each path can use a different provider or region. A client may accept EU storage while rejecting US-hosted inference, or accept model processing outside the EU only under a documented transfer mechanism. Your architecture and contract need to reflect those distinctions.
Start by splitting the workload into three buckets:
Storage
Conversation transcripts, vector embeddings, uploaded files, cached tool results, backups, and deleted-record tombstones all need a location and retention policy. Pin vector stores to the approved EU region. Check where object storage replicas, snapshots, disaster-recovery copies, and support exports live. A deletion request isn't complete if the active database is clean but an old backup remains indefinitely without a documented erasure process.
Model inference
The prompt and completion may contain personal, confidential, or regulated information. Confirm the processing region for both the primary model and fallback models. A common deal-killer is routing inference through a US region because its GPU pool is cheaper, while presenting the product as EU-hosted.
Schrems II makes international transfers a design and documentation issue, not merely a procurement checkbox. Your data-processing agreement should identify subprocessors, transfer mechanisms, technical safeguards, and the circumstances under which a request leaves the approved region. Don't assume that an EU dashboard means the model provider processes every request in the EU.
Audit
Audit records should establish who accessed data, which agent acted, what tools it called, and which policy or legal basis governed the action. Separate operational telemetry from conversation content where possible, restrict administrator access, and define retention by record type. A client needs enough evidence to investigate an incident without giving every support engineer unrestricted transcript access.
Use the EU data residency requirements guide as a planning reference, then validate the final design with the client's DPO or counsel. Country-specific overlays can matter, including German BDSG obligations, French CNIL guidance, and Dutch AP positions. The correct configuration depends on the workload, sector, controller and processor roles, and the client's transfer assessment.
A practical pre-sale checklist should confirm:
Region pinning: Storage, embeddings, backups, and inference regions are explicit.
Subprocessors: The client receives a current list and change-notification process.
DPA terms: Processing purposes, retention, assistance, security, and deletion duties are documented.
Erasure propagation: Deletion reaches indexes, caches, replicas, backups, and derived memory.
Human controls: High-impact actions require approval, and operators can inspect the evidence behind an action.
Incident access: Break-glass access is logged, time-limited, and reviewed.
Enterprise surveys reflect this tension between interest and deployment maturity. PwC's AI agent survey reports that 79% of U.S. executives say agents are already being adopted, 88% plan to increase AI-related budgets, and 66% report measurable productivity gains. Cloudera's findings in the same verified brief identify data privacy at 53%, legacy integration at 40%, and implementation cost at 39% as leading barriers. The commercial lesson is direct: a residency answer often closes more deals than another model option.
Pricing, Packaging, and Operating the Fleet
Price the operating commitments, not just the agent. A client paying for a branded assistant is also paying for a tenancy boundary, model access, integration maintenance, incident response, domain management, and the judgment to stop an unsafe action.
A simple packaging structure can start with three levels:
| Tier | Tenancy Model | Model Billing | EU Residency | Custom Domain + SSL | Shared Memory | Support SLA |
|---|---|---|---|---|---|---|
| Launch | Shared cluster namespace | Hosted credits with limits | Not included | Optional | Single tenant | Business-hours support |
| Managed | Per-client worker and dedicated vector store | BYOK or metered hosted billing | Region-pinned storage | Included | Per-client fleet | Priority support |
| Regulated | Dedicated VM or strongly separated worker boundary | Client-controlled BYOK | EU storage and inference options | Included | Controlled shared memory | Contracted response process |
Seat-based pricing is easy for buyers to understand and easier for you to forecast, but it can punish a client whose agent serves a large internal population. Usage-based pricing aligns model expense with activity, yet it creates invoice anxiety and exposes your margin to provider changes. A hybrid usually works best: a recurring platform and support fee, an included usage allowance, and a transparent overage policy.
Charge separately, or gate by tier, for dedicated tenancy, EU residency, custom domains, managed SSL, premium integrations, longer retention, and human approval workflows. Don't hide these costs inside an undifferentiated “AI agent” line. If the buyer later asks for a dedicated worker or EU-only inference, you should be able to point to a defined capability rather than renegotiate the entire service.
Fleet operations after the contract is signed
Give each client an environment dashboard that shows health, version, integration status, model usage, memory growth, recent errors, and pending approvals. Pin agent versions per tenant. Test a new prompt policy or connector in staging, then roll it out to a Slack channel or change window where the client's technical contact can observe and approve it.
Your on-call routing needs an answer to “the AI is hallucinating in production.” Page the service owner, freeze risky tools, preserve the trace, and roll back the agent version or knowledge index. Don't make the client prove the problem through a long support ticket while the agent continues writing records or sending messages.
Use the first post-launch review to inspect:
Health checks: Runtime availability, queue depth, connector freshness, and failed tool calls.
Cost alerts: Unexpected model changes, retry loops, unusually large prompts, and tenant-level budget drift.
Memory growth: New sources, stale entries, duplicate facts, and deletion failures.
Quality signals: Escalations, rejected actions, user corrections, and unsupported requests.
Margin review: Hosting, model usage, support time, storage, and compliance work against the package price.
Annual prepaid contracts improve planning, while monthly usage arrangements reduce buyer commitment and make expansion easier. Either way, document renewal assumptions before launch. A client shouldn't discover that a “fixed” plan excludes the storage, integrations, or residency controls its security team required.
Sokko is one infrastructure option for this operating model. It provides always-on managed hosting for named agent runtimes, isolated machines, custom domains, invite-only access controls, shared persistent memory, connected apps, and US or EU hosting options with EU-hosted inference choices. Evaluate it alongside other platforms against your required isolation, audit, billing, and residency controls, then test the exact client workflow before committing.
If you're launching branded agents for multiple clients, visit Sokko to evaluate managed hosting, isolated deployments, custom domains, shared memory, and EU-region options in one operational layer. Start by mapping one client's data paths and support requirements, then use that deployment as the template for the rest of your fleet.