Phase 1 — Formalize the blueprint schema
Turn the existing blueprint design into a real schema with step IDs, dependencies, retry policy, timeout, allowed tool profile, network mode, and output contracts.
JackChen-me/open-multi-agent
Useful Pattern. Wrong Backbone.
This brief explains what the original GitHub project is, which parts are genuinely valuable for Agent Soul System, which parts conflict with the current architecture, and the exact path to adopt the good parts without importing the bad runtime.
Original Repo
What It Is
open-multi-agent is a lightweight TypeScript orchestration engine for short-lived agent teams. Its pitch is simple: define a team, pass a goal, let a coordinator decompose the goal into a task DAG, run independent tasks in parallel, then synthesize a result.
- Positioning
- Not an agent OS. It is a Node-friendly multi-agent execution layer.
- Core Model
- Coordinator agent, task DAG, dependency queue, shared memory, per-agent tools.
- Stack Fit
- TypeScript-first, embeds into Node backends, serverless jobs, CI, or app runtimes.
- Current Facts
- Version 1.1.0, launched 2026-04-01, roughly 5.8k stars, 2.3k forks, 163 commits.
- Main Limitation
- No durable workflow state or checkpointing. The maintainers explicitly do not prioritize that yet.
Recommendation
What We Might Want To Use
The useful parts are almost all about execution structure, not identity, memory, or system ownership.
DAG Scheduler
Independent workstreams can run in parallel without hand-wiring every edge. This maps cleanly to blueprints with explicit dependencies.
Task Queue
A ready-queue model for agent, code, and validation steps is worth porting into the existing runner.
Step Abstraction
The separation between planning, execution, and synthesis is good. For Agent Soul System, it should become blueprint step runners, not a generic team black box.
Parallel Fan-Out
Bounded parallelism is valuable for research, review pipelines, and disposable worker tasks under Carlos or Merlin.
Lightweight Scope
It proves the executor can stay small if memory, persona, routing, and project state remain elsewhere.
Architecture Boundary
What Fights The Current System
Agent Soul System is a persistent autobiographical memory architecture. The original repo is not. That mismatch is the whole point.
Shared Memory
Its memory model is too thin and too transient. Agent Soul System already has workspace files, bank routing, Convex, and five long-term memory backends.
Shell Tooling
Direct shell and file tools are too permissive for this environment. Mike’s proxy rule and safety constraints need a stricter runtime contract.
No Durable Runs
No checkpointing means it is the wrong backbone for multi-step operations that need restartability, traceability, or audit-safe state.
Auto Planning As Source Of Truth
Oliver already owns planning and Carlos already owns staffing and sequencing. The runtime should execute approved blueprints, not replace your chain of command.
In-Process State
Process-local queues and memory are fine for a demo, not for Mission Control visibility or recoverable runs.
Decision
Use It As A Worker Runtime Pattern
The right call is: do not adopt open-multi-agent as the system. Use it as a reference for building a cleaner executor inside the existing stack.
Keep
OpenClaw workspaces, agent persona files, memory banks, Convex/MCC, routing, approvals, project state.
Add
A local DAG executor for blueprint runs with agent steps, code steps, gate steps, and bounded parallelism.
Where
Inside the existing runner layer, not as a competing framework. The most natural host is the current SDK runner path.
Implementation
If We Do Want To Use It
The implementation plan is straightforward if the scope stays disciplined: port the orchestration ideas, keep the current source of truth, and enforce your runtime rules.
Phase 2 — Build the executor in the current runner
Add a DAG scheduler and step runners to the existing SDK runner so agent steps, code steps, and gate steps can execute under one audited runtime.
Phase 3 — Wire runtime contracts into enforcement
Use the generated tool manifest and permission policy as the executor’s source of truth so shell, file, browser, and network access stay constrained.
Phase 4 — Persist run state to Mission Control
Write node-level start, success, failure, retry, and artifact events to Convex and provenance logs so runs are visible and auditable.
Phase 5 — Pilot on bounded workflows only
Start with research fan-out, review pipelines, and disposable worker tasks. Do not let it own autobiographical memory, agent identity, or long-lived project state.
sdk-runner/
├── blueprint_runner.py
├── dag.py
├── scheduler.py
├── tool_policy.py
├── run_store.py
└── step_runners/
├── agent_step.py
├── code_step.py
└── gate_step.py