Sub Agent

9 min read

The Sub-Agent functionality tool can be activated within the following spaces:

Unique AI Space

What It Does

The Sub-Agent functionality allows one assistant space to delegate a focused task to another pre-configured assistant space.

Instead of giving one space every capability directly, you can create specialized spaces for narrow workflows and expose them to an orchestrator space as callable sub-agents. When the orchestrator decides to use one, it sends a message to the linked sub-agent, waits for the result, and then continues answering with the returned content.

This makes sub-agents a reusable delegation layer inside the platform: one space can specialize in a task, and other spaces can call it when that specialization is needed.

Key Advantages

Specialized delegation -- Break complex behavior into smaller, purpose-built assistant spaces.
Reusable expert spaces -- A single sub-agent can be linked to multiple orchestrator spaces instead of duplicating configuration.
Per-link customization -- The same sub-agent can appear differently depending on where it is used, with custom display name, prompt guidance, and runtime settings.
Conversation continuity -- Sub-agents can reuse their own chat state across calls when ongoing context is helpful.
Isolated execution when needed -- Chat reuse can be disabled so each call starts fresh.
Reference propagation -- If the sub-agent returns references, they can be forwarded to the parent response in a structured format.
Controlled execution -- Polling interval, timeout behavior, stop condition, and forced tool usage are configurable.
Flexible output handling -- Responses can be returned as plain text or interpreted as content chunks for downstream processing.

How It Works

A space is marked as a sub-agent in its advanced settings.
Another space links that sub-agent from the Sub-agents section.
The linked sub-agent is exposed to the orchestrator as a callable tool.
When the orchestrator calls it, a message is sent to the configured assistant space.
The platform waits until the sub-agent finishes or the configured timeout is reached.
The result is returned to the parent space, optionally with references, debug metadata, and system reminders.

Setup Layers

Sub-agent setup happens in two layers:

Layer	Where It Is Configured	What You Do There
Define the reusable sub-agent	In the space that should act as a sub-agent	Enable the `Sub-Agent` advanced setting, give the tool a clear identity, and define its runtime behavior.
Attach it to an orchestrator	In the orchestrator space under `Sub-agents`	Add the reusable sub-agent to the orchestrator and, if needed, override its settings for that specific orchestrator.

This distinction is important:

The sub-agent space defines the reusable default behavior.
The orchestrator can then append that sub-agent and adjust the configuration again for its own use case.
In practice, this means one reusable sub-agent can be linked into multiple orchestrators, each with slightly different naming or behavior if needed.

Setup Walkthrough

1. Configure the sub-agent space itself

In the advanced settings of the space that should be reusable, enable Sub-Agent. Once enabled, the full sub-agent configuration becomes available.

The most important fields at this level are:

Display Name -- Must not be empty. This is the tool name shown to the orchestrator and the name that will also appear in the chat UI when the sub-agent is used.
Icon -- Same behavior as any other tool. Choose the icon that best represents the delegated capability.
Selection Policy -- Same policy model as other tools. It controls how the tool is made available for use.
Tool Description -- This is one of the most important fields. It should clearly explain when the orchestrator should decide to call this sub-agent.

For example, if you build an investment-research sub-agent, the description should explain which kinds of prompts should trigger it, such as requests for investment proposals, structured market analysis, or investment-specific reasoning.

The advanced Configuration section is collapsed by default and contains the lower-level execution settings such as chat reuse, timeout handling, and response formatting.

2. Add the sub-agent to an orchestrator

In the orchestrator space, and append an existing reusable sub-agent to the Sub-agents in the Sources & Tools section. After adding it, the orchestrator can adjust the configuration again.

This second layer is useful when:

the same reusable sub-agent should appear with a different display name in different orchestrators
the tool description should be tuned for one orchestrator's prompting behavior
timeout, polling, or other advanced settings should differ between orchestrators

In other words, the linked sub-agent inherits the reusable setup, but the orchestrator can still tailor it locally.

Custom Spaces as Sub-Agents

The setup described above is not limited to standard Unique AI sub-agents. You can also use custom spaces as sub-agents. This is especially relevant for custom spaces with custom modules that should be appended to a Unique AI space as a sub-agent.

To make a custom space available as a sub-agent:

Open the custom space.
Go to the advanced settings.
Add “isSubAgent"=true.

Once this is enabled, the custom space becomes eligible to appear in the sub-agent selection list and can then be appended at the orchestrator level just like any other sub-agent.

This means:

custom spaces with custom modules can participate in orchestrated Unique AI flows
the custom space must first be explicitly marked as a sub-agent
after that, it becomes available for linking from the orchestrator's Sub-agents section

Configuration Overview

Core Identity Fields

These are the most important visible fields when setting up a sub-agent:

Field	Default	Why It Matters
Display Name	`Sub Agent Tool`	The visible tool name. This should never be left empty because it is what the orchestrator sees and what the user later sees in the chat UI.
Icon	`Icon Chat Plus`	The icon used to represent the sub-agent in the UI.
Selection Policy	`ByUser`	Controls how the tool is made available, using the same policy model as other tools.
Tool Description	Empty	Describes when the orchestrator should call this sub-agent. This should be written carefully, because it strongly influences tool selection behavior.

Advanced Configuration

The following table covers the visible parameters from the expanded Configuration section.

