Building White-Label Agentic AI: Multi-Tenant Reseller Platform Guide

The White-Label Opportunity for Agentic AI

The fastest way to scale an agentic AI business beyond direct sales is to enable other companies to resell your platform under their own brand. White-label distribution lets you acquire hundreds of end customers through a single reseller partnership rather than closing each deal individually.

Consider the economics. Closing a direct enterprise sale takes three to six months of sales effort and costs $5,000 to $20,000 in sales and onboarding expenses. Closing a reseller partnership takes a similar investment, but that single deal can deliver 50 to 500 end customers as the reseller deploys across their existing client base. The customer acquisition cost per end user drops by an order of magnitude.

This model works particularly well for agentic AI because the core agent infrastructure is the same across deployments. A dental scheduling agent and a veterinary scheduling agent use the same underlying conversation engine, tool framework, and voice processing pipeline. What differs is the branding, the system prompt, the specific tools configured, and the integration with each business's systems. White-labeling lets you build the platform once and deploy it thousands of times with different configurations.

This guide covers the architecture, business models, and implementation patterns for building a white-label agentic AI platform based on patterns from CallSphere's multi-vertical deployment infrastructure.

Multi-Tenant Architecture

Tenant Hierarchy

A white-label platform has at least three levels of tenancy that must be modeled in your data layer and enforced in your access control.

flowchart LR
    INPUT(["User intent"])
    PARSE["Parse plus<br/>classify"]
    PLAN["Plan and tool<br/>selection"]
    AGENT["Agent loop<br/>LLM plus tools"]
    GUARD{"Guardrails<br/>and policy"}
    EXEC["Execute and<br/>verify result"]
    OBS[("Trace and metrics")]
    OUT(["Outcome plus<br/>next action"])
    INPUT --> PARSE --> PLAN --> AGENT --> GUARD
    GUARD -->|Pass| EXEC --> OUT
    GUARD -->|Fail| AGENT
    AGENT --> OBS
    style AGENT fill:#4f46e5,stroke:#4338ca,color:#fff
    style GUARD fill:#f59e0b,stroke:#d97706,color:#1f2937
    style OBS fill:#ede9fe,stroke:#7c3aed,color:#1e1b4b
    style OUT fill:#059669,stroke:#047857,color:#fff

The platform level is your company. You own the infrastructure, the agent framework, the LLM integrations, and the core technology. The reseller level is your direct customer. Each reseller sells the product under their own brand to their clients. They have their own admin dashboard, branding configuration, billing relationship, and customer support channel. The end tenant level is the reseller's customer — the individual dental practice, real estate agency, or auto repair shop that actually uses the agent to handle their calls or chats.

Platform (Your Company)
  +-- Reseller A (HealthTech Solutions)
  |     +-- End Tenant: Smile Dental Clinic
  |     +-- End Tenant: CityVet Animal Hospital
  |     +-- End Tenant: Family Care Medical
  +-- Reseller B (PropTech Agency)
  |     +-- End Tenant: Downtown Realty
  |     +-- End Tenant: Sunrise Properties
  +-- Reseller C (BizPhone Pro)
        +-- End Tenant: Mario's Pizza
        +-- End Tenant: Elite Auto Repair

Data Isolation Is Non-Negotiable

Every database query, every API response, every log entry must be scoped to the correct tenant. Data leakage between tenants — even between end tenants under the same reseller — is a security incident that can destroy customer trust and create legal liability.

Implement data isolation at multiple layers for defense in depth. At the database layer, add a tenant_id column to every table and enable PostgreSQL row-level security policies.

ALTER TABLE conversations ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON conversations
    USING (tenant_id = current_setting('app.current_tenant_id')::uuid);

CREATE POLICY reseller_isolation ON conversations
    USING (reseller_id = current_setting('app.current_reseller_id')::uuid);

At the application layer, set the tenant context in request middleware based on the authenticated user and ensure every database session inherits the correct scope.

@app.middleware("http")
async def tenant_context_middleware(request: Request, call_next):
    user = await get_authenticated_user(request)
    request.state.tenant_id = user.tenant_id
    request.state.reseller_id = user.reseller_id

    async with get_db_session() as session:
        await session.execute(
            text(f"SET app.current_tenant_id = '{user.tenant_id}'")
        )
        await session.execute(
            text(f"SET app.current_reseller_id = '{user.reseller_id}'")
        )
    return await call_next(request)

