Skip to main content

Documentation Index

Fetch the complete documentation index at: https://relevanceai.com/docs/llms.txt

Use this file to discover all available pages before exploring further.

Subagents let you connect any Agent you’ve built in the Relevance AI builder to Super GTM. Once connected, Super GTM sees the subagent in every conversation and can invoke it when a user request matches what the Agent does. This is the bridge between the Agents your team has already built and the Super GTM chat experience — the work of designing, prompting, and configuring an Agent in the builder is reused directly inside Super GTM.
Subagents replace the deprecated agents-as-skills approach. Previously, Super GTM would become a connected Agent by reading its instructions and running its tools inline. Subagents instead run each connected Agent in its own conversation with its own context.

​
How it works

Super GTM acts as an orchestrator. Connected subagents appear in its catalog at the start of every conversation, and Super GTM decides when to delegate to one based on the user’s request and the subagent’s description. Each subagent runs as a full agent in its own conversation — separate context, its own reasoning, its own tools. The only context shared with Super GTM is the message Super GTM sends in. When the subagent responds, its output is returned to Super GTM, which then continues with the user. If Super GTM needs more from the same subagent later in the session, it sends a follow-up message into that same subagent conversation rather than starting fresh.
For each connected subagent, Super GTM sees:
  • The Agent’s name
  • The Agent’s description
These two fields drive routing — Super GTM matches the user’s request against the description to decide whether to invoke the subagent. A clear, specific description that explains what the Agent does and when to use it is the single biggest factor in getting reliable routing.

​
Connecting an Agent as a subagent

1

Open the Agent in the builder

Go to app.relevanceai.com and open the Agent you want to connect.
2

Make sure the Agent has a name and description

The Agent must have both before it can be used as a subagent. The description is what Super GTM reads when deciding whether to route to this Agent — explain clearly what the Agent does and when to use it.
3

Open advanced settings

In the agent edit view, navigate to the Advanced section.
4

Toggle on Can be used by Super GTM

Enable the Can be used by Super GTM setting. The Agent is now available as a subagent in every Super GTM conversation in the project.
The Agent’s description is the most important field for subagent performance. Super GTM reads it on every conversation to decide when to route a request to this Agent. If the description is vague, missing, or written for end users rather than for the orchestrator, routing will be unreliable.

​
Writing a description that routes well

The description should answer two questions clearly:
  1. What does the Agent do? Be specific about the task — “drafts personalized cold outreach emails based on a prospect’s LinkedIn profile” beats “writes emails.”
  2. When should Super GTM use it? Describe the kind of request that should trigger it — “use when the user wants to write a first-touch email to a new prospect.”
Agent name: Cold Email WriterDescription: Drafts personalized cold outreach emails for new prospects. Takes a LinkedIn URL or company name as input, researches the prospect, and produces a short first-touch email matching our team’s voice and outreach playbook. Use when the user asks for an outreach email, an intro email, or wants to start a sequence with a new prospect. Do not use for follow-ups on existing conversations — those should go to the Follow-up Email Writer.This works because it explains exactly what the agent produces, what it needs as input, when to route to it, and when not to. Super GTM uses all of that to make a routing decision.
Agent name: Email AgentDescription: Helps with emails.This fails because Super GTM has no way to distinguish it from any other email-related capability — the built-in skills, an integration, or another subagent. Most email-related requests will not route here, and the ones that do will be inconsistent.

​
Tips for managing subagents

The description is read by Super GTM, not the end user. Write it for an LLM making a routing decision. Include trigger phrases users might say, the kinds of inputs the agent expects, and any cases where this agent should not be used.
Subagents work best when each one owns a well-defined task. A “research a prospect” subagent and a “draft a follow-up email” subagent will route more reliably than a single “do anything sales-related” subagent.
Super GTM sees every connected subagent at the start of every conversation. As the catalog grows, the orchestrator has more tools and agents to choose between, and routing accuracy can drop. We recommend keeping the total number of connected subagents under ~20 per project. Super GTM also has 10+ built-in tools and agents already, so the effective catalog is larger than just your subagents.
If Super GTM routes to the wrong agent — or fails to route to your subagent when it should — the fix is almost always in the description. Update it to clarify when the agent should be used, then test the same request again.
A skill is the right choice when the workflow is a sequence of steps Super GTM itself should run. A subagent is the right choice when the work is best done by a separate agent with its own configuration — its own system prompt, tools, or integrations. If a skill can do the job, prefer the skill.

​
Frequently asked questions (FAQs)

Not currently. Each connected agent has a single conversation per Super GTM session, and follow-up messages from Super GTM go to that same conversation rather than spinning up a new instance.
Not currently. When Super GTM invokes a subagent, it waits for that subagent to respond before continuing — invocations happen one at a time, sequentially.
Yes. If Super GTM needs more from a subagent it has already invoked, it sends a follow-up message into the same subagent conversation rather than starting a new one. The subagent keeps its prior context for that session.
Approval requests are passed up from the subagent to the Super GTM UI, where the user approves or rejects them just like they would for any other approval-gated action. Once the user responds, the subagent continues from where it paused.
There is no hard technical limit, but we recommend connecting no more than ~20 subagents per project. Beyond that, Super GTM has more capabilities to choose between and routing accuracy starts to drop. Keep in mind that Super GTM already ships with 10+ built-in tools and agents, so each subagent you connect adds to that baseline.
Yes. The “Can be used by Super GTM” setting is project-wide — once an Agent is enabled, every Super GTM user in the project sees it as a subagent. Use this in combination with the Agent’s own permissions in the builder to control who can run it.
Super GTM cannot enable the toggle without a description. If you remove the description after the toggle is on, the Agent will still appear in the catalog but Super GTM will have no information to route on, so requests are unlikely to reach it.

​
Skills, subagents, and memory

Subagents sit alongside skills and memory as the three ways you tailor Super GTM to your team’s work:
  • Skills define repeatable workflows Super GTM runs itself, step by step.
  • Subagents delegate work to a separate agent that has its own configuration and runs in its own context.
  • Memory personalizes how Super GTM and its subagents present output back to each user.
A common pattern is a project skill that tells Super GTM to call a specific subagent at a specific step — for example, a “post-meeting follow-up” skill that delegates email drafting to your Cold Email Writer subagent. Memory then shapes the tone of the final output for each user.