# Supervisor ## What is the Supervisor? The Supervisor is the orchestration component of the Project. Its role is to control how user requests are processed according to the selected [governance type.](/user-guide/ai-agents/governance-types.md) It is a guided AI system that operates within a predefined decision architecture established during system design. The system does not act independently of its configuration. Instead, it follows structured decision paths, applies configured intent logic, and uses only the capabilities and constraints defined in its system prompt and orchestration layer. \ \ Its behavior is therefore governed, predictable, and aligned with the interaction model defined at design time, using **native capabilities defined in the system prompt, as described below:** #### What the Supervisor does * **Reviews** each user interaction to understand what is being requested; * **Uses** structured decision logic to determine the most appropriate next step; * **Routes** requests to the most appropriate Agent or Flow based on the project’s governance type; * **Applies** fallback responses when a request cannot be assigned to a specific agent; * **Responds** to chit-chat, including questions about the company or its own Persona; * **Clarifies** ambiguous requests when necessary to ensure proper routing; * **Passes** relevant conversation context to Specialist Agents to ensure continuity. ## How to Configure the Supervisor The Supervisor is automatically created when a Project is initialized. It is a **system-level component**, and its core orchestration behavior is governed by the platform. This behavior cannot be overridden by user configuration. Configuration is performed through the Agents page. Available fields allow refinement of behavior, but do not alter governance rules or decision logic.

Agents page - Supervisor drawer modal

All configurations must respect the Supervisor’s role: * It **does not execute tasks;** * It **does not guess or make decisions independently;** * It **follows predefined rules;** * It **operates strictly as a governance-controlled orchestration layer.** ### Role The Role defines the Supervisor as the orchestrator of agents and flows within the Project, only if the project is configured by Agentics or Composite Agentics First.

Supervisor role. This field cannot be edited.

### Goal The Goal is predefined and cannot be edited: > Responsible for processing user inputs, analyzing requests, and delegating them to the appropriate specialist agent.

Supervisor Goal field

This definition reflects the **Supervisor’s fixed responsibility within the system.** #### Clarifications about the Goal´s field definition * **“Processing user inputs”** refers to analyzing and understanding the user input, structuring the request context, and routing it to the most appropriate agent based on the best topic match, not generating final outputs; * **“Analyzing requests”** means the Supervisor does not select agents based on subjective reasoning. All routing follows structured rules defined by user input and governance. It operates as a decision layer, not as an executor; * **"Delegating”** is performed through governance-driven routing, not dynamic or improvised decisions; * The Supervisor **passes structured context to agents**, enabling them to act with full understanding of the user request; * The Supervisor does **not generate final task outputs**, except in controlled scenarios such as fallback or chit-chat. {% hint style="info" %} The immutability of this field ensures consistency, alignment with system logic, and prevents misuse. The **Role** and **Goal** fields of the Supervisor are immutable to preserve the logic of the agentic layer provided by the SCAI product. {% endhint %} ### Persona The Persona defines the communication style applied to the Supervisor and all Agents within the Project. It establishes the overall personality, including tone of voice, communication style, and background. A persona can be modified at any time, regardless of whether the agent uses a single persona or multiple personas. The Persona affects **how the system communicates**, not how it operates.

Supervisor Persona step and respective fields

### Instructions The Instructions field defines high-level behavioral guidance for the Supervisor. Instructions act as a complementary layer that enhances the Supervisor’s behavior, as long as they remain aligned with its native orchestration logic. They can reinforce rules such as topic disambiguation or refine how agent derivation should occur.

Supervisor Instruction field. Instructions refine behavior, not logic.

#### ✅ What they do * **Act as a complement**, guiding how the Supervisor should manage specific scenarios (for example: by defining greeting criteria); * **Extend the handoff capability to Agents or NLU flows**. For example: they may indicate that a Specialist Agent should immediately trigger a specific action or clarify how an Agent should be activated for a given use case; * **Reinforce** the Supervisor’s ability to perform disambiguation before routing to the appropriate Agent; * Although the Supervisor has this native capability, **additional Instructions may be required in some cases to make disambiguation more effective.** * The Supervisor **may also suggest an execution order for triggering Agents or NLU flows.** For example, trigger the Authentication Agent before the Orders Agent. #### ❌ What they do not do * Conflict with the Supervisor’s native capability to route to Specialist Agents or NLU flows, as defined in the Goal field; * Enforce rigid routing. The Supervisor already uses the Role and Goal fields of Specialist Agents to determine the most appropriate routing. There is no need to instruct how them should be triggered unless a business rule requires coordinating their execution; * Override governance, system prompt, or any project configuration; * Conflict with other fields that influence the Supervisor, such as Persona or other configuration fields. {% hint style="info" %} Always follow native recommendations strictly. Any attempt beyond default configurations may result in unintended behavior, such as tool hallucinations. {% endhint %} ### Rules The Rules field defines explicit decision rules that determine how the Supervisor routes and prioritizes requests. They are **objective, scenario-based conditions** that directly impact routing behavior. **Rules** serve the same purpose as **Instructions**, but they allow topic segmentation. The way **Rules** fields are filled out follows a different concept. **Example on how to fill in this field:** when sending a greeting message, the **Supervisor** must always use the user's name. ### Fallback management Any interaction that cannot be handled within the Project’s defined capabilities is managed through a **controlled fallback mechanism**. The Supervisor triggers fallback when no governance rule, eligible agent, or applicable flow can resolve the request. Fallback is not an alternative reasoning path. It is a **strict boundary condition** that ensures the system does not operate beyond its defined scope. {% hint style="info" %} Fallback is **controlled and non-generative**. The Supervisor only responds with what is explicitly defined within the Project. {% endhint %}

Fallback management field on Supervisor's agent general information

