From Native Subagents to Multi-Runtime Orchestration

Most multi-agent coding setups start inside one ecosystem. That is often the right place to start.

If I am already working in Claude Code and need another agent to research a code path or review a change, the native delegation model is simpler than adding another orchestration layer.

The problem I am interested in is different: what if I want different coding-agent runtimes in the same workflow?

Native delegation is simple

Inside one runtime, the parent already knows how to create workers, pass context, wait for them, and collect results.

That simplicity starts to disappear when the workers are separate CLIs with different runtimes and capabilities.

I might want Claude Code, Codex, Pi, or another CLI available without making any one of them the owner of the whole system.

Herdr as a shared control plane

This is where Herdr becomes interesting to me.

I do not think of it as another intelligence layer. I think of it as a thin control plane over terminal-based coding agents.

Herdr can recognize multiple agent kinds, including claude, codex, and pi, and exposes common lifecycle operations around them: start an agent, prompt it, wait for it, inspect its state, and read its output.

That gives an external supervisor a small common surface instead of teaching it the interaction details of every CLI.

The hierarchy can stay simple:

supervisor
    |
  Herdr
  / | \
 /  |  \
Claude Codex Pi

The important part is that Herdr does not need to decide how Claude or Codex should reason. It only needs to manage the runtime boundary around them.

Route work instead of building a swarm

The goal is not to send every task to every model and vote on the answers.

A more useful experiment is routing:

task
  |
choose a worker
  |
implementation
  |
independent review

Different tasks may benefit from different agents because of tool access, latency, cost, quota, context limits, or simply the quality I observe for that kind of work. The routing can be manual at first. There is no need to build an AI router before there is evidence that the routing decisions are repeatable.

Using another runtime or model family for review is also useful because the reviewer is not just another copy of the same runtime that produced the implementation.

The orchestration tax is real

Cross-runtime orchestration adds problems that native subagents mostly hide: process lifecycle, different CLI behavior, failures during handoff, and deciding which state is authoritative.

I would rather keep that shared state outside the agents when possible:

GitHub Issue -> spec -> commit + tests -> PR -> review

A worker should be replaceable. If Codex stops halfway through a task, Claude should be able to read the same issue, repository state, and test results and continue without reconstructing a long agent-to-agent conversation.

That is also the main test for whether this architecture is worth keeping. If using multiple runtimes does not produce enough specialization, independence, or flexibility to pay for the orchestration complexity, the native single-runtime workflow is better.

For me, the distinction is becoming:

native subagents = delegation inside one runtime
Herdr            = orchestration across runtimes

Multi-agent coding may be less about spawning more agents and more about routing work to the right runtime.