Deep dive · advanced topics · ~30 minInternal talk · July 2026
WIP — draft

Orchestrating
Agents.

Beyond one agent, one terminal: orchestrators and sandboxes, skills & plugins, and the MCP vs CLI decision.

David Budáč
tools → skills → mcp vs cli
2
Agenda

Three parts, ~30 minutes

PartTopicNote
01The tool landscape & orchestrationlive demo
02Skills & pluginslive demo
03MCP vs CLI—

All product claims are date-stamped July 2026 and sourced — see the closing Sources slide.

01

The tool landscape & orchestration

Beyond one agent, one terminal: multiplexers, parallel workspaces, backlog-driven flow, and the sandboxes that make it safe.

3
Orchestration · the map

Single agent → orchestrator → sandbox

Single-agent CLI

One agent, one terminal. Claude Code, Codex CLI — what most of this room runs daily.

Orchestrator

Coordinates multiple agent instances at once — multiplexers, parallel worktree dashboards, backlog-driven fleets.

Sandbox

Isolates what an agent can touch — filesystem, network, git branch — so autonomy doesn't mean risk.

you, turn by turn agent orchestrator agent agent agent agent agent agent fs · network · git — contained
4
Orchestration · Herdr

Herdr: an agent multiplexer

  • Terminal-native, Rust, single binary, runs fully local — no cloud component.
  • Spawns and monitors multiple coding agents (Claude Code, Codex, Gemini CLI, and others) in one terminal.
  • Auto-detects each agent's state — blocked / working / done / idle — plus a local socket API for agent-to-agent handoff.
herdr — one terminal, one dashboard claude code working codex blocked — needs you gemini cli done agent → agent handoff over a local socket API

Earns its place when you're already running three terminal tabs of agents and want one dashboard instead of three.

5
Orchestration · Conductor

Conductor: parallel worktrees, one dashboard

  • Native macOS app (Melty Labs) — runs multiple Claude Code / Codex agents in parallel, each in its own isolated git worktree.
  • Dashboard for monitoring, diff-first review, and PR shipping.
  • Free app; bring your own Claude/Codex subscription.
repo one .git history worktree a agent · own branch worktree b agent · own branch worktree c agent · own branch dashboard diff-first review PR one shared history — three isolated working copies

Earns its place when review quality matters more than terminal muscle memory — the diff-first flow is the differentiator.

6
Orchestration · backlog-driven patterns

Agents that pull from a backlog

ticket ready
→
agent picks it up
→
isolated workspace
→
PR opened
→
human reviews

The human's job shifts from authorship to triage and review — the agent does the first draft of the whole ticket, not just a function.

7
Orchestration · live demo
Live

Symphony: issue → PR, end to end

  • Open-source orchestrator (Apache 2.0) that polls an issue tracker, creates an isolated workspace per ready task, dispatches an agent, updates the issue on completion.
  • Linear is currently the only supported tracker in the released implementation; GitHub Issues is on the roadmap.
  • Agent-agnostic — the coding agent it dispatches is pluggable.

Live This is an OpenAI project, not Anthropic's — worth saying out loud since the coding agent underneath is swappable.

8
Orchestration · fallback

Fallback: recorded run

▢
Placeholder — screenshot or recording of Symphony claiming a Linear ticket through to opened PR goes here.

Use only if the poll cycle stalls live. Keep the "OpenAI project, Linear-only today" caveat in the narration.

9
Orchestration · why sandbox

Untrusted autonomy needs isolation

  • An agent that picks up tickets and opens PRs unattended is, by definition, running with untrusted autonomy.
  • Isolation means containing what it can touch: filesystem, network, and which git history/branches it can affect.
  • The goal isn't distrust of the model — it's bounding the blast radius of a bad tool call or a runaway loop.
sandbox agent ✕ full filesystem ✕ open network ✕ main branch & history own worktree · scoped fs · allowlist a bad tool call stops at the wall
10
Orchestration · Sandcastle

Sandcastle: one call, isolated run

