Sub-agents

Sub-agents let Strata split a complex request into independent sub-tasks and run them in parallel as isolated-context workers, then fold their results back into one answer. They exist for the kind of request that is really several smaller requests at once — research five companies, compare four files, draft six sections — where doing the work one step at a time would be slow and where each piece doesn't need to see the others.

Note

Don't confuse this with a Linked agent — the ability for a scheduled agent to call another saved agent as a sub-task. That's a separate feature on the Agents side of the product. Sub-agents are a tool the AI reaches for mid-task; a Linked agent is one automation invoking another.

How it works

When a request naturally breaks into parallel pieces, the AI calls a tool that spawns several sub-agents at once — each one a fresh instance of the model with its own clean context, working on one piece of the task. They run concurrently rather than one after another, so five independent lookups take roughly as long as the slowest one instead of five times as long. When they finish, the parent conversation reads their results and writes the single answer you see.

Each sub-agent can read much of what your chat can — it can query the connected database, search and read Outlook, OneDrive, Jira, Confluence and the Knowledge Base where they're enabled for you, and search the web — and it inherits the same model governance and spend limits. It can also use the custom connectors (MCP) you've turned on, but only to look things up: a sub-agent is never given a connector tool the connector's server marks as making changes, and on a connector your administrator allows to make changes it gets only the tools the server marks read-only. It also gets the database knowledge Strata has saved about the connected database. A sub-agent also follows your response mode, so a Technical or Simple setting applies to its work too, and it inherits your custom instructions, your organization's industry and description, and whether extended thinking is on for the turn — so a file a sub-agent builds follows the same currency, date format and terminology as the answer around it. What it can change is much narrower; see Actions that need your approval.

When Strata reaches for sub-agents

The model decides to spawn sub-agents — it's a tool call, the same way it decides to run an analysis or query the database. There's no button for it. You can ask for it directly ("research these 5 companies in parallel," "summarize each of these files at the same time"), and the AI usually will, but the decision to actually call the tool is always the model's.

Typical triggers:

• Multi-entity research — gathering comparable information across several companies, products, or topics.
• Comparing several files or datasets — reading and summarizing multiple uploads side by side.
• Drafting several sections at once — independent parts of a long document that don't depend on each other.
• Large analyses with independent parts — a task that splits cleanly into pieces too large or too slow to do serially.

A short, single-fact question never spawns sub-agents — the overhead isn't worth it, and the model knows that.

Shaping each sub-agent

The parent doesn't just hand out tasks — it can tailor every sub-agent to its job. You never configure any of this; the AI does it per sub-agent, inside hard limits Strata enforces on the server.

• Model — the parent picks a model for each sub-agent from the current and preview chat models you're allowed to use (your organization's, role's and your own model access, or an API key's model list); legacy, retired and voice models are never offered. It picks a fast, inexpensive one for a narrow lookup and a stronger one for real reasoning; raising the reasoning effort (or turning on extended thinking) for a turn nudges it toward the stronger models. A sub-agent given no model, or one outside that list, runs on the conversation's own model — even a legacy one you picked — and if that model isn't allowed either, the sub-agent doesn't run. If a sub-agent's model isn't deployed in your organization's Azure AI Foundry, it retries once on the conversation's model (when you're allowed to use it) and the answer notes the switch; if there's nothing to fall back to, it fails and the chat rail shows model not deployed. A sub-agent that never ran adds nothing to recorded cost. A sub-agent can never run on a model your organization hasn't allowed.
• Effort — each sub-agent gets its own reasoning depth (low, medium, or high), so a quick lookup doesn't pay for deep reasoning it doesn't need.
• Roles and instructions — the parent can define a few named roles for a turn ("analyst," "fact-checker") and give each sub-agent extra instructions: a persona, a format, a checklist. These are always added to Strata's standing sub-agent rules, never a replacement for them.
• Token budget — every sub-agent has a token ceiling: 300,000 tokens unless the parent sets one, and never more than 400,000. The count includes the context the sub-agent re-reads on every step, so a multi-step task uses more than its written output suggests. The parent can set a lower ceiling for a narrow task, and nothing can raise one above your organization's limits.
• Files — when you attach files to your message, the parent can hand specific ones (up to five each) to the sub-agents that need them, instead of every sub-agent seeing everything. A file from an earlier turn or session of the conversation can be handed to a sub-agent too, which can open, edit, save or attach it (see Files from earlier in the conversation). Files a sub-agent creates (a spreadsheet, a PDF, a deck, an analysis output) appear in the chat like any other file, and each sub-agent works in its own analysis sandbox so parallel sub-agents never overwrite each other's files.
• Structured output — the parent can ask a sub-agent to answer as a JSON object with named fields, so results from several sub-agents line up and can be compared directly. If a sub-agent's reply doesn't match, it gets exactly one chance to correct it; if it still misses, the parent receives its prose answer, flagged as not matching.
• Shared briefing — the parent can write one short briefing (up to 4,000 characters) that every sub-agent in the round receives — the fiscal year, the naming conventions, the definitions everyone should use. It is read-only: a sub-agent can't change it or send anything back through it.