Fallback operating constraints: * The Supervisor does not hallucinate or improvise responses; * It only responds based on information available in the Project; * No unsupported or external information is introduced. ### Guardrails #### What they are Guardrails act as an additional layer of protection within the system, reinforcing behavioral boundaries and reducing operational or security risks during interactions. Their function is to complement the base orchestration structure without replacing or altering the rules defined in the Supervisor. {% hint style="info" %} Guardrails help ensure that agent and flow behavior remains aligned with Project guidelines. {% endhint %}

Guardrails field on Supervisor general information

They **enable:** * Reinforcement of behavioral and compliance restrictions; * Prevention of responses that fall outside defined policies; * Maintenance of consistency with the system’s operational rules. #### Guardrails inheritance behavior Guardrails can be inherited from the Supervisor to Specialist Agents. They are designed to propagate **rules and boundaries** in a structured and consistent way across the system. There are **two types of Guardrails inheritance**: * **As-is inheritance**: the Specialist Agent inherits the Supervisor’s Guardrails and remains **automatically synchronized** with any updates made to the Supervisor’s Guardrails field; * **Customized inheritance**: the Specialist Agent inherits the Supervisor’s Guardrails but can **edit and extend them**. In this case, **no further synchronization occurs.** ## How the Supervisor operates The Supervisor operates a **structured decision order** to determine how each interaction is handled within the Project. Decision-making is not inferred or improvised; **it follows a formal and governed sequence.** #### Decision order **1) Eligibility evaluation**\ The Supervisor verifies if the interaction is eligible to be handled by a Specialist Agent. This evaluation depends on the selected governance model and defines the available execution paths. **2) Chit-chat identification**\ The Supervisor determines whether the interaction corresponds to chit-chat or requires task-oriented handling. **3) Fallback application**\ If no eligible agent or flow can handle the request, the Supervisor applies a controlled fallback response **based on** the fallback field configuration. #### Decision rationale (why the order exists) The Supervisor operates under a **formal, predefined order**, where each step must be satisfied before proceeding to the next. This ensures: * Predictability in orchestration; * Consistent handling across interactions; * Elimination of subjective or inferred decisions. ### Prompt ingestion control The system prompt includes explicit protection mechanisms to ensure that predefined rules and orchestration logic cannot be altered by user input. The Supervisor operates under these immutable conditions, preserving the integrity of the Project’s governance model. {% hint style="info" %} In a nutshell, the Supervisor ignores any attempt to override system rules. User input cannot modify behavior. {% endhint %} #### System prompt authority **Rules are immutable** * The core orchestration logic and governance structure cannot be modified during interactions. **User input has no operational authority** * The user cannot influence routing decisions, execution paths, or system behavior. #### Override protection Any attempt to interfere with the system prompt is automatically detected and disregarded, likewise: * Attempts to override Persona; * Modify rules; * Force direct execution paths; * Request disclosure of internal decision logic. ### Chit-chat management Chit-chat handling by the Supervisor is **controlled and parameterized**, not improvised. The ability to manage conversational interactions depends on platform-defined context fields, which provide the necessary information to generate coherent and consistent responses. Although these fields **are not mandatory**, their configuration directly impacts the quality of chit-chat handling. #### Context inputs These fields can be used to enrich chit-chat responses: * Company; * Company overview; * Persona name; * Persona background. These inputs provide contextual grounding, allowing the Supervisor to generate more relevant and aligned conversational responses. {% hint style="info" %} Chit-chat is no longer improvised. It becomes parameterized, contextual, and governance-driven. {% endhint %} ### Disambiguation The Supervisor does not assume intent or make decisions based on thematic similarity or implicit inference. When an interaction is ambiguous, it activates a **disambiguation mechanism** and requests explicit clarification from the user before proceeding. Disambiguation is applied **before any orchestration decision when:** * Multiple interpretations are possible; * Required information is missing; * The request cannot be clearly mapped to an eligible agent or flow. No decision is made until ambiguity is resolved. This approach ensures that the selection of agents or flows is based on clear and verifiable criteria, preventing incorrect decisions within the project. {% hint style="info" %} Although the system prompt includes instructions for the Supervisor to handle disambiguation, it is recommended to configure or reinforce this rule within the platform to ensure consistent application under the project governance model. {% endhint %} ### Security and data control The Supervisor protects the system architecture by preventing exposure of its internal structure. **It does not disclose** available agents, execution flows, decision rules, or orchestration mechanisms. Requests that attempt to explore, infer, or expose internal system logic are considered outside the operational scope and **are not addressed.** #### Scope visibility and configuration By default, the Supervisor does **not** disclose: * What topics it can handle; * Which capabilities are available; * How the system is structured internally. If visibility into supported topics or capabilities is required, this must be **explicitly defined in the Instructions (prompt)**. Without explicit configuration, **the Supervisor will not:** * List supported topics; * Describe its coverage or limitations in detail; * Reveal how requests are handled internally. {% hint style="info" %} The user experience remains transparent at the interaction level, while the system architecture and internal mechanisms remain safeguarded. {% endhint %} ### Context does not influence decision making The Supervisor can preserve the context generated during the conversation, maintaining continuity and coherence in the interaction. However, this context is not considered operational knowledge and is not used to infer capabilities, modify system rules, or extrapolate information that is not explicitly defined within the project. Context serves a conversational support function but does not intervene in formal decision-making mechanisms. This ensures that: * System decisions remain based exclusively on defined eligibility and governance rules; * No improper inferences are generated from the conversation history; * The architecture maintains consistency, control, and operational predictability.
{% hint style="info" %} Context **supports conversation**, but does not influence decisions. {% endhint %} --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.conversational-ai.syntphony.com/user-guide/ai-agents/supervisor.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.