Video summary

claude code orchestration workshop

Main summary

Key takeaways

Technology

Why orchestration features exist (context & token reasoning)

The speaker explains that early agent setups struggled with reliable function/tool calling, which made it hard for models to consistently run CLIs/tools (for example, the GitHub CLI).

MCP servers improved tool access, but they introduced a new problem: loading many MCP servers exposed lots of tool metadata (arguments/descriptions). This could quickly fill the context window.

To address this, skills were introduced as a more context-efficient mechanism. Instead of loading full tool details up front, the model sees only a small “recipe” snippet (name + a few lines). More details are loaded later via the skill file at execution time.

Net effect: skills and workflows help manage context window usage and token cost when orchestrating many actions.

Core orchestration primitives (what they are + use cases)

Skill

A skill is a “recipe” a Claude agent can follow.

  • Used for: repeatable procedures (e.g., how to use a CLI to create PRs).
  • Why it helps: you can have many skills without as much context explosion as with large MCP tool descriptions.
  • Guidance: don’t “blindly” use huge prebuilt GitHub skills—make or modify skills for your own process.
  • Also distinguished by:
    • Model-invocable vs User-invocable Some high-stakes actions should be manually triggered to reduce risk.

Subagent

A subagent is for one-off side tasks.

  • Invoked for: a specific task.
  • Context behavior: it doesn’t see full chat history, so it uses smaller isolated context.
  • Useful when: you want a discrete work item handled without broad context sharing.

Agent teams

Agent teams are a small crew of agents with named roles that can message each other and run across multiple sessions.

  • Best for: coordination (e.g., frontend agents aligning with backend agents so both sides stay consistent).
  • Tradeoff: more agents ⇒ more inter-agent messages ⇒ faster context/token consumption.

/goal

A /goal is a single plan that Claude loops repeatedly until a completion condition is met.

  • Strategy: “depth” via repeated iterations toward criteria.
  • Can spawn: agents/agent teams depending on prompting.
  • Tradeoff: can increase cost.
  • Not ideal for: broad parallelization.

Workflow / Dynamic workflow (main focus)

A workflow (especially dynamic workflows) uses a “width” approach:

  • Claude writes/executes code that runs many agents in parallel.
  • Results converge at the end.
  • Key structural detail: the plan lives in code, not inside the agents’ context.

Agents behave like “brainless workers” focused on their task, rather than coordinating through shared conversation context.

Powerful—but can be extremely expensive if poorly scoped (the speaker cites quota exhaustion happening within minutes).

Detailed guidance on cost, safety, and evaluation

The repeated theme is to always estimate:

  • how many agents/subagents will spawn,
  • how much context each agent reads,

  • which model each agent uses (Haiku cheapest, Sonnet middle, Opus most expensive),

  • and the overall token cost / quota impact.

Preference: workflow engineering + inspection

The speaker strongly prefers creating workflows and then reviewing them:

  • Instead of letting Claude fully generate and run an entire workflow blindly,
  • they create/modify the workflow file so behavior is predictable.

Why this matters: workflows are inspectable:

  • You can open the workflow files.
  • You can also inspect generated subagent files, including:
    • system reminders,
    • attachments/tool visibility,
    • and injected context.

Common pitfall: unintended expensive models

If model choices aren’t explicit, Claude may select an unintended expensive model for subagents.

  • Example failure: workflows created agents using Fable 5.1 across many agents when the intended model was cheaper.
  • Fix: explicitly constrain the model used by agents/subagents when creating/executing workflows.

When to use which (practical decision framework)

  • For a single session, quick edits, or steering within one chat: use standard interaction or agent teams/subagents—not workflows.

  • For large parallel jobs (audit/review of many files, migrations, deep research, stress-testing decisions): use dynamic workflows.

  • For cross-dependent coordination (e.g., frontend/backend consistency): use agent teams, not workflows.

  • Avoid / don’t rely heavily on UltraCode: it can combine multiple workflows at high parallelism (“x-high plus workflows”) and tends to consume tokens quickly. The speaker hasn’t found a need beyond workflows/agent teams//goal.

Demo: Dynamic workflow example (audit + migration assistance)

The speaker demonstrates a dynamic workflow using a template repo containing many “cursor rules.”

Workflow objective

Analyze rules and determine which should become:

  • Claude skills
  • Claude commands
  • versus persistent/global rules.

Approach

  • Run the workflow in a report-only first pass (no edits).
  • Scope the analysis to a specific directory’s global files, not the whole repo.
  • Use one worker per file, with the cheapest model (Haiku) for workers.

Results

They audited multiple rules and produced an audit report quickly—about ten minutes after spinning up ~30 workers.

Failure/mistake demonstration (model specification)

When asked to create and execute a migration workflow without careful model specification, the system generated workflow agents using Fable 5.1 (incorrectly expensive) instead of the intended Sonnet 4.6.

Fix: explicitly constrain the model used by agents/subagents when creating/executing workflows.

Skill hygiene & maintenance (evaluation practices)

When managing many skills (the speaker references cases involving “a thousand skills”):

  • First step: delete unnecessary skills (note that enterprises may be limited here).
  • Separate human-invocable vs model-invocable skills. Using user-invocable flags reduces context load and limits model invocation surface.

“Skill hygiene” evaluation approach

  • Add automated reviews (e.g., a “slop gate” triggered on push/changes to skill files).
  • Use model-based skill review that outputs structured results, then mark pass/fail programmatically.
  • Add hooks/scanners for common bad patterns (“skill slop”).
  • Add CI/evals so problematic skills don’t ship to production.

Main speakers / sources

  • Speaker: Shrey (Senior Software Engineer at Microsoft; works on AI; discusses agent orchestration/assist coding; previously used GitHub Copilot; has conference speaking experience).
  • Referenced systems/organizations:
    • Anthropic (skills/MCP/orchestration concepts)
    • MCP servers
    • Claude Code
    • GitHub Copilot
    • GitHub CLI (used as an example of tooling)

Original video