Isolated context

Each sub-agent starts with a blank slate. It cannot see your conversation history, your earlier messages, your saved memory, your work style, or what any other sub-agent in the same round is doing. The only things it has to work with are the task the parent wrote for it, the shared briefing, its own instructions, any files it was handed, and the standing context above — your custom instructions and your organization's industry and description — so the quality of a sub-agent's result depends on how completely the parent explained the job.

Your custom instructions reach a sub-agent as your words, with one qualification: it applies the parts about substance (terminology, units, currency, date format, what to include) and ignores the parts about how a chat reply should look, because its result is read by the main assistant rather than shown to you. A scheduled agent run and an @agent turn have their own instructions, and on those turns a sub-agent receives neither set — it follows the task it was given.

This isolation is what makes parallelism safe: sub-agents can't step on each other or drift based on shared state, because there is no shared state. It's also why a sub-agent occasionally comes back with a slightly different framing than you expected — it answered the task exactly as written, without the surrounding context you and the AI had built up.

The review pass

When a sub-agent returns a substantial result, Strata runs a quick, independent review of it: does the result actually answer the task it was given — on topic, complete, free of placeholder text or obvious fabrication? The verdict goes back to the parent alongside the result, so it can re-run a thin piece or tell you that part is incomplete rather than presenting it as finished.

The review is advisory only. It never rewrites, trims, or drops a sub-agent's output. It runs on a handful of the largest results per round, never on failed or stopped sub-agents, and a review that itself fails never fails the sub-agent. In the rail, a result the review found incomplete or off-task is marked may be incomplete or may be off-task.

Recursion

A sub-agent can itself spawn further sub-agents, breaking its own piece of the work down again. Strata caps how many levels deep this can go, and a sub-agent starts at most three of its own at a time, so a request can't spiral into an unbounded tree of workers. A sub-agent reads pages, runs queries and searches the web itself rather than handing each page to a worker of its own. In practice, most requests resolve in one level; recursion shows up on genuinely large, multi-layered tasks. Nested sub-agents appear in the rail directly under the sub-agent that started them, joined to it by tree lines.

Actions that need your approval

In the Strata web app, a sub-agent can propose an action that changes something outside the chat. Ask for it plainly (for example, "have a sub-agent email the summary to Dana") and the sub-agent proposes the email itself rather than drafting it and waiting; the approval card is the review. When the round is over, Strata tells you exactly how each proposed action ended: approved, approved automatically by your setting, denied, not answered in time, not allowed, or approved but then failed (see When an approved action fails). How that proposal is approved depends on the chat's Approvals setting (below). When it needs you, a card appears directly under that sub-agent in the rail showing exactly what it is asking to do — the email with its recipients, attachments and body, the forwarded message, the Jira issue, the page, the file and where it will be saved, the share — with Approve and Deny buttons. The card carries the logo of the service involved — Outlook, Jira, Confluence, OneDrive — so you can tell at a glance where the action would land.

