Multi-tenant agent platform

You sell a product where each of your customers gets their own AI agents: a research assistant, a support triage bot, a codebase Q&A helper. Tenants must not see each other's threads, must have their own budgets, and you need a single view to see which tenant costs what. Building this with raw provider APIs means reinventing multi-tenancy for threads, messages and usage across every customer you onboard. Get isolation wrong. You ship a data leak.

Why Ringside

• FC-Customer = tenant. One Ringside Customer per tenant, enforced tenant-isolation on every read; cross-tenant access returns 404, not 403 (no ID enumeration).
• Assistants, Threads and Runs. OpenAI-compatible Assistants shim means your tenant bots have durable state, function tools and run lifecycle without you owning the schema.
• Per-Customer budgets and rate limits. Each tenant gets their own USD cap, RPM and TPM; margin reporting per tenant is one query away.

Architecture

In code

# One Ringside Customer per tenant in your app
tenant = client.customers.create(
    external_id=f"tenant_{org.id}",
    name=org.name,
    budget_usd=200.00,
)

# Per-tenant assistant, scoped via tool config + system prompt
assistant = client.beta.assistants.create(
    name=f"{org.name} research bot",
    model="fc:openai/gpt-4o",
    tools=[{"type": "function", "function": WEB_SEARCH_TOOL}],
    instructions=f"You answer questions about {org.product_name}.",
    metadata={"customer_id": tenant.id},
)

# Thread + run, pinned to tenant for billing + isolation
thread = client.beta.threads.create(
    metadata={"customer_id": tenant.id},
)
run = client.beta.threads.runs.create(
    thread_id=thread.id,
    assistant_id=assistant.id,
    extra_headers={"FC-Customer": tenant.id},
)

Cross-links

Examples

Endpoints

Used by

[TODO: real customers]

Get started in 5 minutes →