Single-Tenant Agent Platform

When to use it

A contractual requirement that one customer’s data never shares infrastructure with another’s.
Data residency obligations that differ per customer.
A small number of large customers — the operational cost scales with the number of tenants, so this stops being practical somewhere between twenty and a hundred.

Diagram

                    ┌────────────────────────────┐
   customer app ───►│  Edge / API gateway        │
                    │  authn, rate limit, region │
                    └──────────┬─────────────────┘
                               │  routed by tenant claim
        ┌──────────────────────┴──────────────────────┐
        ▼                                             ▼
┌───────────────────────┐                    ┌───────────────────────┐
│ Tenant A (region eu)  │                    │ Tenant B (region us)  │
│ ┌───────────────────┐ │                    │ ┌───────────────────┐ │
│ │ Velerion env prod │ │                    │ │ Velerion env prod │ │
│ │  agents, tools    │ │                    │ │  agents, tools    │ │
│ └────────┬──────────┘ │                    │ └────────┬──────────┘ │
│  ┌───────▼────────┐   │                    │  ┌───────▼────────┐   │
│  │ tenant secrets │   │                    │  │ tenant secrets │   │
│  ├────────────────┤   │                    │  ├────────────────┤   │
│  │ tenant data    │   │                    │  │ tenant data    │   │
│  └────────────────┘   │                    │  └────────────────┘   │
└───────────────────────┘                    └───────────────────────┘
        │                                             │
        └──────────────► central control plane ◄───────┘
                    (deploy, audit, usage rollup only)

Components

Component	Responsibility
Edge gateway	Terminates TLS, authenticates the caller, resolves the tenant claim to a target deployment, enforces per-tenant rate limits.
Tenant workspace	One Velerion workspace per tenant, with its own environments, connections and secret store.
Central control plane	Deploys the same agent revision to every tenant, aggregates usage and audit data. Holds no tenant payload data.
Tenant data store	Owned by the tenant deployment. Reached only through an MCP connection scoped to that workspace.

Deployment

Promote one revision across every tenant workspace in a controlled order:

REVISION=$(velerion agents show support-triage --env prod \
  --workspace canary-tenant --json | jq -r '.revision')

for ws in tenant-a tenant-b tenant-c; do
  velerion promote --agent support-triage \
    --workspace "$ws" --from staging --to prod \
    --revision "$REVISION" --yes
  velerion agents show support-triage --workspace "$ws" --env prod --json \
    | jq -e '.health == "healthy"' || exit 1
done

Always include a canary tenant that receives the revision first, and gate the loop on its health check rather than on elapsed time.

Failure modes

Failure	Blast radius	Mitigation
Tenant data store unavailable	One tenant	Per-tenant circuit breaker at the gateway; agent degrades to a no-tool response.
Bad agent revision	Canary tenant only, if the rollout is gated	`velerion rollback --workspace <ws> --env prod`.
Control plane outage	Deploys blocked; running agents unaffected	Control plane is not on the request path. Verify this with a game day.
Credential leak in one tenant	One tenant	Secrets are per-workspace with no shared root.

Trade-offs

Cost and toil scale linearly with tenants. Every tenant is another set of quotas, another rollout to watch and another bill line.
Cross-tenant analytics get harder. Usage rollup is the only shared path, so anything not in that rollup requires a new aggregation you have to build and secure.
Slower fleet-wide fixes. A one-line prompt correction still needs a full staged rollout.
Regional model availability differs. An agent pinned to a model that is unavailable in a tenant’s region fails at deploy time — verify availability per region in staging.