The actions a sub-agent can ask for are the ones that always show an approval card:

• Outlook — send an email, schedule a send, reply or forward.
• Jira — create an issue, comment, change a status, edit fields (only where your organization allows Jira writes).
• Confluence — create a page or comment (only where your organization allows Confluence writes).
• OneDrive — save a file from the conversation to your OneDrive, create a sharing link, invite people, or revoke access.

Everything else that changes data stays unavailable to sub-agents: they never run SQL that writes, never move, rename, or delete OneDrive files, never save an email attachment or a converted copy to OneDrive, never create drafts, calendar events, mail rules, To Do tasks, or email templates, and never ask you to connect an extension. Those remain with the main assistant.

The Approvals setting

At the top of the Sub-agents card in the workspace panel, Approvals sets how this chat's sub-agents get approval. That card is the only place it is set — the composer row beside the model carries the model and the send button, and nothing else. Click it to choose one of five rungs, ordered from most cautious to least:

The setting is saved per chat and applies to every sub-agent in that chat, on every turn. Changing it takes effect at the sub-agent's very next action, even in the middle of a round. A new chat starts on Ask every time unless your administrator has set a different starting rung for your organization.

What Strata always asks about, whatever the setting. Some actions wait for you even under Skip approvals:

• an email to anyone outside your organization (or outside the domains your admin allows), an email to more than 25 people, or a forward that would send a thread to a partner domain;
• an email to a group or distribution list, or to any address Strata cannot confirm in your directory as a colleague's mailbox;
• any email or share when you are signed in with a personal address (for example gmail.com), because a shared mail provider says nothing about who is in your organization;
• a reply or reply-all, judged on the people the original message actually reaches (its Reply-To or sender, and for reply-all everyone on it) — never on a recipient list the AI wrote;
• an email your organization's egress rules flag for confirmation;
• a sharing link anyone can open, sharing with someone outside your organization, or any share your organization's OneDrive rules ask to confirm;
• a save to OneDrive when your organization's OneDrive rules ask to confirm saves, or when Strata cannot read those rules;
• anything Strata cannot classify with certainty.

Limits on automatic approvals. Even when an action qualifies, Strata stops approving on its own and puts the next one in front of you when:

• the same action (same recipients and content, same issue and change) comes up a second time in a turn;
• a turn has already had 10 automatic approvals under Ask only when risky, or 30 under Skip approvals;
• your organization has data-policy detectors or a policy endpoint configured and they flag the full content (the whole email, issue or page, not just what the approval card shows), cannot be reached, or are only observing (shadow or audit mode) — and, for an organization that inspects content, whenever the action carries attachments Strata has not scanned;
• you press Stop while the check is running.

Every automatic approval is still shown under the sub-agent that asked, as Approved automatically with the reason (for example "internal recipients"), and recorded in your organization's audit log without the content.

Your organization can limit which settings you can choose; a setting you can't pick is marked Limited by your organization. Your administrator sets three things here — the highest rung you may pick, the rung a new chat opens on, and what a scheduled agent does when there is nobody to ask — under Organization settings → Member defaults, in the Rules for everyone, effective now group: Most freedom a member may choose and Where a new chat starts sit under the Sub-agents switch, and Approvals for scheduled agents is under Advanced at the foot of that group.

Keeping approvals honest

• You're told even when you've looked away. The rail opens itself on any screen size, a phone included, expands the Sub-agents card and scrolls to the card; if the full Outputs view was open, it closes so the card is in view. While an approval waits, the rail stays beside the chat even when you open an artifact or the sources panel (that panel narrows instead), and if you close the rail, a red dot stays on the Workspace toggle until you answer. The section header reads 1 needs approval, and while the tab is in the background its title shows a count. If you'd like a system notification too, allow browser notifications with Notify me when a decision is waiting at the bottom of the Approvals menu, or Notify me when away on a card — Strata never asks for that permission on its own. Once allowed, you are also notified about approvals the main assistant needs and about approvals waiting in another chat.
• An unanswered request expires. After ten minutes it closes as Expired — the action was not taken, and the sub-agent carries on without it. Strata tells the assistant that nobody answered, not that you declined.
• Stop means stop. Clicking Stop closes every open card at once as Stopped — the action was not taken, and an approval can never be answered after Stop, even from another tab.
• Declined means declined. A sub-agent that's turned down doesn't retry or look for a way around it; it reports that the action was declined.

