> For the complete documentation index, see [llms.txt](https://docs.appmixer.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.appmixer.com/getting-started/ai-copilot/custom-context.md). # 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](/getting-started/ai-copilot.md#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. ```markdown ## 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. ```markdown ## 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. ```markdown ## 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. ```markdown ## 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. ```markdown ## 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`. ```markdown ## 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. ``` --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.appmixer.com/getting-started/ai-copilot/custom-context.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.