Subagents

Subagents are specialized AI agents you configure once and reuse across your workspace. Each subagent has its own name, system prompt, model, and curated set of tools — so instead of re-explaining what you want every time you open a chat, you give the work to an agent that already knows how to do it.

A subagent is the difference between "I need to summarize yesterday's support tickets" typed into a fresh chat every morning and a Support Digest agent that already knows which systems to query, what format to use, who to notify, and runs on its own at 8am.

Subagents are also where the tools you build in Assist earn their keep. A subagent's tool whitelist is the concrete set of things it can do — read from your WMS, post to Slack, create a ticket, update a CRM record. The agent's prompt decides what to do; its tools decide what it's able to do. The two together are the unit of work.

Who can create subagents

  • Any workspace member can create a subagent. The creator becomes the owner.
  • Workspace admins can create, edit, and delete any subagent in the workspace.

What a subagent can do

  • Hold a focused system prompt that defines its job, tone, and guardrails.
  • Use a specific model you choose, or inherit the workspace default.
  • Call a curated set of tools — either every tool in the workspace, or an explicit whitelist.
  • Be scoped to specific projects so it only touches data it should touch.
  • Run on a schedule (daily, weekly, monthly, or once) in a timezone you pick.
  • Receive messages directly from a Slack, Telegram, or Discord channel.
  • Be delegated to from the main chat or from another subagent.
  • Optionally get its own private filesystem for notes, drafts, and reports.
  • Optionally be linked to a sandcastle so it can read and write that app's state.

What a subagent cannot do

  • Act outside its workspace. Subagents do not see data, tools, or chats from other workspaces.
  • Use tools that are not in its whitelist (when a whitelist is configured).
  • Delegate infinitely. There is a configurable cap on how deep delegation chains can go (default one level).
  • Delete itself if it is linked to a sandcastle. The sandcastle link must be removed first.
  • Run without a model. Either a specific model must be selected or a workspace default must be configured.
  • Be invoked by external MCP clients. Subagents are consumed inside Assist today, not exposed outbound.

How subagents work

When you create a subagent, you are saving a configuration: a system prompt, a model, a tool whitelist, a set of projects it can access, and any optional extras like a schedule, a sandcastle link, or a filesystem. That configuration is stored at the workspace level and can be shared with teammates.

Subagents run in three ways:

  • On demand, when you open a chat with the agent directly or when the main chat delegates a task to it.
  • On a schedule, when a trigger fires at its configured time and runs a saved prompt against the agent.
  • On a message, when Assist receives a message in a Slack, Telegram, or Discord channel that has been mapped to the agent.

In all three cases, the subagent executes with the same system prompt and tool whitelist you configured. That is the point: the behavior is consistent whether a human is chatting with it, a cron schedule is waking it up, or a teammate posts in a channel.

Subagents and the rest of Assist

  • Custom tools — Any tool you build in Assist can be added to a subagent's whitelist. This is how you give an agent access to your WMS, ERP, DSP, or any internal API. Tools are built once at /tools, versioned, tested, and published — then any subagent in the workspace can draw from the same shared toolbox. Credentials and network permissions live on the tool, not on the agent, so adding a tool to a subagent automatically gives that agent the right (and only the right) access. See building a shared toolbox for your organization for the full pattern.
  • Scheduled triggers — Subagents are first-class targets for scheduled triggers. You set the schedule and the prompt; the trigger does the rest.
  • Sandcastles — Link a subagent to a sandcastle and it gets tools for reading and writing that app's state collections. Great for an app that needs a dedicated operator.
  • Agent filesystem — Turn on the filesystem for a subagent and it gets a private text-file store it can read and write across chats.
  • Channel mappings — Wire a subagent to a Slack, Telegram, or Discord channel so messages in that channel route automatically to the agent.

Related guides