Multi-agent: supervisor, handoffs & sub-agents #289

Activity

1. codeforstartups

   added this to the P2 — Agents & models milestone on Oct 1, 2026
2. codeforstartups

   added

   help wantedGood for contributorsGood for contributors

   difficulty: advancedDeep / large scopeDeep / large scope

   pillar: dynaflowdynaflow — orchestration engine & visual builderdynaflow — orchestration engine & visual builder

   area: agentsagent primitives & multi-agentagent primitives & multi-agent

   on Oct 1, 2026
3. tikhandesanket commented on Oct 5, 2026

   

   tikhandesanket

   on Oct 5, 2026

   Last edited by tikhandesanket

   Collaborator

   More actions

   Started workin on it
4. tikhandesanket

   self-assigned this

   on Oct 5, 2026
5. tikhandesanket commented on Oct 6, 2026

   

   tikhandesanket

   on Oct 6, 2026

   Last edited by tikhandesanket

   Collaborator

   More actions

   @codeforstartups

   can we design the structure of the ecosystem like this
   dynalabs / ecosystem
   │
   ├── dynavec/
   │ └── Remember
   │ ├── vector search
   │ ├── BM25
   │ ├── hybrid retrieval
   │ ├── graph
   │ ├── embeddings
   │ ├── caching
   │ └── retrieval tools
   │
   ├── dynaflow/
   │ └── Build & run
   │ ├── Agent
   │ ├── Supervisor
   │ ├── Router
   │ ├── Handoff
   │ ├── Workflow
   │ └── State
   │
   ├── dynalogs/
   │ └── Observe
   │ ├── traces
   │ ├── runs
   │ ├── latency
   │ └── token/cost tracking
   │
   └── dynaevals/
   └── Measure & improve
   ├── evaluation datasets
   ├── retrieval evaluation
   ├── agent evaluation
   ├── judges
   └── regression testing
6. tikhandesanket commented on Oct 7, 2026

   

   tikhandesanket

   on Oct 7, 2026

   Collaborator

   More actions

   @codeforstartups, please check this #288. This implementation is tightly coupled we need to decouple it, and the current project.toml actually supports this direction

   I have reviewed the existing agent primitives from #288 and the current project structure.

   My understanding is that the long-term ecosystem should be separated by responsibility:

   • dynavec — Remember: vector storage, graph, retrieval/memory
   • dynaflow — Build & Run: agents, Planner, ReAct, Supervisor, Handoff, Nodes/Subgraphs
   • dynalogs — Observe: tracing and execution logs
   • dynaevals — Measure & Improve: evaluation, quality metrics, and feedback

   For the current #289 implementation, I propose that we do not split the repository or create separate dynaflow/dynalogs/dynaevals packages yet. Instead, we can extend the existing dynavec.agents primitives introduced in #288.

   The main design goal should be loosely coupled / decoupled concepts. Each orchestration component should have a clear responsibility and minimal dependency on the others:

   • Agent → performs a task
   • AgentState → carries shared conversation/context
   • Handoff → transfers control from one agent to another while preserving state
   • Supervisor → decides which specialist agent should handle the next step and aggregates results
   • Planner → decomposes a goal into steps
   • Node/Subgraph → provides a reusable execution unit for larger workflows

   For example:

   User Request
        │
        ▼
    Supervisor
        │
        ├──► Specialist A
        │       │
        │       └──► shared AgentState
        │
        ├──► Specialist B
        │       │
        │       └──► shared AgentState
        │
        └──► Aggregate Results
   

   The Supervisor should not be tightly coupled to a specific agent implementation, storage backend, or LLM provider. Similarly, AgentState should be generic and not depend on DynamoDB, vector stores, or other dynavec internals.

   This loose coupling will make the primitives easier to test, reuse, and eventually move into dynaflow when the ecosystem is split into separate packages.

   For #289, the initial implementation would therefore focus on:

   1. AgentState

   2. Handoff

   3. Supervisor

   4. Minimal node/sub-agent support where required

   5. Tests for:

      • supervisor delegating to at least two specialists
      • result aggregation
      • handoff preserving conversation/state

   This keeps #289 focused on the current acceptance criteria while keeping the architecture ready for the future ecosystem.

   If this direction looks good, I’m ready to start implementing it.
7. codeforstartups

   closed this as completedin #345on Oct 19, 2026