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

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.

<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.

<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.