// TypeScript SDK — MIT license import { sandcastle } from "sandcastle"; await sandcastle.run({ provider: "docker", // or podman, vercel, custom agent: "claude-code", branch: "auto" // worktree + branch strategy managed for you });
sandcastle.run() provider — docker/podman/vercel/custom own worktree · own branch agent commits merged back automatically not isolated: mounted volumes · open network egress

Manages sandbox provider, git branch/worktree strategy, and merges commits back automatically. What's isolated: filesystem and process. What escapes: anything the provider itself exposes — mounted volumes, open network egress.

11
Orchestration · failure modes

Failure mode: runaway loops

  • An agent keeps retrying a failing approach without escalating — tokens and time burn with nothing to show.
  • Fix: a hard turn or token budget per task, enforced by the orchestrator, not left to the agent's own judgment.
try → fail → retry, same approach tokens burn every lap hard budget max turns / max tokens stop & escalate the orchestrator enforces the wall — not the agent
12
Orchestration · failure modes

Failure mode: merge conflicts between agents

  • Parallel agents on overlapping files produce conflicting diffs — nobody notices until merge time.
  • Isolated worktrees reduce this but don't eliminate it when tasks genuinely overlap — that still needs a human to sequence the work.
main agent a — own worktree auth.ts agent b — own worktree auth.ts conflict — seen only here same file, two diffs — a human still sequences overlapping work
13
Orchestration · failure modes

Failure mode: review bottlenecks

  • Orchestration multiplies PRs, not reviewers.
  • Without review capacity scaling too, the backlog just moves from "unwritten code" to "unreviewed PRs" — no net gain.
agent agent agent unreviewed — the new backlog PR × 10 … reviewer × 1 throughput moved the queue — it didn't remove it

Orchestration is a throughput tool for writing code, not a substitute for review capacity.

14
Orchestration · takeaway

Which tool, for which situation

SituationReach for
Already running 3 agent terminalsHerdr
Want visual diff-first review of parallel runsConductor
Backlog-driven, unattended issue → PRSymphony (Linear today)
Need real isolation for unattended runsSandcastle
02

Skills & plugins

Packaged instructions that load only when needed — and how a team distributes them.

15
Skills · anatomy of a SKILL.md

A skill: instructions + scripts

my-skill/ ├── SKILL.md # short description (always in context) + full how-to (loads on trigger) ├── scripts/ # optional helper scripts the skill can invoke └── reference/ # optional deep-dive docs, loaded only if needed

Only the description sits in context by default — the rest loads on trigger, not on every turn.

16
Skills · progressive disclosure

Progressive disclosure vs stuffing CLAUDE.md

CLAUDE.md

Paid on every turn, every session — regardless of whether it's relevant right now.

Skill

Description always present; full instructions load only when triggered.

Occasional-but-verbose knowledge belongs in a skill, not CLAUDE.md — this is deck 05, Cost & Context's argument applied directly. /doctor will do the migration for you: it moves always-loaded guidance out of CLAUDE.md into skills and nested files that load on demand.

17
Skills · decision heuristic

Skill, CLAUDE.md, or MCP server — which, when?

NeedReach for
Needed every turn, regardless of taskCLAUDE.md
Packaged know-how, triggered by topica skill
Needs auth, live state, typed API surfacean MCP server (part 03 of this deck)
18
Skills · plugins

Plugins: bundle it for a team

  • A plugin packages skills + subagents + hooks + MCP configs into one distributable unit.
  • Install once — everyone on the team gets the same toolkit and conventions, not a folder of individually copy-pasted skills.
plugin — one unit skills subagents hooks MCP configs versioned together install teammate same toolkit teammate same toolkit teammate same toolkit one install — same conventions everywhere
19
Skills · distribution

Distribution inside an org

  • A plugin lives in a repo the team pulls from — versioned like any other shared config.
  • Updates propagate the same way a shared lint config would: pull, don't copy-paste.