When an approved action fails

An approval only says the action may go ahead. If the action then fails, the line under the sub-agent no longer reads just Approved; it says what happened, followed by the reason:

• Approved, not done (or Approved automatically, not done): the service refused the action, so nothing was changed. The reason says why, for example the Atlassian connection only allows reading. Reconnect Atlassian in Settings > Extensions, permission was denied, what it acted on was not found or the request limit was reached.
• Approved, not confirmed (or Approved automatically, not confirmed): the action failed in a way that doesn't show whether it went through, such as a timeout or a service error, so it may have been done. The reason tells you to check before retrying. Look in Jira, Confluence, Outlook or OneDrive before you ask for it again, so it isn't done twice.

A Jira edit that updated the issue's fields and then failed to change the assignee reads Approved, not confirmed with only part of it went through, and Strata's answer names the fields that changed. An automatic approval that fails keeps its service logo and its Details. Strata's answer reports the same outcome as the rail.

Key

Approvals only exist where someone can see the card. In the Outlook add-in, the mobile app, the API, and scheduled agent runs, sub-agents stay strictly read-only — they cannot propose actions at all. Sub-agents aren't available in Teams. And a sub-agent can never use a tool the conversation itself isn't allowed: if an extension or the Knowledge Base is turned off for you, it's off for your sub-agents too.

The workspace rail

Sub-agents live in the first card of the workspace panel, the rail that opens along the right edge of a chat from the Workspace toggle in its top-right corner. On a wide screen the rail opens on its own the first time a turn spawns sub-agents, unless an open artifact or sources panel leaves no room beside the chat; then a red dot appears on the Workspace toggle instead. On a phone-sized screen the rail covers the chat, so sub-agents starting never opens it there: tap the toggle to see it, and close it with the X at its top or the Esc key. An approval is the exception: it opens the rail on a phone too (see Keeping approvals honest). The Sub-agents card shows a live row for each sub-agent in the latest round:

• Name and status — running, done, failed, or stopped.
• Model, by name, and its effort when it isn't the default and the model uses an effort setting.
• Live token count and time taken.
• What it's doing right now — the step it's on while it runs.
• Markers such as resumed, may be incomplete, or model busy when they apply.
• N queries, when the sub-agent queried your database: expand it to see each query and how many rows it returned.

Approval cards appear under the row that raised them. When any sub-agents in the round stopped short, a single Resume button appears under the list — Resume all (N) when there's more than one (see Resuming sub-agents). Collapse the card's header to tuck it away while a round keeps running, or close the rail to give the chat back its full width. While the card is collapsed or the rail is closed, a small red dot on the card's name or on the Workspace toggle tells you a sub-agent finished or failed, or an approval is waiting (see The red dot). The card clears only when your next turn spawns a new round — leaving the chat and coming back shows the last round again.

The permanent action step

Every round of sub-agents also leaves a normal action step in the chat — something like Ran 4 sub-agents — that stays in that conversation's history for good. Click anywhere on it to expand a compact list of that round's sub-agents: each one's name, the model it ran on, and its status (Done, Failed, or Stopped). It's a status record, not a transcript — the sub-agents' output was already folded into the answer above, so the step doesn't repeat it.

Stopping a round

Click Stop while sub-agents are running the same way you'd stop any other response. The response ends there — the parent doesn't go on to write an answer from partial results. Nothing the sub-agents did is thrown away, though: finished sub-agents keep their results, which the AI can use on a later turn, and sub-agents that were cut off are marked stopped and can be resumed.

Resuming sub-agents

