Writing Custom Context for Copilot

COPILOT_CUSTOM_CONTEXT tells Copilot about your product, your customers and the business they run. Copilot already knows how to build, edit and explain flows, how to talk to non-technical users and how to work with the components available to each user. What it cannot know on its own is your domain: what your users call things, how your data is organized and which decisions matter in your industry. Custom context fills that gap.

A good custom context is short, factual and specific to your product. It describes your world rather than giving Copilot new rules for how to build flows.

Choosing the right setting

Copilot has three places for extra context. Put each kind of information in the one that fits it.

Setting	Scope	Use it for
COPILOT_CUSTOM_CONTEXT	Whole instance	Your product, your users, domain vocabulary, data model and capabilities. Up to 16000 characters.
COPILOT_TONE_OF_RESPONSE	Whole instance	Voice, vocabulary and register of Copilot's replies, for example formality, spelling conventions or punctuation preferences. Up to 4000 characters.
aiContext on the user	One user	Details that differ per user or tenant, such as timezone, locale, or the site or account the user represents. See Per-user context.

What to include

Your product and its users

Name the product Copilot is embedded in and describe who uses it. Copilot only refers to the product by name when you give it one, and knowing the audience helps it choose the right words and examples.

## Product and users
You are the automation assistant inside VetDesk, a practice management platform for veterinary clinics.
Your users are practice managers and front-desk staff. They know their clinic well but are not technical.

Domain vocabulary and data model

Explain the key concepts in your domain, especially the ones that are easy to confuse, and what a single account or workspace represents. This keeps Copilot from applying an automation to the wrong records or assuming it spans more than it does.

## Vocabulary
- A "patient" is the animal. A "client" is the pet owner. Messages go to clients, never to patients.
- An "appointment" is a scheduled visit. A "visit" is an appointment that has taken place.
- A "reminder" is a message about a due vaccination or check-up, not about an appointment.
- One workspace is one clinic. An automation never applies to other clinics.

Business names for fields

Copilot never shows internal field names to users and describes data in plain language instead. When your connectors use field names that do not translate obviously, tell Copilot which business term to use.

## Field names
- "primaryContact" is the client's "main contact method".
- "apptSlot" is the "appointment time".
- "wellnessPlan" is the client's "care plan".

What your product offers and what it does not

Describe the capabilities your users can expect, and state clearly what does not exist. This stops Copilot from suggesting that a user set up something your product does not support.

## Capabilities
- Clients can be messaged by SMS or through the VetDesk client app. There is no email channel for client messages.
- Payments are handled outside VetDesk. Automations cannot charge clients or change invoices.

Decisions that matter in your domain

Copilot builds a working flow from what the user asked, makes reasonable assumptions where the request is unclear, and lists anything the user should check or decide next to the finished flow. Tell it which ambiguities matter in your domain, so it picks the safest interpretation and flags the right questions.

## Ambiguous requests
- "All clients" can mean clients with an upcoming appointment, clients with a reminder due, or every client of the clinic. Choose the narrowest group that fits and ask the user to confirm it.
- A reminder sent too often annoys clients. Unless the user says otherwise, send each reminder once per client and mention that choice.

What to leave out

Rules Copilot already follows. Copilot already avoids technical jargon in its replies, does not invent IDs or option values, uses only the components available to the user and lists open points separately from its summary. Repeating these adds length without changing behavior.

Instructions that change how Copilot works. Custom context is injected as a lower-authority section of the system prompt. It cannot override Copilot's core role, safety rules or flow-building rules. Instructions that try to change how flows are built, how many messages Copilot writes or how its summary is structured will be ignored or followed inconsistently. Describe your domain and let Copilot apply it.

Tone and style. Put these in COPILOT_TONE_OF_RESPONSE.

Per-user details. A timezone, site or account that differs between users belongs in each user's aiContext, not in the instance-wide context.

A catalogue of your components. Copilot reads component names, descriptions and fields directly while it builds. Describe what a component is for in its own description rather than in the custom context.

Secrets and personal data. The custom context is sent to the LLM provider with every Copilot request. Never include API keys, credentials or personal data about your customers.

Tips

• Use short Markdown sections with headings, as in the examples above.
• State facts rather than commands, and give the reason when it is not obvious ("a reminder sent too often annoys clients"). Copilot applies a rule more sensibly when it knows why the rule exists.
• Keep it focused. A few precise paragraphs work better than a long list of edge cases.
• After changing the context, try a handful of typical requests from your users and check the flows and replies. Changes apply without restarting a pod.

Complete example

The example below uses a fictional product. It combines the sections above into a single value for COPILOT_CUSTOM_CONTEXT.

## Product and users
You are the automation assistant inside VetDesk, a practice management platform for veterinary clinics.
Your users are practice managers and front-desk staff. They know their clinic well but are not technical.

## Vocabulary
- A "patient" is the animal. A "client" is the pet owner. Messages go to clients, never to patients.
- An "appointment" is a scheduled visit. A "visit" is an appointment that has taken place.
- A "reminder" is a message about a due vaccination or check-up, not about an appointment.
- One workspace is one clinic. An automation never applies to other clinics.

## Field names
- "primaryContact" is the client's "main contact method".
- "apptSlot" is the "appointment time".

## Capabilities
- Clients can be messaged by SMS or through the VetDesk client app. There is no email channel for client messages.
- Payments are handled outside VetDesk. Automations cannot charge clients or change invoices.

## Ambiguous requests
- "All clients" can mean clients with an upcoming appointment, clients with a reminder due, or every client of the clinic. Choose the narrowest group that fits and ask the user to confirm it.
- Unless the user says otherwise, send each reminder once per client and mention that choice.