[FEATURE] Support for Multi-Framework Agent Integration in Strands Swarm

[sambydlo]

Problem Statement

I would like Strands to support agents built in other frameworks (LangGraph, Quick Suite, etc.) within Strands swarm constructs. Currently, Strands swarm requires all agents to be native Strands Agent instances, which means I cannot leverage existing agents from other frameworks without completely rebuilding them in Strands. This creates significant development overhead when I want to extend multi-agent systems with agents that already exist in other ecosystems.

Proposed Solution

Expand on the FunctionNode work to expose framework-specific agent wrappers (LangGraphAgent, ADKAgent, etc.) that adhere to the new AgentBase interface. This would allow agents from different frameworks to be mapped to a Strands-compatible interface and participate in Strands swarm orchestration alongside native Strands agents. The solution should enable mixed-framework swarms where agents from different ecosystems can collaborate using Strands' pre-built multi-agent constructs like swarm, handoffs, and other orchestration patterns.

Use Case

This would help with customer scenarios where existing agent investments need to be integrated into Strands-based multi-agent systems. For example, I have a multi-agent system using Strands swarm where a coordinator selects 2-3 domain experts from a pool and creates a temporary swarm for handoff-based collaboration (repo: github.com/aws-samples/sample-advcomp-expert-team-strands-agentcore). I've encountered requirements to extend this system with agents built in LangGraph or Quick Suite rather than rebuilding them from scratch in Strands Agents, but then using those agents in Strands multi-agent constructs like swarms. The ability to integrate these external agents would enable reuse of existing work, reduce development time, and allow customers to leverage Strands' orchestration capabilities without abandoning their current agent investments.

Alternatives Solutions

Current workaround: Manually rebuild agents from other frameworks as native Strands agents. This works but creates significant duplication of effort and maintenance burden.

Alternative approach: Build custom communication protocols outside of Strands swarm constructs. This is feasible but loses the benefit of Strands' pre-built orchestration patterns and requires reinventing coordination logic that swarm already provides.

Additional Context

Reference conversation: github.com//pull/991 introduced FunctionNode for executing arbitrary code. A similar pattern could potentially be extended to support framework-agnostic agent integration.

This feature aligns with the "Extensible by design" and "Embrace common standards" tenets by meeting customers where they are with flexible extension points and respecting existing framework investments.