A sub-agent that stopped, failed (for example, the model was busy), or was interrupted (the service restarted mid-run) can be picked up again instead of starting from scratch. Click Resume in the rail — one click continues every stopped sub-agent in that round together — or just ask: "finish the sub-agents that stopped."

Resume sends a new message for you, so the chat carries on too: the stopped sub-agents continue, and once they're done the assistant finishes the answer that was interrupted, using everything they found. Anything you'd typed in the prompt box stays there.

A resumed sub-agent continues from what it had already written and the list of steps it had already finished, and returns a complete result. Some limits apply, all enforced on the server:

• Once. Each sub-agent can be resumed a single time. If the resume also stops short, spawn a new sub-agent with a narrower task.
• Recent and saved. Only within 7 days, and only in a conversation that's saved. When history saving is off for a turn, its sub-agents are never resumable — there's nothing saved to continue from.
• Same database. If the sub-agent was querying a different database connection than the one active now, Strata refuses the resume and says so, rather than quietly continuing against the wrong data. Switch back to that connection to resume it.
• Progress, not results. The results of lookups a sub-agent had already run aren't kept, so it may run some again if it needs them. It's told never to repeat an action that changed something — and any action it proposes still needs your approval.
• No doubles. Clicking Resume twice, or in two tabs, starts only one continuation per sub-agent.

Using earlier results

Sub-agents' results aren't lost when the turn ends. On a later turn in the same conversation, the AI can look back at what earlier sub-agents found — "use the research the analysts did," "what did the fact-checker flag?" — instead of spawning new ones to redo the work. It can pull a list of recent sub-agent results, one sub-agent's full result, or everything from one round.

These are snapshots of what each sub-agent found when it ran, so the AI names which sub-agent a fact came from and roughly when, and re-checks anything that changes (live data, an inbox, prices) before presenting it as current. Results older than 7 days, from turns that weren't saved, or from other conversations aren't available this way — for other conversations, see past-chat search in Chat.

Sub-agents in scheduled agents

A scheduled agent can use sub-agents too, when its Sub-agents capability is switched on in the agent form's Tools (see Agent permissions). A run with nobody watching gets tighter bounds than chat:

• Up to 5 sub-agents per step and 10 per run, and no nesting — a run's sub-agents can't start their own.
• The agent's own tools only. Each sub-agent is limited to the tools that agent was granted and that governance allows — an agent granted only SQL can't reach Outlook through a sub-agent.
• Always read-only. There's no one to approve anything, so a run's sub-agents can't propose actions at all.
• The run's budget is shared. An admin's per-run token and cost ceilings are split across the run's sub-agents, not handed to each one in full.

Sub-agents inside a run don't appear in a chat rail. In the run's details, the Ran N sub-agents step lists each sub-agent with its model, status, tokens and time, and the steps it finished (up to 20 each). Like the rest of the run's steps, this isn't kept when the agent owner's settings say not to save AI or extension output. Inside a run, sub-agents follow the agent's own tool grants, which don't include connectors.

Retention and privacy

Sub-agents follow the same retention rules as the conversation:

• When Save AI responses to history is off, or you're in incognito, a sub-agent's task, output, step list, and review notes are not saved — only non-content facts such as its status and token counts. This applies the same way to turns sent through the API.
• If a turn's answer is blanked (for example, Keep my extension-data chats in history is off and the turn used an extension) or withheld by your organization's response policy, the saved sub-agent records for that turn are scrubbed too, so they can't be read back or resumed later, and the rail clears.
• The working copies kept only for resuming are cleared once a sub-agent can no longer be resumed. Deleting a conversation also ends read-back and resume for its sub-agents.
• Strata's operational telemetry for sub-agents records counts and categories only — how many ran, how they ended, tokens, time, which models — never names, tasks, outputs, error messages, or user identifiers.

Usage and billing (admins)

Sub-agent tokens are counted at the model each sub-agent actually ran on, not the model of the conversation that started it. On the Usage page they appear as their own rows labelled with the model and (Sub-agents), and they count toward that model's allowance and your organization's spend ceiling like any other usage. For scheduled agents, the run's cost is priced the same way. Files a sub-agent creates count as deliverables for the conversation that started it.