At the API layer, validate that every request's target resource belongs to the authenticated user's tenant. Never rely solely on database-level filtering — add explicit checks in your API handlers as a second line of defense.

Shared Versus Dedicated Resources

Most end tenants share the same database, application servers, and LLM API keys. This shared-infrastructure model is efficient and keeps per-tenant costs low, which is essential for enabling resellers to price competitively.

For large or compliance-sensitive tenants, offer a dedicated tier with isolated database schemas or separate database instances, dedicated application pods with resource guarantees, separate LLM API keys for independent rate limiting and cost tracking, and dedicated phone numbers and voice processing resources.

Custom Branding System

Configuration Model

Store branding configuration per reseller as structured data that the frontend consumes at render time.

{
  "reseller_id": "reseller_healthtech",
  "branding": {
    "company_name": "HealthTech Solutions",
    "logo_url": "/uploads/resellers/healthtech/logo.svg",
    "favicon_url": "/uploads/resellers/healthtech/favicon.ico",
    "primary_color": "#2563EB",
    "secondary_color": "#1E40AF",
    "accent_color": "#60A5FA",
    "font_family": "Inter, sans-serif",
    "border_radius": "8px"
  },
  "emails": {
    "from_name": "HealthTech Solutions",
    "from_address": "notifications@healthtechsolutions.com",
    "reply_to": "support@healthtechsolutions.com"
  },
  "legal": {
    "terms_url": "https://healthtechsolutions.com/terms",
    "privacy_url": "https://healthtechsolutions.com/privacy"
  }
}

The frontend application reads this configuration at page load and applies it through CSS custom properties or a theme provider. This approach lets a single deployed frontend codebase serve every reseller with unique branding — no separate deployments per reseller needed.

Custom Domain Routing

Resellers expect their dashboard to be accessible at their own domain such as ai.healthtechsolutions.com rather than a subdomain of your platform. Implement this with a reverse proxy like Caddy or Traefik that routes based on the Host header and provisions SSL certificates automatically.

The onboarding flow for a custom domain works as follows. The reseller registers their desired domain through your admin API. Your system instructs them to create a CNAME DNS record pointing to your platform's load balancer. A background worker detects the DNS propagation and provisions a Let's Encrypt SSL certificate. The reverse proxy configuration is updated to route requests for that domain to your application with the reseller context injected via headers.

# Dynamic Caddy configuration
ai.healthtechsolutions.com {
    reverse_proxy app-server:3000 {
        header_up X-Reseller-ID "reseller_healthtech"
    }
    tls {
        dns cloudflare {env.CF_API_TOKEN}
    }
}

For platforms with dozens or hundreds of resellers, use Caddy's on-demand TLS or Traefik's dynamic configuration to avoid manually maintaining proxy configs.

Configurable Agent Personas

Each end tenant needs an agent that sounds and behaves like an extension of their specific business. The challenge is enabling deep customization without giving tenants the ability to break the agent or create security vulnerabilities.

Layered Configuration

Agent configuration follows a three-layer inheritance model. Platform defaults provide sensible baseline behavior for all agents. Reseller overrides let resellers customize the defaults for their vertical and brand — for example, a healthcare reseller might set a more formal tone across all their tenants. End tenant overrides let individual businesses customize greeting messages, business hours, specific service offerings, and other business-specific details.

At runtime, merge these layers with end tenant settings taking highest priority.

def resolve_agent_config(tenant_id: str, reseller_id: str) -> AgentConfig:
    platform = load_platform_defaults()
    reseller = load_reseller_overrides(reseller_id)
    tenant = load_tenant_overrides(tenant_id)

    merged = deep_merge(platform, reseller, tenant)
    return AgentConfig(**merged)

Safe Customization Boundaries

Allow tenants and resellers to customize through structured forms, not raw prompt editing. Safe-to-customize fields include the agent's display name and voice selection, greeting and closing messages, business hours and timezone, service types and appointment durations, escalation phone numbers and email addresses, and notification preferences.

Fields that require review before deployment include system prompt modifications beyond the designated insertion points, custom tool integrations that call external APIs, and data retention policies that differ from the platform default.

