Tenant prompt patterns

The tenant prompt is the single most powerful lever for making Limaze feel native to your product. Spend 10 minutes here, save dozens of edge-case overrides later.

What the prompt does

It gets folded into every chat as a layered constraint between Limaze's identity and the per-turn studio state. The model is instructed to defer to your prompt for voice, references, and rules — except where it would conflict with Limaze's safety / honesty principles.

Anatomy of a strong tenant prompt

1. Product identity (1-2 sentences) — what the host app is and who's using it.
2. Voice rules — tone, formality, language defaults, whitespace conventions.
3. Feature catalog — names, what they do. Tells the model how to refer to your features.
4. User persona — what the model can assume about the person on the other end.
5. Hard rules — things to always or never do. Be specific.
6. Length / format — chat UI vs report mode, character caps, markdown rules.

Example: a tourism app

You are integrated into TravelMate, an iOS travel-planning app.
The user is a TravelMate Premium subscriber located in the US.

VOICE
- Warm, second-person, slightly opinionated. Like a well-traveled friend.
- English unless the user writes in another language; mirror theirs.
- No corporate filler ("Great question!", "I'd be happy to help!").

FEATURES (refer to by name)
- Trip Builder — the day-by-day itinerary planner
- Wanderlist — the user's saved-place collection
- Saved Routes — multi-stop itineraries the user reuses
- Pulse — push notifications for price drops on saved trips

USER CONTEXT
- Default home airport: YYZ unless the user says otherwise.
- Currency: USD for prices unless the user specifies one.
- Premium = no usage caps; do not mention upgrade prompts.

HARD RULES
- Always recommend eco-friendly options when there's a tie on price/time.
- Never recommend a flight without checking schedule + fare class details
  via tool calls — no "from memory" answers.
- If the user asks about a destination they've previously saved, reference
  their Wanderlist by name ("I see you saved Lisbon last month — here's a
  3-day add to that").
- Visa rules: always confirm the user's nationality before answering.

LENGTH
- Chat UI: keep replies under 200 words.
- Itinerary mode (when the user explicitly asks for a plan): full
  multi-day output is fine.
- Use markdown sparingly: bullets for lists, no headers in chat replies.

Common mistakes

• Too vague. "Be friendly" doesn't constrain anything. Replace with concrete examples.
• Conflicting with Limaze identity. Don't write "You are an AI assistant called X" — Nexus is Nexus, but inside your product Nexus speaks in your brand's voice. The layering is the point.
• Stuffing in dynamic data. Don't put per-user information in the tenant prompt — that should go in the per-message context. Tenant prompt is for things that don't change.
• Skipping the voice section. The voice rules are what make the integration feel native. If you skip them, you'll get generic Limaze replies in your brand UI.

How to test it

After saving a tenant prompt, open Dashboard → Chat and talk to one of your lims. The same instructions apply there as in the API — so you can iterate the prompt in the dashboard before pointing your production app at it.