Who can use sub-agents (admins)

Sub-agents are governed by the same three-tier cascade as Strata's other capabilities — organization → role → individual member — so you can turn the feature on broadly and still carve out exceptions.

• Organization — the base setting at Organization → Member defaults → Rules for everyone, effective now → Sub-agents. It's on by default. Turning it off removes the tool from chat for everyone.
• Role — each role can set sub-agents to Allow, Deny, or Inherit (follow the org default) at Organization → Roles → (a role) → Capabilities. A role setting overrides the org default for members of that role.
• Individual member — the same Allow / Deny / Inherit control per person at Organization → Users → (a user) → Access → Capabilities → Sub-agents. A user-level setting is the most specific and wins over both role and org.

When the resolved setting is off, the tool is removed from that person's chat entirely — the AI solves multi-part requests serially instead. The cascade fails closed: if the setting can't be read for any reason, sub-agents stay off rather than defaulting on. The same setting applies to the scheduled agents a person owns, and admins can additionally remove sub-agents from one person's agents with the Sub-agents checkbox under Allowed agent tools (see Per-user agent governance).

Key

Spawning sub-agents never widens what the AI can reach. Every sub-agent runs under the same model governance, tool permissions, and spend limits as the conversation that spawned it, and any action it proposes waits for you.

What can go wrong

• The sub-agents tool never seems to fire. Check with an admin that Sub-agents is still enabled for you — it can be turned off at the organization, role, or individual level. If it's off, the AI falls back to doing the work step by step.
• A sub-agent's result is off-topic or missing context you assumed it had. It never saw the conversation — only the task the parent wrote for it. Ask the AI to re-run that piece with more explicit detail.
• A sub-agent shows "model busy." Strata already retried the model several times before giving up. Click Resume, or ask Strata to retry that piece, once capacity frees up.
• An approval card says "Expired — the action was not taken." Nobody answered within ten minutes. Ask Strata to try that action again if you still want it.
• A card never appeared and the action was refused. The chat is on Do not ask, refuse instead. That rung answers nothing and refuses anything that would have asked, so the run ends with a reason rather than waiting. Move to a rung that asks, and try again.
• An approved action reads "Approved, not done". You approved it, but the service refused it and nothing was changed. The reason on the line says what to fix; for a Jira or Confluence action it is often a connection that only allows reading, which reconnecting Atlassian fixes. If it reads Approved, not confirmed, check whether it went through before asking again.
• An action went through without a card. The chat is on a rung below Ask every time — Ask only when risky, Ask before anything leaves, or Skip approvals. The row under the sub-agent says Approved automatically and why. Move the setting back to Ask every time at the top of the Sub-agents card.
• "Not allowed for sub-agents." Some actions are never available to a sub-agent in any setting (for example a database schema change). Ask the main assistant instead.
• Resume says a sub-agent can't be resumed. It already finished, was already resumed once, is older than 7 days, ran on a turn that wasn't saved, or was using a different database connection. Ask Strata to run that piece again as a new sub-agent.
• You don't get a browser notification. Notifications only fire while the tab is in the background and after you've allowed them from an approval card. Check that your browser and operating system allow notifications for Strata.
• A very large request seems to stop nesting further. Recursion is capped so it can't run away. Ask Strata to split the request into a couple of separate turns.

Examples you can try

• "Research these five companies in parallel and summarize each one's latest earnings in the same format."
• "Compare these four uploaded CSVs at the same time and tell me which one has the cleanest data."
• "Have two analysts draft the summary and a fact-checker review both drafts."
• "Research the three vendors in parallel, then email the comparison to my manager" — the email waits for your approval.
• "Use what the sub-agents found last time and update the table with this quarter's numbers."

Related

• Chat overview — the action-step trail sub-agents appear in
• Artifacts — other panel-based surfaces in chat
• Analysis — the sandbox a sub-agent can also reach for
• Agent permissions — the Sub-agents capability for scheduled agents
• Agents overview — scheduled agents and Linked agents, a different feature