Skip to main content
← Back to blog

orchestration primitive vs desktop ade: pick the right layer

The multi-agent coding category went from a handful of projects in late 2024 to thirty-plus by mid-2026. Along the way it split into two shapes that solve adjacent-but-different problems. When to reach for each, why you might end up using both.

two shapes

Desktop ADEs. A desktop app. You install it like any other, open a window, configure credentials, see your repo, agents, and diffs in one UI. Open-source examples: emdash (Electron, 23 CLI providers, YC W26), Conductor, Cline's desktop mode. Closed-source in the same shape: Claude Code's VS Code extension, Cursor's "run in background."

Orchestration primitives. A library or CLI you import into your own workflow. No window - a process you can pipe into other things. Examples: Bernstein (the project this blog belongs to, 18 CLI adapters, Python-importable), Workz, some configurations of Plandex. LangGraph and CrewAI are adjacent but different - they orchestrate LLM calls, not CLI coding agents.

Different layer of the same problem. Pick by where your workflow already lives.

what an ADE does well

  • A visual workspace. Diffs, PR status, CI checks, agent logs all in one window.
  • Zero-config launch. Open the app, it picks up your repo, agents just work.
  • Identity handled. Credentials in the OS keychain, not a .env that leaks.
  • Distribution. Electron installers for macOS, Windows, Linux. Your non-terminal colleague can use it.

Right answer when:

  • You keep an IDE open all day and want agents inside that workflow, not hidden in a tmux pane.
  • You're onboarding teammates who don't live in the terminal.
  • You want one tool covering edit, review, merge, and CI visibility end-to-end.

Trade-offs:

  • Not programmable from outside. You can't import emdash or kick off a parallel run from a CI job. It's a UI, not a library.
  • Opinionated conventions. Agents in app-managed worktrees, audit logs in app databases. Extracting them is possible but not first-class.
  • Cross-machine coordination usually requires an extra feature on top.

what a primitive does well

  • A process you can script. bernstein run --goal "..." | jq . works. So does invoking from GitHub Actions, or import bernstein.core in Python.
  • Deterministic coordination. Scheduler is a regular event loop. Every run replay-able from the audit trail.
  • MCP server mode. Your agent of choice talks to the orchestrator through the same Model Context Protocol Anthropic publishes for Claude Code.
  • Composition. The primitive is one step in a larger pipeline: linter → multi-agent pass → janitor → merge queue → deploy.

Right answer when:

  • You want to embed multi-agent coding in something you already run: CI, internal dev platform, evaluation harness.
  • You care about reproducibility. HMAC-chained audit gives you "did the agent really do that?" answers days later.
  • You're already in a scripting-first workflow and don't want a new app to keep open.

Trade-offs:

  • No visual diff/merge UI out of the box. git diff the worktree, or plug into existing tools.
  • Setup needs a terminal. pipx install bernstein && bernstein init, not a double-click installer.
  • One layer of a larger stack. You'll likely pair with a separate review tool, CI, notification channel.

shortcuts

  • Building a product on top of multi-agent coding? Primitive. Libraries compose; apps don't.
  • Onboarding a team that wants a single download? ADE. Hard to beat for non-power users.
  • Agents in CI, evaluation, internal platform? Primitive, almost always.
  • Agents on your own laptop during normal dev? Either works. Try both for a week.
  • Need to prove to compliance "here's exactly what happened"? HMAC audit trails live in the primitive layer. ADE output logs are usually app-scoped.

both at once

Nothing prevents running both. A pattern from Bernstein's early users:

  • Bernstein in CI for the "every PR gets a lint-plus-refactor agent pass" step.
  • Desktop ADE for interactive "I'm pairing with Claude Code on this refactor" flow.
  • Bernstein's MCP server exposed to the ADE so both see the same audit trail.

If you're already on an ADE and it covers what you need, keep it. If you hit "but I want to run this from a shell script / from CI / inside another service," that's the signal to look at a primitive. The leaf-node delegation pattern that lets Bernstein wrap another orchestrator (or another ADE) as a single step is walked through in orchestrate the orchestrators.

where Bernstein sits

Primitive shape. What we optimise:

  • Deterministic coordinator in plain Python - no LLM in the scheduling loop, runs reproducible.
  • HMAC-chained audit - every agent action replay-able days later.
  • MCP server mode - expose Bernstein to any MCP-capable client (Claude Code, Cursor, your own agent).
  • 18 CLI adapters: Claude Code, Codex, Cursor, Aider, Gemini CLI, OpenAI Agents SDK, Amp, Cody, Ollama, more.
  • Apache 2.0, BYOK, pipx install bernstein.

What we don't build: a desktop UI. emdash and Conductor both do that well; if you need one, try those.

Plenty of room in the category for multiple right answers. The thing primitives and ADEs are both replacing is the "write a bunch of glue code to make two agents work on the same repo without destroying it" option that nearly everyone used until twelve months ago. Neither shape is going back to that.

If you want a more concrete read of how the primitive shape plays out day to day, introducing Bernstein covers the original goal and the v2.0 release notes cover what shipped most recently.

  • cost calculator - put your own monthly Claude + Codex + Cursor bill in and see the band of LLM spend Bernstein's cheapest-passing-test routing would shift.
  • why Bernstein - the longer-form pitch: who it is for, how the audit trail works, and what it deliberately does not try to do.
Bernstein

Prefer a weekly recap? Subscribe to the weekly digest.