Context
Explored a Salesforce AI Research repo that implements multi-agent workflows in Slack. It's a research project (3 stars, 7 commits, Apache licensed) — not an official Salesforce product. Notable: ships with a typo in production code (channle_id), no error handling around tool execution, and TODO comments acknowledging unhandled failure modes.
Interesting pattern: transition-as-tool
Their multi-agent workflow uses a pattern where available agent transitions are encoded as a tool definition. The LLM calls transition(next_module, summary, reason) when it decides the current agent should hand off to another. The forced summary and reason parameters create an audit trail for why the transition happened.
This is more flexible than Shellack's current approach (detect_sub_agent does keyword matching upfront at the start of a conversation). The transition-as-tool pattern would allow agents to escalate or re-route mid-task based on what they discover.
How this could apply to Shellack
- A project agent starts working on a crash report, realizes it's actually a build config issue, and transitions to a different sub-agent mid-conversation
- An agent hits a cross-project concern and transitions to the orchestrator
- The
summary + reason parameters provide observability — each transition is logged with context
Current approach (for comparison)
detect_sub_agent(prompt) in agents/sub_agents.py uses keyword matching on the initial prompt to select a sub-agent class (CrashInvestigator, Testing, CodeReview, Docs). This happens once at the start — the agent can't re-route mid-conversation.
Priority
Low — current routing works fine for the existing sub-agent set. Worth revisiting when adding more specialized agents or cross-project workflows.
Context
Explored a Salesforce AI Research repo that implements multi-agent workflows in Slack. It's a research project (3 stars, 7 commits, Apache licensed) — not an official Salesforce product. Notable: ships with a typo in production code (
channle_id), no error handling around tool execution, and TODO comments acknowledging unhandled failure modes.Interesting pattern: transition-as-tool
Their multi-agent workflow uses a pattern where available agent transitions are encoded as a tool definition. The LLM calls
transition(next_module, summary, reason)when it decides the current agent should hand off to another. The forcedsummaryandreasonparameters create an audit trail for why the transition happened.This is more flexible than Shellack's current approach (
detect_sub_agentdoes keyword matching upfront at the start of a conversation). The transition-as-tool pattern would allow agents to escalate or re-route mid-task based on what they discover.How this could apply to Shellack
summary+reasonparameters provide observability — each transition is logged with contextCurrent approach (for comparison)
detect_sub_agent(prompt)inagents/sub_agents.pyuses keyword matching on the initial prompt to select a sub-agent class (CrashInvestigator, Testing, CodeReview, Docs). This happens once at the start — the agent can't re-route mid-conversation.Priority
Low — current routing works fine for the existing sub-agent set. Worth revisiting when adding more specialized agents or cross-project workflows.