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.
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.
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.
Goal
The Goal is predefined and cannot be edited:
Responsible for processing user inputs, analyzing requests, and delegating them to the appropriate specialist agent.
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.
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.
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.
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.
✅ 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.
Always follow native recommendations strictly. Any attempt beyond default configurations may result in unintended behavior, such as tool hallucinations.
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.
Fallback is controlled and non-generative. The Supervisor only responds with what is explicitly defined within the Project.
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.
Guardrails help ensure that agent and flow behavior remains aligned with Project guidelines.
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.
In a nutshell, the Supervisor ignores any attempt to override system rules. User input cannot modify behavior.
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.
Chit-chat is no longer improvised. It becomes parameterized, contextual, and governance-driven.
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.
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.
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.
The user experience remains transparent at the interaction level, while the system architecture and internal mechanisms remain safeguarded.
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.
Context supports conversation, but does not influence decisions.
Last updated
Was this helpful?