If you use Codex CLI or Claude Code for real work, you’ve probably run into the same problem I did: once a task gets bigger, it becomes hard to see the overall plan, review it before execution, and
keep track of what each sub-agent is doing.
That is why I built Sonol Multi Agent.
It is a local-first multi-agent setup that turns a single request into a structured plan, lets you review and approve that plan in a UI dashboard, and then shows the sub-agent flow and runtime progress while
the work is happening.
This project is for people who want a more visible and controllable multi-agent workflow without handing the source of truth over to a browser tab or a remote web app.
Project link: https://github.com/volition79/sonol-multi-agent
## What you get
With Sonol Multi Agent, you can:
- turn one request into a structured multi-agent plan
- review and approve that plan in a dashboard before execution
- monitor sub-agent flow and runtime progress
- keep orchestration state local instead of making the browser the authority
The goal is not just to make multi-agent workflows possible. It is to make them easier to follow, easier to trust, and easier to recover when something goes wrong.
## How it is set up
The system is split into two skills, and both need to be installed together:
sonol-multi-agent
This handles planning, proposal flow, approval flow, and orchestration.sonol-agent-runtime
This handles runtime reporting, bridge-connected dashboard updates, and shared execution state.
If you install the repo and follow the README, you can use the two skills together as one workflow.
## Why I built it this way
A lot of multi-agent systems are cloud-first.
The planner owns the state, the dashboard owns the state, and after a while the browser session starts to feel more important than the machine actually doing the work.
I wanted the opposite.
In this setup:
- the local AI session creates the first creative draft
- a hosted planner only normalizes and binds that draft
- the local SQLite database remains authoritative
- the local bridge remains authoritative for dashboard and runtime access
- the remote dashboard stays a thin UI layer
That boundary matters a lot to me. I did not want browser storage or a remote dashboard to quietly become the real source of truth.
## Why local-first matters in practice
This is not just a philosophy choice.
It affects how the system behaves when something is messy in the real world.
When orchestration state stays local, it is easier to understand:
- what the current plan actually is
- whether approval really happened
- which run is active
- what events were emitted
- what the local runtime believes right now
That makes debugging, recovery, and trust much better than when state is scattered across a browser session and remote services.
## Tested environments
So far, I have tested this setup in these environments:
- Codex CLI on Windows WSL
- Claude Code on Windows
I also recently tested Claude Code on macOS. The first run hit an environment-specific issue, but once the exact terminal error text was shared, the problem was fixed and the workflow behaved normally
afterward.
That process also helped tighten some of the practical parts of the system, including path handling, runtime behavior, and recovery.
## If you want to try it
If this sounds useful, I’d encourage you to download the repo, install both skills, and try it on a real task.
If you do, I’d especially like feedback on:
- the installation flow
- the approval and dashboard experience
- local-first orchestration tradeoffs
- failure recovery during multi-agent runs
That kind of feedback is much more useful than a demo-only reaction, because the whole point of this project is to make multi-agent workflows usable in actual developer environments.
