dsh-agent-bus

English | 中文

<p> <a href="https://github.com/MistyBridge/dsh-agent-bus/blob/main/LICENSE"><img src="https://img.shields.io/badge/license-MIT-green.svg" alt="MIT"></a> <a href="https://github.com/MistyBridge/dsh-agent-bus"><img src="https://img.shields.io/badge/platform-DeepSeek%20Harness-1a73e8" alt="DeepSeek Harness"></a> <a href="https://nodejs.org/"><img src="https://img.shields.io/badge/node-%5E22.19%20%7C%7C%20%3E%3D24-339933" alt="Node.js"></a> </p>

Multi-agent orchestration for DeepSeek Harness. Stop being the messenger.

dsh-agent-bus is a DeepSeek Harness plugin that turns live sessions in one workspace into an orchestra: they assign work, review each other’s output, and run multi-step DAG workflows — on the inbox you already have.

You keep the specialists. You stop copy-pasting.

Why this exists

Harness already runs several agents in one workspace. It does not let them collaborate.

Without this plugin:

• A planner cannot give a coder a job. You paste the brief.
• A coder cannot wait for a reviewer. You paste the patch.
• When step 3 fails, you reconstruct steps 1–2 from chat logs.

Let the bus run the team. Don’t be the messenger.

What you actually get

Talk stays talk. A question, a ping, a “look at this” is send_note. No ledger, no review, no timeout theatre. If the peer is offline, the note waits and delivers when they come back.

Work stays work. create_task is a job with a body, an optional acceptance bar, and a reviewer. The worker reports; the reviewer accepts or sends the same task back with feedback. The id never changes across rework.

A plan can run without you in the loop. create_flow is a named DAG. You (or the planner agent) write the plan, then create tasks with flow_id and dependencies. Task B is not even delivered until A is accepted. If A is canceled or fails for good, B and C fail with it — no orphaned workers.

The next agent reads the chain, not the archaeology. After settle, the executor can attach a handoff (numbers, decisions, caveats). Dispatch concatenates that into the downstream task. Step 3 does not have to get_task its way through step 1.

You can see it. On the web profile a capsule on the right opens a workbench: a task list, and a per-flow DAG canvas. Click a node for the full requirement. Archived ancestors stay on the graph, faded.

The task log

Chat logs are a lousy work tracker. They mix pings with jobs, they vanish when a session is compacted, and the next agent cannot query “what was accepted yesterday.”

Agent-bus keeps a task log next to the conversation — a durable record of every real job, not a dump of every message.

Notes stay in the session. send_note is conversation. It does not create a ledger row, it does not show up on the panel, and it does not need a report. The jsonl of that session is the log.

Tasks get a ledger row. Each create_task writes who asked, who does it, who reviews, the requirement, optional acceptance criteria, dependencies, and later the verdict. Status moves on that row (queued → submitted → working → completed → settle). Rework is the same id; you can read the whole life of one job with get_task.

The report is stored as a document, not as more chat. Short reports sit inline on the row. Long ones spill to disk, keyed by task id — never by a filesystem path the model could leak:

get_task reads hot then cold. Agents never see the split. The ledger itself lives in the harness storage domain (agent_bus); every open also writes a JSON snapshot under ~/.dsh/agent-bus/backups/ (last 20 kept) so a schema rebuild cannot silently eat the table.

What you browse vs what agents list. The panel is the human log: active work, archive (settled more than 24 hours, or failed/canceled), tokens, and the DAG for a flow. list_tasks hides archived rows on purpose — the worker’s inbox is not a history dump. History is the panel, get_task, and the session log.

That is the point: the next specialist, the reviewer, and you all read the same record instead of reconstructing the job from three chat windows.

Quick start

dsh plugin --profile web add dsh-agent-bus
dsh web

From a local checkout:

dsh plugin --profile web add .
dsh --profile web --dump-config
dsh web

The web-app bundle already mounts storage and the workspace registry. A custom or headless profile must declare storage, storage-json, storage-domain, and workspace in its own cordis.patch.yml — load fails loudly otherwise. A gateway that cannot record must not boot as a silent prompt.

Requires Node.js ^22.19.0 or >=24.

How it works

Delivery is the harness inbox: one followup() per turn, idle sessions take the next item. This plugin does not add a second queue.

The plugin’s job is the ledger — who asked, who does it, what “done” means, what depends on what — plus a panel that reads that ledger.

There is no receive-side tool. The worker sees an ordinary turn. They do the work and call report_task.

note     send_note              →  peer replies in prose (or not)
task     create_task            →  queued → submitted → working → completed → settle
flow     create_flow + tasks    →  DAG auto-dispatches each node after its predecessors settle

Pick the lightest channel that still matches the ask. Chat-as-task is how work gets stuck in working. Task-as-chat is how you lose review.

Agent Bus vs sub-agents

Why we did not build on sub-agents

Harness already ships sub-agents: the parent calls spawn_subagent, a child boots, does the job, and returns a summary. That is the right tool for “go explore this in isolation and come back.”

We did not put the team on that architecture. A child inherits the parent’s permission group and session config — skills, MCP servers, plugin set, model, allowlist. You can trim the toolbelt (agent type, capability mode, persona). You cannot give the coder a repo MCP, the researcher a web MCP, and the reviewer a tighter tenant allowlist as three different configurations. Fine-grained staffing is exactly what a specialist team needs, and inheritance makes it hard.

So every bus peer is a normal DeepSeek Harness session — the same object you already customize. It keeps its own skills, MCP servers, plugin group, permission preset, and model. That is how you staff a team, and it is the same session model a multi-tenant host hangs permission groups and plugin groups on: per tenant, per role, not “whatever the parent spawned.”

Where the cost actually goes

No fake speedup numbers — the difference is where tokens and latency are spent.

Rule of thumb: spawn a sub-agent to protect the caller’s context for a one-shot. Use the bus when the callee is a named teammate — with their own skills, MCP, plugins, and permissions — who will take the next job after this one.

Tools

Docs

License

MIT