Parameter	Default	Description
Reuse Chat	`true`	Reuses the existing sub-agent chat instead of creating a new one for each call. Good for delegated workflows that benefit from continuity.
Use Sub Agent References	`true`	Preserves references returned by the sub-agent so they can be used in the main agent's response.
Forced Tools	`[]`	Restricts the sub-agent to a specific list of tool names. Useful when the sub-agent should behave like a narrow wrapper around one capability.
Tool Description For System Prompt	Empty	Extra description injected into the system prompt to help the orchestrator understand the sub-agent more precisely.
Tool Format Information For System Prompt	Empty	Additional formatting instructions placed into the system prompt to shape how the response should be produced.
Parameter Description Sub Agent Message	`This is the message that will be sent to the sub-agent.`	Describes the delegated input field that the orchestrator fills when calling the sub-agent.
Poll Interval	`1`	Number of seconds between polling attempts while waiting for the sub-agent response.
Max Wait	`120`	Maximum number of seconds to wait before the call times out.
Stop Condition	`completedAt`	Determines which backend completion signal ends polling for the sub-agent response.
Tool Input Json Schema	Empty	Optional custom JSON schema used as the tool input contract instead of the default single `user_message` field.
Returns Content Chunks	`false`	If enabled, the sub-agent response is interpreted as a list of content chunks instead of plain text.
System Reminders Config	`[]`	Optional reminder rules added to the tool response, for example depending on whether references are present or whether specific text patterns appear.

Unique AI Orchestrator Sub-Agents Config

In addition to the per-sub-agent tool configuration, UniqueAI orchestrators also expose a higher-level Sub Agents Config section in their advanced settings of the loop agent.

This section controls how the orchestrator handles sub-agent results globally after a sub-agent has already been called. The screenshot you shared belongs to this orchestrator-level configuration, not to the individual sub-agent tool settings.

Orchestrator-Level Parameters

Parameter	Default	Description
Evaluation Config	`Active`	Enables evaluation of sub-agent responses at the orchestrator level. This uses the sub-agent evaluation service configuration and determines whether returned sub-agent outputs should be reviewed or assessed before being incorporated into the final response.
Referencing Config	`Active`	Enables orchestrator-level referencing behavior for sub-agent results. When active, the orchestrator adds referencing instructions so references returned by sub-agents can be preserved and used correctly in the final answer.
Sleep Time Before Update	`0.5`	Time in seconds the orchestrator waits before updating the main agent message to display sub-agent responses. This is currently used as a temporary rendering safeguard.

When These Settings Matter

These settings are especially relevant when:

the orchestrator uses multiple sub-agents and you want consistent handling of their outputs
you rely on references produced by sub-agents and want them forwarded cleanly into the final answer
you want orchestrator-level evaluation or review behavior on sub-agent responses

In short, the per-sub-agent settings define how a specific sub-agent is called, while the Sub Agents Config section defines how the Unique AI orchestrator processes sub-agent outputs after they return.

Important Runtime Behaviors

Chat Reuse

By default, sub-agents reuse their chat state. This is useful when the delegated workflow benefits from memory across multiple calls. If chat reuse is enabled, the platform serializes concurrent runs of the same sub-agent to avoid race conditions in the reused chat. If you need fully independent executions, disable chat reuse.

Timeouts and Polling

Sub-agent execution is polled until the configured stop condition is met. If the sub-agent does not finish before max_wait, the call fails with a timeout. This makes timeout behavior explicit and configurable, which is especially important for longer-running delegated workflows.

References

If the sub-agent returns references and reference forwarding is enabled, those references can be preserved for the parent assistant. The platform rewrites them into a sub-agent-specific inline format so the parent response can distinguish where they came from. If the sub-agent does not return references, the parent can still receive the text result, but no citations from that sub-agent will be available.

Forced Tools

You can restrict a sub-agent to one or more specific tools. This is useful when the sub-agent should act as a narrow execution wrapper, for example around search or internal retrieval, instead of having full freedom over all of its configured tools.

Important Considerations

Access Control

Users must have access to the sub-agent space as well as to the orchestrator.

If the orchestrator tries to call a sub-agent that the current user cannot access, the call fails and an error is returned instead of a successful delegated response.

Because of this, access rights should always be considered when linking sub-agents into an orchestrator:

when you add a sub-agent to an orchestrator, make sure the intended users can also access that sub-agent

Elicitation in Web Search Sub-Agents

If a sub-agent uses Web Search and triggers an elicitation call, that elicitation is forwarded to the orchestrator.

This means the approval step still happens at the orchestrator level, not inside a separate sub-agent UI context. From the user's perspective, the orchestrator remains the place where approval is requested and confirmed.

Configuring the Sub Agents Assessment Handling

Unique assistant’s can have some assessments that are attached to the assistant message, such as hallucination checks, compliance checks etc. E.g:

Note that there can be multiple assessments for an assistant answer.
In the case of sub-agents, it is possible to collect all sub agent’s assessment and do the following:

If there is only one sub-agent assessment, it is displayed as it.
Otherwise, we perform an LLM call to summarize the main points from all the valid assessments and display it as follows.

Some notes:

The severity of the assessment (green, yellow, red) corresponds to worst assessments received.
Any invalid assessment (due to an error for e.g) will be ignored.

Limitation: MCP Server Approvals

MCP server approval requests triggered inside a sub-agent are currently not forwarded to the orchestrator.

This means that if a sub-agent tries to use an MCP server that still requires approval, the approval prompt does not surface correctly at the orchestrator level. In practice, the orchestrator call or the sub-agent call will fail instead of continuing with an approval flow.

One example is an MCP server such as an Outlook server:

if the sub-agent triggers a tool call against that server
and that MCP server has not yet been approved
the request is not forwarded to the orchestrator for approval
so the sub-agent execution fails

This is a current limitation of the setup.

Workaround for MCP Server Approvals

To work around this limitation, first create a separate direct chat where the MCP server can be approved explicitly.

After that approval has already happened, the same MCP server can then be used successfully when triggered later from within the sub-agent.