Build one agent. Give every customer their own.

Open a workspace for each customer. It holds their isolated runtime, credentials, knowledge, usage and record. Build your agent once, publish it once, and run it across all of them, with each customer kept in their own workspace.

Start building Talk to us

Workspaces

One customer. One workspace. Nothing to migrate.

A workspace is the boundary around everything that belongs to one customer: their sandbox, credentials, knowledge, memory, usage and records.

Create one when they sign up. Suspend it when they leave. Your application stays in control; Levain keeps each customer's agent environment separate.

Your product is the layer customers see; each has its own workspace underneath it Three customers — acme, borealis and vega — all log into your product, which is one layer across the top. Your product opens one workspace per customer through a single API call, and a wall stands between them. acme borealis vega your product POST /org/workspaces acme's workspace borealis' workspace vega's workspace
Open one, and close one 
POST /api/v1/org/workspaces
{ "name": "acme" }
201 { "id": "ws_7f3a", "lifecycle": "active", "headless": true }

POST /api/v1/org/workspaces/ws_7f3a/lifecycle
{ "state": "suspended" }
200 { "id": "ws_7f3a", "lifecycle": "suspended" }

Runtime

Give every run its own machine.

Every agent run starts in a fresh microVM belonging to one workspace. It is isolated from your infrastructure and every other customer, then destroyed when the run ends.

Your agent can run untrusted code without turning your application into its sandbox.

The lifetime of one run: created for the run, isolated while it lasts, destroyed when it ends A trigger starts a run. The run happens inside a fresh microVM that belongs to one workspace, with no route to your infrastructure and none to any other customer's workspace. The machine is created when the run starts and destroyed when it ends; the record and the meter are what survive it. your infrastructure every other workspace trigger API · schedule · Slack a fresh microVM, for this run only running in acme's workspace record and meter kept in the workspace created destroyed one run

Connections

Let the agent work in your customer's tools, not yours.

Connect the CRM, helpdesk, warehouse or other systems your customer uses. Their credentials stay inside their workspace and are never exposed to the model.

Decide which actions the agent can take automatically and which ones require approval, per tool and per agent.

The customer's credentials stay in their workspace; the agent reaches their tools without the model ever reading a key Inside acme's workspace, a connection holds acme's credentials. The agent calls out through them to acme's CRM, helpdesk and warehouse. A barred line between the credentials and the model shows the model is never handed the key, and the tools a node may call are declared in the agent itself. acme's workspace their credentials one connection per tool the model the tools this node may call @allowed_tools ["mcp__hubspot__*"] their CRM their helpdesk their warehouse

Memory & knowledge

Give the agent context without giving it someone else's.

Documents, connected sources and everything the agent remembers belong to the workspace that owns them.

The agent can work with the customer it is serving. It cannot browse another customer's knowledge, memory or data.

One call, scoped by the workspace 
GET /api/v1/wikis/current
X-Workspace-Id: ws_7f3a
200 { "name": "acme", "page_count": 214 }

GET /api/v1/wikis/current
X-Workspace-Id: ws_2b8c
200 { "name": "borealis", "page_count": 37 }

Build once

Build the agent once. Choose the model for the job.

Use models from multiple providers through one platform, including Anthropic, OpenAI, Google, Meta, Mistral and others, or bring your own keys.

Change the model without rebuilding your agent. Use different models for different tasks, then publish the same agent across every customer workspace.

The model is a setting

Change it without rebuilding your agent. The definition, the tools and the prompts stay exactly as they were.

"model": "claude-sonnet-5"

One model per task

Each step of an agent names its own. Route the cheap step to a small model and the hard one to a large model.

"model": "gpt-5-mini"
"model": "opus"

Or bring your own keys

Use Levain's model access, or point the platform at your own provider account and keep the billing relationship.

POST /api/v1/byok/openai

Improve

Don't just run agents. Make them better.

Give agents a loop for reflection, evaluation and improvement. Measure outcomes, learn from failures and test new versions against real work before rolling them out.

The agent you deploy today does not have to be the agent you keep tomorrow.

The loop a shipped agent runs through, and the approval that closes it A closed circuit. The running version leaves a record, Levain reads the outcomes and proposes the next version, and the circuit is broken on one side by an approval gate: nothing ships until you approve it. renewal-watcher v7 running everywhere outcomes read renewal-watcher v8 proposed you approve it

Usage

Cap what each customer can spend before it reaches your margin.

Credits pool at your organization while every workspace reports its own usage.

Set limits per customer, see exactly what each workspace consumed, and feed those numbers directly into your own billing.

See pricing
Spend this month against the limit set for each customer: acme at $18.24 of $20.00, nearing the limit you set; borealis at $9.31 of $25.00; vega at $2.07 of $10.00.

Record

Know exactly what happened, months later.

Every run records what the agent read, what it called, what a human approved and what it cost, tied to the exact agent version that produced it.

Publish a new version and the old record stays intact. Export any run as a printable page that carries your name, not ours.

Publishing a new version leaves the runs the old one produced exactly as they were A timeline of one agent. Version 6 is active up to the moment version 7 is published; version 7 is active after it. A run that finished before the publish still reports agent_version 6, and a run after it reports agent_version 7. Each run keeps the version that produced it. PATCH /api/v1/agents/agt_4b1/versions/7 { "status": "active" } the agent definition v6 v7 pinned run_9c2 agent_version 6 · $0.31 pinned run_a41 agent_version 7 · $0.28

Delivery

Put the agent where your customer already works.

Call it from your product, let it answer in Slack, or connect it through Claude and ChatGPT. Same agent. Same customer workspace. Wherever the conversation starts.

In your product

API and webhooks. Read the docs.

In Slack

Meet customers in the channel they already use.

In Claude and ChatGPT

Expose the same agent through MCP.

Frequently asked questions.

How is one customer kept apart from another?

Each customer gets a workspace with its own runtime, credentials, knowledge and memory. Agents can only access the workspace they are running in, and every run gets a fresh isolated machine.

Which models can I use?

Multiple model providers through one setting, including Anthropic, OpenAI, Google, Meta, Mistral and others. Use Levain's access or bring your own keys.

Can I control what an agent is allowed to do?

Yes. Set tool access and approval requirements per agent. Actions that require a human wait for approval before they run.

What happens when I publish a new version?

New runs use the version you publish. Previous runs keep their original version and record, so you can always see which agent actually did the work.

What if I want to leave?

Your agents, records and workspace data are available through the API. There is no export fee and no lock on your keys.

Build your first customer-facing agent today.

Start with one workspace. Build and test your agent there. When it is ready, publish it and give every customer their own isolated copy.

Start building Talk to us