AI
System Contexts
The "stance" and knowledge boundaries of an AI Agent. A system context contains instructions, examples, restrictions and data sources that shape every answer.
Updated May 18, 2026
Configuration · AI · 8.3
A System Context is an agent’s “stance”: the instructions it follows, the data sources it draws from, the tone it uses, the things it must not do. One agent can use several contexts; one context can be shared across agents.
Why this matters to the business
"AI answers wrong"
Context restricts the knowledge source to your KB → no wild inventions from the open web.
"Tone is off"
Tone of voice in the prompt → "formal, short, no humour" or "informal, clear, friendly".
"Privacy-sensitive info leaking"
Restrictions in context → "never mention salaries, birthdates, or customer name without consent".
"Domain knowledge missing"
KB-binding per context → IT context uses the IT KB, FM context uses the FM KB.
What’s in a context?
| Component | What it drives |
|---|---|
| Role instruction | "You are a Facility helpdesk agent at Acme. Answer questions briefly, politely, in correct English." |
| Knowledge sources | Which KB categories, which historical tickets, which documents. Limits hallucination. |
| Restrictions | "Never answer HR or salary questions. Refer them to HR." |
| Few-shot examples | 3-5 example conversations that demonstrate the desired style. |
| Output format | JSON, markdown or free text — depending on the use case. |
| Language strategy | Reply in the language of the question, or a fixed language? Detect via user profile. |
| Safety policy | What to do on sensitive topics, profanity, or "I'm thinking of harming someone"? |
How contexts are stacked
- 1Global tenant context — base instructions for all agents (name, language, tone, safety).
- 2Use-case context — specific instructions per task type (classify vs answer have different styles).
- 3Agent context — fine-tuning for a single agent (e.g. IT vs FM).
- 4Per-request metadata — language, location, user role of the concrete request.
Which decisions will you make?
One global context or several?
One base tenant context + use-case-specific additions is robust and easy to maintain.
Knowledge-source strategy
Whole KB as source or selected categories? Tighter = fewer hallucinations.
Ownership
Who writes and maintains contexts? Comms + service owner + AI-platform admin.
Versioning
Keep older versions — on bad output you can trace which context update caused it.