Usage Billing and Revenue Sharing

Metering Infrastructure

Track usage at the most granular level available and aggregate for billing. Every conversation event records the tenant ID, reseller ID, conversation ID, duration, LLM token counts, tool calls made, and communication channel used.

An hourly aggregation job rolls these events into daily usage summaries per tenant and per reseller. At month end, an invoice generation process calculates charges based on the reseller's billing model and generates invoices for each reseller and optionally for each end tenant.

Revenue Sharing Models

Three models dominate white-label agentic AI partnerships. In the wholesale model, resellers purchase conversation capacity in bulk at a discount and resell at whatever margin they choose. You charge $0.15 per conversation and the reseller charges their end tenants $0.45 per conversation, keeping the $0.30 spread. In the revenue share model, you and the reseller split end-tenant revenue at an agreed ratio such as 70/30 or 60/40. The reseller handles sales and support while you provide the platform and technology. In the platform fee model, resellers pay a monthly platform fee based on their total usage tier, and you do not involve yourself in their end-tenant pricing.

Reseller Analytics Dashboard

Resellers need a comprehensive dashboard showing their business performance across their entire tenant portfolio. Key views include total revenue with breakdown by end tenant and monthly trends, conversation volume across all tenants with per-tenant drill-down, agent performance metrics aggregated and per-tenant to identify underperforming deployments, billing summary with upcoming invoice preview and payment history, and tenant management for provisioning new end tenants, updating configurations, and managing integrations.

API Provisioning for Technical Resellers

Resellers with engineering teams want programmatic access to manage their tenant portfolio and integrate agent capabilities into their own products.

Provide well-documented REST APIs for tenant lifecycle management including creation, configuration, suspension, and deletion. Provide endpoints for agent configuration updates, usage data and billing queries, conversation history access for their tenants, and webhook registration for real-time event notifications like conversation completed, escalation triggered, or error occurred.

Authenticate reseller API access with scoped API keys. Each key should grant access only to that reseller's tenants and resources. Implement rate limiting starting at 100 requests per minute with the ability to increase for high-volume resellers.

Frequently Asked Questions

How many resellers should I have before investing in white-label infrastructure?

Build lightweight white-label capability — branding configuration and basic tenant management — after your first serious reseller conversation. Invest in full infrastructure (custom domains, API provisioning, automated billing) after you have three to five signed resellers and can validate the requirements from real usage. Building the complete platform before you have reseller demand risks over-engineering for requirements that do not actually exist.

How do I prevent data leakage between tenants in a shared-infrastructure model?

Defense in depth. First, enforce row-level security at the database layer using PostgreSQL RLS or equivalent. Second, set tenant context in application middleware and ensure every query inherits the filter. Third, add explicit tenant ownership checks in API handlers before returning data. Fourth, write automated tests that create two test tenants and verify that queries from one tenant never return data from the other. Run these tests in your CI pipeline on every deployment.

What is the best billing model for resellers?

It depends on your reseller's sales motion. If they sell to price-sensitive small businesses, the wholesale model gives them pricing flexibility. If they are adding your agent as a feature in their existing software platform, revenue share aligns incentives well. If they are large enough to commit to volume, the platform fee model provides you with predictable revenue. Many platforms start with one model and add others as they learn what different reseller segments prefer.

Should resellers be able to modify agent system prompts?

Provide structured customization, not raw prompt access. Let resellers configure specific fields — business details, tone preferences, escalation rules, greeting messages — through forms. These values are injected into your prompt template at designated insertion points. Direct prompt editing creates risk because a poorly written modification can break agent behavior, introduce security vulnerabilities, or cause compliance violations. If a reseller has a legitimate need for deep customization, handle it as a professional services engagement with your team reviewing the changes.

How do I handle a reseller that churns and has active end tenants?

Define the process contractually before it happens. Standard options include a 90-day wind-down period where service continues at the current rate to give end tenants time to find alternatives, an option for end tenants to migrate to a direct relationship with your platform, the ability for another reseller to assume the departing reseller's tenant portfolio, and data export capabilities so end tenants can take their conversation history and configuration with them. Technically, ensure your platform supports reassigning end tenants from one reseller to another or to direct platform management without data loss or service interruption.