# Multi-tenant Copilot: prompts that hot-swap per customer

One Copilot component, different system prompts per tenant, per user, per route. No hardcoded personas, no redeploys to change a tone.

Everybody who ships AI features for multiple customers eventually hears the same request: "can our bot sound more like us?" It's a reasonable ask. A legal SaaS wants the bot to hedge like a lawyer. A sales tool wants it assertive. A kids' platform wants it friendly and clamped. Three very different system prompts.

The bad way to handle this is forking the repo per customer. The next-worst way is a config service that's technically correct and operationally sad. The good way is three attributes on a web component.

## Instructions are a prop, not a deployment

Copilot takes an `instructions` attribute. It's a string. You render it server-side with the tenant's chosen persona. No build step, no cache bust, no prompt registry.

```html
<wy-copilot
  agent="assistant"
  instructions="<%= tenant.botInstructions %>"
></wy-copilot>
```

`tenant.botInstructions` is a row in your database. Change it, refresh the page, done. If you want the change to only apply on certain routes, use a different string in that route's render.

## Reference data travels with the component

Instructions tell the agent how to behave. `contextualData` tells it what it's looking at. Mount the Copilot anywhere and hand it a JSON string describing the current view.

```html
<wy-copilot
  agent="assistant"
  instructions="<%= tenant.botInstructions %>"
  contextualData='<%= JSON.stringify({
    tenantName: tenant.name,
    plan: tenant.plan,
    featuresEnabled: tenant.features
  }) %>'
></wy-copilot>
```

Same agent, same Copilot, different context per render. A customer admin sees one set of reference data; an end user sees a narrower subset. It's all props.

## Scoped conversation history, automatically

Copilot separates conversations per authenticated user out of the box — you don't have to stitch a tenant id into a uid by hand. Each user sees their own history; tenants don't leak. The authentication you wire to Weavy is what scopes the data.

## What you don't have to build

- A prompt template service that maps tenants to strings at request time.
- A context propagation layer from your route to the model.
- Tenant-isolated conversation storage that somebody on the team has to audit.

One Copilot component, three attributes, every tenant gets their own personality without a new deploy.

## Ship the collaboration layer today

Free to start. No credit card. Your first component running in under ten minutes.