For the Standard Agents such as Search Agent ( CoWorker ) and Sales Agent, both are built on the previous planner model using SentOS and not Atlas.
Migrating these into Atlas breaks the logic.
Configuring them with Customized subAgents is an option, however, since managed, not the optimal way.
Idea
Create a Custom Agent using Atlas and Delegate from CoWorker / Sales Agent
Anyone tried it ?
Since we have limited insights into session logs, various A/B testing makes it a little tedious to confirm the delegation in the Agent Router.
Any input is appreciated.
,
On the premise - yes, it's accurate. Standard OOTB agents like the Search Agent/CoWorker and Sales Agent still ship on the legacy topic-based planner. Salesforce's own migration path confirms this isn't a soft upgrade: the official migration options involve either a conversion path or a full Agent Script rebuild, and once you activate the rebuilt agent in the new builder, your original legacy agent is automatically deactivated. So there's no "gradually move CoWorker onto Atlas while keeping it running" path today it's a cutover, which lines up with why you're seeing broken logic on direct migration attempts.On your idea (custom Atlas agent + delegate from CoWorker/Sales Agent to it):
- Delegation/routing in Atlas is modeled through the Agent Router (formerly Topic Selector) and subagent transitions every user utterance begins at the start_agent subagent, which classifies intent and routes to appropriate subagents. That mechanism is designed for subagents within one Agent Script built agent, not for a legacy planner standard agent handing off to a separately built Atlas agent. I couldn't find anything confirming that a legacy CoWorker/Sales Agent can natively transition control to an independent Atlas custom agent as a subagent that's a real architectural seam, not just tooling immaturity.
- There is a low level lever some teams use: the planner type lives on GenAiPlannerDefinition, and you can flip it directly sf data update record -v PlannerType=Atlas__ConcurrentMultiAgentOrchestration -s GenAiPlannerDefinition -i {id}. That's almost certainly the "customized subagents" workaround you mentioned — and your instinct that it's not optimal is right, since it's mutating a managed-package-controlled record outside supported tooling, which is exactly the kind of thing that breaks silently on the next Salesforce release.
- The actual supported direction for cross-agent delegation is Multi-Agent Orchestration on Atlas 3.0 (Summer '26, GA June 15): it doesn't use a fixed decision tree — it reasons from agent descriptions each time, so those descriptions become load-bearing routing inputs, not documentation. Atlas 3.0 also addresses context loss at agent-to-agent handoffs via structured context packets that travel with every delegation, and A2A is the open protocol letting Agentforce agents talk to agents on other platforms/frameworks. If cross-agent delegation is the real goal, A2A is likely the sanctioned mechanism going forward rather than forcing a legacy planner agent to hand off to a bespoke Atlas agent via router hacks.
My take:
treat "delegate from CoWorker/Sales Agent → custom Atlas agent" as unsupported today, not just under documented the planner-type field hack will work in a demo and then fight you every release cycle, especially since you already flagged you have limited session log visibility for A/B confirming the router's actual behavior. I'd sandbox-test the A2A path once Summer '26 orchestration is fully rolled into your org before investing further in the planner-flip approach.
I hope you find the above information helpful. If it does, please mark it as Best Answer to help others too.
