A model-native meta-agent plugin for DeepSeek Harness: the model synthesizes task-specific workflows at runtime from five agentic workflow patterns (prompt chaining, parallel workers, router, supervisor, evaluation loop) and coordinates tools and subagent
The plugin will be installed here. Keep web if you are unsure.
npx -y @deepseek-ai/dsh plugin --profile web add dsh-meta-orchestrator@0.2.0
Compatibility and provenance
Meta Orchestrator is published as dsh-meta-orchestrator and currently resolves to version 0.2.0. The Hub verifies its manifest and preserves the exact installation source for reproducible installs.
A DeepSeek Harness plugin that teaches the agent to synthesize a task-specific workflow at runtime — instead of hard-coding pipelines or fixed agent topologies. For anyone running multi-step work in DSH who wants the plan the agent follows to be explicit, versioned, and durable rather than implicit.
🧭 How it works
Normally an agent just starts working on your request. With this plugin, it plans first, then works the plan — and the workflow is dynamic: written by the model itself, per request:
Analyze — the agent reads the request; if it is genuinely ambiguous, it asks before doing anything.
Pick a pattern — it chooses one of five proven ways to organize the work: ⛓️ steps in order (prompt-chaining), ⚡ fan out independent parts (parallel-workers), 🔀 classify, then dispatch (router), 🎯 delegate and review (supervisor), 🔁 draft → score → improve (evaluation-loop). Each pattern's detailed playbook is loaded only when picked.
Write the plan down — it calls orchestrate with the stages, the roles it will delegate, and verifiable success criteria. The plugin validates the structure and saves it durably. That is all the plugin ever does: it records plans, it never executes them.
Do the work with DSH's own tools — subagents, todos, workflow scripts, plan mode. The plugin adds no runtime of its own.
Adapt or close — if reality diverges, adapt_workflow revises the plan (every revision is versioned); when the work is done, complete_workflow records how each success criterion turned out.
Simple requests skip all of this — the agent is explicitly told not to orchestrate for orchestration's sake.
flowchart LR
A["1 · Analyze"] --> P["2 · Pick a pattern"] --> W["3 · Write the plan<br/><sub>orchestrate</sub>"] --> E["4 · Do the work<br/><sub>DSH primitives</sub>"] --> M["watch progress"]
M -- "reality diverged" --> AD["revise the plan<br/><sub>adapt_workflow</sub>"] --> E
M -- "work finished" --> D["5 · close it out<br/><sub>complete_workflow</sub>"]
All of this behavior comes from one short instruction block the plugin adds to the agent's system prompt — no extra model calls, no background processes.
What gets installed
Added to your agent
What it is
An instruction block (~330 words)
Teaches the plan-first protocol above; sits in the system prompt of every session
Five pattern playbooks
Skills in the catalog; cost nothing until the model loads one
orchestrate / adapt_workflow / complete_workflow
The three recording tools: save the plan, revise it, close it
🧩 Why it's built this way
The model is the planner — no hard-coded pipeline and no fixed agent topology decides how your task runs; the model picks and composes per request, and may deviate when the task demands it.
Recording, not executing — the plugin holds no runtime, no scheduler, no message bus. Execution stays on the harness's battle-tested primitives, so there is nothing extra to break.
Plans survive restarts — every plan lives in DSH's storage domain as an append-only create → adapt* → complete chain, fenced per session lifecycle. No custom session event types, so orchestrated sessions always resume cleanly.
Built to track a fast-moving harness — only stable public plugin surfaces are used; nothing is pinned to harness internals.
flowchart TB
subgraph P["🧭 dsh-meta-orchestrator"]
direction LR
PS["policy section"]
SK["5 pattern skills"]
TL["orchestrate · adapt_workflow · complete_workflow"]
end
subgraph H["🐋 DeepSeek Harness"]
direction LR
SYS["system prompt"]
CAT["skill catalog"]
REG["tool registry"]
DOM[("storage domain")]
end
PS --> SYS
SK --> CAT
TL --> REG
TL --> DOM
H --> EX["subagent · workflow · todo · goals · plan mode"]
How it compares to other DSH orchestration plugins
dsh-meta-orchestrator
workflow-capsule engines
agent-team plugins
Who plans
The model, per request, at runtime
A generated script in a bundled sandbox runtime
A fixed lead + specialists topology
Pattern choice
Selected and composed from five canonical patterns
Baked into capsule scripts
One topology for every task
Execution
Harness-native primitives only
Own QuickJS/WASM runtime + run store
Own mailbox/wake-up machinery
Re-planning
adapt_workflow re-plans the pattern itself, versioned
Pause/resume/rerun of the same script
Re-brief within the fixed topology
DSH coupling
Public plugin surface only
Pinned to a harness snapshot
Patches harness dependencies
✅ Compatibility
DSH packages
peer range @deepseek-ai/*@^0.1.0-rc.5 — verified against 0.1.0-rc.6, the current npm release
2026-08-14 — real npm install, 46/46 tests, live web profile session
Node
^22.19.0 || >=24.0.0
Profile
needs the storage stack, shipped by the @deepseek-ai/dsh-web-app bundle (the standard web profile). The stock headless profile does not ship it — see Troubleshooting.
Platforms
Windows 11 (dev), Ubuntu (CI)
Only public plugin surfaces are used — systemPrompt, skills, tools, storageDomain, agent/pre-step — so ordinary harness churn rarely bites. But the harness is pre-1.0, and a semver caret does not span prerelease lines: ^0.1.0-rc.5 matches 0.1.0-rc.6, not a future 0.1.1-rc.1. When a new rc line lands, the peer range here needs a bump — open an issue if you get there first.
📦 Install
Requires a profile with the storage stack — the standard web profile (dsh-web-app bundle) ships it (see Compatibility).
dsh plugin --profile web add dsh-meta-orchestrator # from npm
dsh plugin --profile web add github:jiruidai/dsh-meta-orchestrator#v0.2.0 # from git, pinned
dsh plugin forwards to pnpm inside the profile directory, so every pnpm verb works. Restart dsh after an add or remove — the bundle layer list is read at boot; only the cordis.patch.yml layers hot-reload.
A git install builds via the package's prepare script, so pnpm asks you to allowlist it once in the profile's pnpm-workspace.yaml (allowBuilds: { dsh-meta-orchestrator: true }).
Upgrade
dsh plugin --profile web update dsh-meta-orchestrator # within the installed range
dsh plugin --profile web add dsh-meta-orchestrator@latest # across ranges
dsh plugin --profile web add github:jiruidai/dsh-meta-orchestrator#v0.3.0 # git installs: re-add the new ref
Disable without removing
The profile's own patch layer applies after every bundle layer and hot-reloads — this takes effect on the next request, no restart, no reinstall. In $DSH_HOME/profiles/web/cordis.patch.yml ($DSH_HOME defaults to ~/.dsh):
- id: meta-orchestrator
disabled: true
Delete those two lines to switch it back on. Recorded workflows are untouched either way.
Uninstall
dsh plugin --profile web remove dsh-meta-orchestrator # drops the dependency and the bundle layer
Restart dsh. For a complete removal, the leftovers the CLI does not touch:
Leftover
What to do
$DSH_HOME/storages/meta_orchestrator.json
Every workflow the plugin recorded. Delete the file to erase them — nothing else reads it.
allowBuilds entry in $DSH_HOME/profiles/web/pnpm-workspace.yaml
Remove it if you added one for a git install.
meta-orchestrator row in $DSH_HOME/profiles/web/cordis.patch.yml
Remove it if you used the dev-install route below.
Past sessions' session.jsonl
Sessions keep the orchestrate calls that already happened — ordinary session history, not the plugin's to rewrite.
Dev install (local checkout)
Build with pnpm build, then add an absolute-path row to $DSH_HOME/profiles/<name>/cordis.patch.yml:
The web profile hot-reloads its patch layer — the plugin is live on the next request, no restart.
🚀 Quick start
No configuration needed — the defaults are the intended setup. Install into the web profile, restart dsh, and hand the agent something genuinely multi-part:
Audit this repo's error handling, then write a short report with concrete fixes ranked by risk.
What you should see, in order:
The agent names its pattern in a sentence — "this is a chain: audit → rank → write."
A skill call loading that pattern's playbook.
An orchestrate call whose result reads back:
workflow "wf-3f2a91c4" recorded (v1)
pattern: prompt-chaining
stages: 4
success criteria: 3
Execute it with the harness's native primitives and report the final result against the success criteria.
Then ordinary DSH work — todos, subagents, tools. The plugin runs none of it: it recorded the plan and got out of the way.
At the end, a complete_workflow call — workflow "wf-3f2a91c4" completed (achieved, v1).
Proof it was persisted, not just narrated (the file appears with the first recorded workflow):
cat $DSH_HOME/storages/meta_orchestrator.json # $DSH_HOME defaults to ~/.dsh
One entry per session id, holding the append-only create → adapt* → complete chain with a full spec snapshot at every step.
Ask something simple instead — "what's in this folder?" — and the agent skips orchestrate entirely. That is the protocol working, not failing.
⚙️ Configuration
One key, no environment variables, nothing sensitive:
Key
Default
Meaning
autoTrigger
false
Append a one-time protocol reminder inside the first request of a session (delivered by composing the agent/pre-step decision). Off by default: the policy section alone drives the protocol at zero extra token cost.
🔐 Permissions & data
Network
none — no requests, no extra model calls
Filesystem
none directly — one Node builtin, crypto.randomUUID
Credentials / env vars
none read, none stored
Subprocesses
none
Durable storage
DSH storage domain meta_orchestrator, table workflows, keyed by session id — $DSH_HOME/storages/meta_orchestrator.json on the stock JSON backend
Worth knowing what lands in that file: every mutation stores a full spec snapshot — the model's written analysis of your request, stage names and details, the briefs it would hand to subagents, success criteria, and the completion report. That is a paraphrase of your task, in plaintext, per session, on your machine. It never leaves the machine, and deleting the file is the entire erase story.
Scope note: this is a host-plane plugin. The ~330-word policy section and the three tools register globally, so every session in the profile carries them — that is the design (see What gets installed), not a leak. With autoTrigger: true, one reminder message is appended to the first request of each session, once.
🩺 Troubleshooting
Boot fails: meta-orchestrator: pending (waiting for services: storageDomain)
The profile has no storage stack. Only the dsh-web-app bundle ships storage / storage-json / storage-domain; the stock headless profile does not. Install into the web profile — or insert those three rows into your profile's patch layer above this plugin.
No orchestrate tool — the plugin seems absent
Check whether the row actually composed: dsh --profile web --dump-config and look for the dsh-meta-orchestrator layer. Missing → the package isn't installed (re-run dsh plugin … add, then restart dsh). Present but disabled: true → a patch layer turned it off.
First add from git fails on a blocked build script
pnpm ≥ 10 refuses a git dependency's prepare script until allowlisted. Copy the exact key pnpm prints into $DSH_HOME/profiles/web/pnpm-workspace.yaml under allowBuilds: and re-run. That allowance means running package code at install time — pin a tag or sha.
The model answers without orchestrating
Intended for simple requests. If you want a nudge at the start of every session, set autoTrigger: true.
orchestrate rejected the spec: …
A structurally invalid spec (no stages, no success criteria, unknown pattern). The error lists every problem and the model normally fixes it on the next call. Nothing is persisted from a rejected call.
… could not record the spec (storage write failed)
The backend rejected the write — check that $DSH_HOME/storages/ is writable. A failed write leaves the recorded chain exactly as it was; it never half-records.
Where to look
Boot and plugin errors
stderr of the dsh process
What actually happened
$DSH_HOME/sessions/<project>/<session-id>/session.jsonl — tool calls and results are ordinary session events
The durable record
$DSH_HOME/storages/meta_orchestrator.json
Rollback, fastest first: disabled: true in the profile patch layer (live on the next request), or dsh plugin --profile web remove dsh-meta-orchestrator plus a restart. Neither deletes recorded workflows.
🛠️ Development
pnpm install # normal checkout: installs the published @deepseek-ai/* packages
pnpm build # clean + tsc → lib/
pnpm typecheck # src + tests
pnpm test # vitest — 46 unit + mount-integration tests
Issues and PRs are welcome — pnpm typecheck && pnpm test must be green. CI runs install → build → typecheck → test on Node 22 and 24, --frozen-lockfile against the committed pnpm-lock.yaml (generated against registry.npmjs.org).
The maintainer's local checkout instead resolves @deepseek-ai/* from a sibling harness checkout through a hand-built junction tree (see the comments in pnpm-workspace.yaml) — in that setup pnpm install is never run.
Token & KV-cache behavior
Fixed cost per request: the policy section + three tool schemas; pattern bodies only when loaded via skill.
The prefix stays cache-stable while section, tools, and skill catalog are unchanged; enabling the plugin mid-session invalidates reuse from the first changed catalog token.
Tool results are small structured summaries (id, version, pattern, counts).
🚧 Limitations
Prompt discipline is the primary enforcement — a model may skip orchestrate entirely.
Specs are per session lifecycle by design; a reused session id never inherits a stale workflow.
No client UI yet — workflow state is visible in conversation, tool results, and the storage domain.
Reporting a vulnerability — please don't open a public issue. Use GitHub's private vulnerability reporting for this repo; see SECURITY.md. Surface-wise there is little to hold: the plugin executes nothing, opens no sockets, and reads no credentials — the realistic concerns are the policy text it injects and the task paraphrases it stores locally (see Permissions & data).
