Escaping the "Human Router": A Practical Guide to Multi-Claude Code Agent Orchestration
The bottleneck of multi-agent workflows is the orchestration layer, not the coding capability of individual agents.
The article describes a homelab developer managing 11 projects and multiple agent sessions with Claude Code who, lacking an automated relay mechanism, manually copy-pasted 257 prompts in a week and took an average of 11 minutes to notice agent completion—becoming a "human router" between agents. The author analyzes the trade-offs between single agent + subagents and multi-agent + scheduling layer, and proposes three automated relay approaches: script monitoring of Vikunja state with tmux injection, agents proactively calling notification interfaces, and a supervisor agent for unified dispatch. Design principles emphasize centralized state visibility, failure isolation with timeout and retry, and preserved human feedback entry points. The conclusion is that the orchestration layer is the real bottleneck of multi-agent systems, and starting with tmux + polling scripts is the lowest-cost first step.
From "Human Router" to CEO: The Pain Point of Multi-Agent Orchestration
A homelab developer manages 11 projects with Claude Code, each equipped with a planning orchestrator session and a code-only development session, plus an infrastructure agent. These agents hand off work through Vikunja task comments. Sounds automated, right? But the reality is that he himself became the "wiring" between agents: last week he manually copied and pasted 257 relay prompts across about 20 terminals, and it took him an average of 11 minutes to notice that an agent had finished. What he wants is simple—like a CEO, just give ideas, receive results, and give feedback, with everything in between fully automated. This dilemma strikes a chord with many developers trying multi-agent workflows: the tools can already write code, but the coordination cost still falls on humans.
According to the original Reddit post, this "babysitting" mode drastically reduces efficiency. The core problem isn't the capability of any single agent, but the lack of automated task flow and state awareness between multiple agents.
Why "One Agent + Subagents per Project" Isn't a Universal Solution
The original poster's question is: should each project use just one agent, with subagents handling granular tasks? From community discussion, this is indeed a common approach, but not without cost. The benefit of a single agent + subagents is centralized context and simple coordination, but the drawback is that a single agent easily becomes a bottleneck—especially when there are many projects and high task parallelism—and dependencies between subagents still need to be scheduled by the main agent.
Another approach is to keep the multi-agent architecture but introduce a lightweight "scheduling layer"—for example, using a message queue or task board to automatically trigger agents. Vikunja already serves as task storage here, but lacks an automatic notification mechanism. Some developers suggest using webhooks or polling scripts to monitor task state changes: once an agent completes a task, the next prompt is automatically generated and sent to the next agent, eliminating manual relay.
Three Feasible Approaches for Automated Relay
Given the tech stack in the original post (Claude Code + Vikunja + multiple terminals), several implementation paths emerge:
Approach 1: Script Monitoring + Auto-Injection
Write a daemon script that periodically queries the status of specific tasks in Vikunja. When a "pending" comment is detected, extract its content and automatically input it into the corresponding Claude Code session via a terminal multiplexing tool (such as tmux send-keys). This directly replaces manual copy-pasting, turning 257 operations into 0. The key is mapping session identifiers: which terminal corresponds to which project and which agent requires a configuration table to maintain.
tmux send-keys is a command of the terminal multiplexer tmux, used to send a sequence of keystrokes to a specified session or window, equivalent to someone typing those characters on the keyboard. In automation scenarios, it is often used to inject input into a running interactive program (such as the Claude Code REPL) without manually switching terminals. Before use, you need to obtain the target pane identifier (such as session:window.pane) via tmux list-sessions or tmux list-panes, and ensure the target program is in a state that accepts input. Since send-keys directly simulates keyboard input, it does not rely on the program providing an API, so it works with any CLI tool—but this also means it cannot sense whether the program is ready, and typically requires pairing with tmux capture-pane to read output or adding delays to ensure reliability.
Vikunja is an open-source, self-hosted task management tool supporting kanban, list, Gantt views, and providing REST API and webhook capabilities. In multi-agent workflows, it is used as shared task storage: each task corresponds to a work item, and agents hand off state and content by adding comments. To implement automated relay based on Vikunja, you need to understand the basics of its API—for example, fetching comments via GET /api/v1/tasks/{id}/comments, adding new comments via POST, and using task labels or custom fields to mark states like "pending" and "done". Vikunja natively supports webhooks (configured in the project), which can push events to an external URL when tasks are created, updated, or commented on. This is more real-time than polling but requires an additional receiving service.
Approach 2: Direct Agent-to-Agent Communication
If Claude Code supports tool calling or function execution, agents can proactively call a "notification interface" after completing a task, writing the result to Vikunja and triggering the start of the next agent. This requires configuring a simple CLI tool or HTTP endpoint for each agent so it has "handoff" capability. Compared to polling, this is more real-time but demands greater agent autonomy.
Approach 3: Upgrade to an Orchestration Framework
Some in the community mention orchestration frameworks like LangChain and CrewAI, but they don't naturally fit Claude Code's terminal interaction model. A lighter approach is the "supervisor pattern": a main agent reads the global task list, generates subtasks based on dependencies, and dispatches them to worker agents. The "orchestrator session" in the original post already has the rudiments of a supervisor; what's missing is an automatic wake-up mechanism.
Supervisor Pattern is a common topology in multi-agent orchestration: a main agent (supervisor) holds the global task view, responsible for decomposing high-level goals into subtasks, ordering them by dependency, and dispatching them to worker agents; worker agents only execute specific subtasks and return results, without communicating directly with each other. The advantage of this pattern is centralized coordination logic, easy monitoring and debugging; the drawback is that the main agent may become a bottleneck, and it demands strong planning capability from the main agent. In the context of Claude Code, the "orchestrator session" naturally suits the supervisor role, but requires an automatic wake-up mechanism—for example, when a worker agent completes a task and writes to Vikunja, an external script or webhook triggers the orchestrator session to continue planning the next step, rather than waiting for a human to push it.
Key Design Principles: Boundaries for Reducing Human Intervention
Whichever approach you choose, several principles are worth noting. First, state visibility: each agent's current state (idle, working, waiting for feedback) should be displayed centrally, not scattered across 20 terminals. Second, failure isolation: one stuck agent should not block the entire pipeline; timeout and retry mechanisms are needed. Third, feedback loop: the author wants "giving feedback" to remain a human task, meaning automation should only cover relay between agents, while human decision points retain clear entry points.
The original poster's statistic of "median 11 minutes to notice completion" exposes a monitoring blind spot. If a dashboard showed all agents' task states and last activity times, this latency could drop to seconds.
Conclusion: The Orchestration Layer Is the Real Bottleneck of Multi-Agent Systems
Claude Code makes the coding capability of a single agent readily accessible, but when the number of projects rises to double digits, the real challenge shifts from "writing code" to "coordinating code". The original poster's 257 copy-pastes are an extreme but real signal: without an orchestration layer, multiple agents are just multiple islands. Whether it's script-based automated relay, agents proactively communicating, or introducing a supervisor agent, the goal is the same—freeing humans from the "wiring" role and preserving only decision-making and feedback. For homelab enthusiasts, starting with tmux + polling scripts is probably the lowest-cost first step.
Related articles
Random Pruning of the DPO Computation Graph: 1.4x Training Speedup and Lower Peak Memory
DPO training too slow and memory-hungry? This paper proposes a random pruning framework for the DPO computation graph, sampling independently across position, sequence, and branch dimensions; branch pruning achieves a 1.426x step-time speedup and cuts training time by about 30%, with in-depth attribution of memory and time gains.
Why Does JEPA Underperform MLM in Longitudinal EHR Representation Learning?
New study compares JEPA and MLM for longitudinal EHR representation learning on MIMIC-IV: three JEPA variants train stably without collapse but underperform MLM; target size, not heterogeneity, drives prediction error.
Transfer Learning + Visible Light Communication: A New Approach to Energy-Efficient Indoor Positioning
A study proposes a transfer learning-based visible light communication indoor positioning method, achieving 47% accuracy improvement on the BOSCH factory dataset, 67.5% model efficiency under high noise, and introducing the ME composite metric for energy-efficient positioning in energy-constrained industrial IoT scenarios.