plugin repo v1.3 → v1.4 pull pull pull dev laptop on v1.4 dev laptop on v1.4 dev laptop on v1.4 versioned like a shared lint config pull, don't copy-paste — updates propagate on their own
20
Skills · live demo
Live

Author a skill, trigger it, done

  • Write a short SKILL.md — description plus one instruction file — for a real task from this team's workflow.
  • Start a fresh session and trigger it by name or by describing the task.

Live The point: the barrier to entry is a text file, not a framework.

21
Skills · fallback

Fallback: recorded run

▢
Placeholder — screenshot or recording of authoring a SKILL.md and triggering it in a fresh session goes here.

Use only if live authoring runs long. Narrate the SKILL.md content and the trigger moment from rehearsal.

03

MCP vs CLI

Two ways to give an agent capabilities — most teams default to one without weighing the tradeoff.

22
MCP vs CLI · two options

Two ways to give an agent capabilities

MCP server

Typed, authenticated tools exposed over a protocol. Works in shell and non-shell surfaces alike.

CLI + docs

Plain command-line tools the agent already knows how to compose, with documentation in context.

agent protocol · typed schemas · auth MCP server remote service / API works without a shell shell · pipes · unix idioms bash CLI tool + docs --help loaded on demand
23
MCP vs CLI · MCP's strengths

Benefits of MCP

  • Typed schemas — the agent doesn't have to guess a command's arguments.
  • Auth handled by the protocol, not embedded in a shell command or a stored token.
  • Works in non-shell surfaces — desktop app, web client — where a CLI simply isn't available.
24
MCP vs CLI · CLI's strengths

Benefits of CLI

  • Composability — pipes and Unix idioms the model already deeply understands from training.
  • No schema overhead — no tool definitions to write or maintain.
  • Agents already know Unix — a CLI's help text is usually far leaner in tokens than a full MCP tool schema.
25
MCP vs CLI · token cost

Token cost of tool definitions

  • Every MCP tool schema loaded into a session is fixed input-token overhead, paid every turn — same mechanism as CLAUDE.md (deck 05, Cost & Context).
  • A handful of MCP servers with verbose schemas adds up before a single tool call happens.
  • A CLI's equivalent "definition" is often just a one-line description plus --help on demand — much cheaper by default.
  • Mitigation exists: deferred tool loading (Claude Code's tool search; the API's tool-search tool) keeps schemas out of context until a tool is actually needed — it narrows the gap, but it's opt-in, not the default everywhere.
a few MCP servers every schema, up front, every turn same tools as CLIs one-line descriptions — --help only when called
26
MCP vs CLI · heuristic

The decision heuristic

Capability is…Reach for
Interactive, authenticated, or remoteMCP
Local, scriptable, chainableCLI

Most teams end up with both — choose deliberately per capability, not by habit.

new capability interactive, authenticated, or remote? yes MCP no local, scriptable, chainable? yes CLI decided per capability — most teams keep both re-check with /doctor: it prices what you installed

Then re-check periodically: /doctor prices your installed skills, MCP servers and plugins against their context cost and flags the ones nobody actually uses.

27
MCP vs CLI · case study

One tool, both ways — measured

  • Pick one internal tool exposed both as an MCP server and as a CLI in your own setup.
  • Compare token overhead and latency for the identical task run through each path.

[TODO: fill in your team's own measured tool + numbers before presenting — this slide is a template.]

28
Close · recap

Tools → skills → MCP vs CLI

01 orchestration
→
02 skills & plugins
→
03 MCP vs CLI
  • Orchestration multiplies PRs, not reviewers — throughput only pays off if review capacity scales with it.
  • Occasional-but-verbose knowledge is a skill, not a CLAUDE.md line — it loads on trigger, not every turn.
  • Choose MCP vs CLI per capability, not by habit — most teams end up with both.
29
Close · sources

Sources — all claims dated July 2026

Tools

Herdrherdr.org Conductorconductor.build Sandcastlegithub.com/mattpocock/sandcastle

Full source list with per-claim citations: deck05-facts.md (internal research doc).