Building a Herdr-Based Multi-Agent Workflow

1. The illusion that one prompt would be enough—and the wall I encountered

With excellent AI coding tools such as Claude Code, Antigravity, Cursor, and Codex becoming commonplace, everyone has probably experienced the astonishing moment when they ask, "Add this feature for me" in a single line of a prompt and the code is instantly completed.

For toy projects or simple scripting, it is more than sufficient to launch a single AI agent and code conversationally. However, the moment you enter a real enterprise backend environment where multiple developers collaborate and complex business rules, strict DDD architecture, and transaction boundaries are intertwined, the single-agent approach begins to reveal its severe limitations and failures.

When handling a complex feature ticket assigned to me on a team project, I found that assigning an entire process—from DB migration DDL and JPA repositories to domain entities, service logic, REST APIs, and test code—to a single agent session quickly led to critical problems. Once the conversation exceeded 15–20 turns, it would forget the framework conventions and domain invariants emphasized at the beginning and overwrite the code arbitrarily. A tiring back-and-forth repeated endlessly, with developers manually pointing out syntax errors and missing business exception handling while visually debugging the agent-written code line by line. At times, it could not identify flaws in its own design and code, instead justifying its blind spots by saying, "Everything is perfect."

After confronting these problems, I changed the direction of my question.
"Instead of entrusting everything to a single AI, what if we built an autonomous agent team in which specialized agents in each field verify and improve one another?"

2. Why 'Multi-Agent' instead of a single agent?

A multi-agent system offers several advantages that are unavailable in a development process carried out by a single agent.

① Distributing cognitive load and preserving role purity

If you tell a single agent, "Analyze the existing code, write the design, then implement and test it," the LLM's internal mechanisms experience cognitive overload.

When it is simultaneously assigned the roles of investigator, designer, developer, and tester within a single prompt, it tends to skip the codebase investigation phase, which requires the most time and effort, and take a shortcut: writing appropriate-looking code with insufficient Context.

In contrast, in a multi-agent system, the assigned agent is given a single purpose: "You are an investigator whose sole task is to investigate the facts (Domain relationships, DB schema, and call flow). Do not write code under any circumstances." When each agent focuses 100% on a single persona, the density and accuracy of its output are maximized.

② Breaking self-confirmation bias through independent verification

Even people find it extremely difficult to identify typos or logical errors in reports they have written themselves. LLMs likewise exhibit self-confirmation bias toward the assumptions and designs they have established.

If you ask, "Are there any bugs in the code I wrote?" in a single-agent session, it commonly inherits the premises of the logic it just wrote and replies, "It is perfect with no problems."

In a multi-agent system, the designer's plan is handed to an independent verifier who knows nothing about it. Working on the premise that "this design/code must contain a critical flaw," the verifier directly opens the actual source code and compares it against reality, filtering out numerous potential runtime exceptions and race conditions in advance.

③ Context-window hygiene and preventing performance degradation

Even though LLM context windows have grown to more than 1 million tokens, the 'Lost in the Middle' phenomenon—forgetting initial instructions or missing intermediate information—as well as degraded reasoning performance remain real problems as conversations grow longer.

A single agent carries tens of thousands of lines of text from opening 30 files, Gradle build error logs, and verbose stack traces all within one session context.

In a multi-agent environment, only the refined, essential outputs are handed off to the next agent when each work stage ends. The thousands of lines of investigation and build logs remain isolated within their respective Pane, so the contexts of the orchestrator and designer stay clean and sharp at all times.

④ Synergy between heterogeneous models and compensating for blind spots

Using a top-tier model for every task makes API costs explode and quickly reaches token limits. Conversely, using only lightweight models for every task causes complex domain architecture reasoning to collapse.

Large-scale exploration and simple repetitive coding/testing are assigned to models that are inexpensive, offer vast token contexts, and operate quickly, while highly sophisticated domain and architecture design is concentrated in top-tier models with deep reasoning capabilities.

Gemini reviews code written by Claude, and Claude reviews code written by Gemini. The two models, with different training data and architectures, complement each other's blind spots.

3. Getting started in practice: Heterogeneous pairing of Antigravity and Claude Code

It began as a very simple experiment.
"What if we launch Anthropic's Claude Code and Google's Antigravity side by side and make them work together?"

When I actually paired the two models, the synergy exceeded my expectations.

Claude Code's Opus model demonstrated overwhelming strengths in complex business logic, object-oriented separation of responsibilities, and use-case design. Antigravity's Gemini 3.6 Flash model was unrivaled at investigating DB column types, Spring bean dependencies, and legacy transaction rules by searching through the actual filesystem with massive context and frightening speed.

The two Big Tech models, with completely different training architectures and perspectives, cross-validated each other and seamlessly filled the blind spots missed when using same-model verification, thereby improving the completeness of the code.

4. The end of the 'copy-and-paste shuttle': Introducing the terminal multiplexer Herdr

Heterogeneous model pairing was fantastic, but I soon ran into a new physical bottleneck.

I would copy the design from terminal 1 (Claude), switch to terminal 2 (Antigravity), paste it, and ask, "Verify this for me"… then copy the result again, paste it into terminal 1, and ask, "There is a problem here. Check it out"…. The same process kept repeating.

Although the agent roles had been separated, I, the developer, had become a 'copy-and-paste shuttle' moving back and forth between terminals.

To end this hell of manual switching, I explored several approaches, and as it happened, I discovered Herdr.

Herdr was fundamentally different from ordinary terminal tools that merely split the screen into multiple sections. It was closer to an 'agent-specific background orchestration engine' that managed the agents' life cycles and message delivery.

• Herdr monitors each Pane's output stream in real time and determines for itself whether an agent is working (Working), blocked (Blocked), or finished (Done). The need for a person to wait in front of the terminal and judge when to press Enter disappeared completely.

• The moment one Pane completes its design and displays Done, the Herdr daemon captures the output Markdown via JSON-over-Socket IPC and immediately injects it directly, together with the prompt, into the next Pane's standard input (stdin). Copy-and-paste fatigue literally became zero.

• When running a long build or the full test suite in a single session, even the developer's prompt window would often freeze completely. In Herdr, each Pane is isolated in its own process and virtual TTY, so even while one Pane was running hundreds of tests in the background, work could continue at any time in another Pane's terminal.

5. The evolution of Herdr's multi-Pane setup: From separating the coding Pane to completing 8 Agent Panes

I did not start with 8 perfectly configured Panes from the beginning. I processed complex development tasks one by one, encountered countless failures and bottlenecks, and evolved the setup by separating out a dedicated Pane whenever a new pain point emerged.

Stage 1: The first separation, starting with one-to-one ping-pong (coding Pane)

Initially, the main session (Claude Code) handled everything alone: requirements analysis, architecture design, code writing, and compilation. However, as dozens of file-edit histories and extensive compilation error logs accumulated directly in the main session, context contamination occurred: after only 10 turns, it would forget the domain rules from the beginning.

To solve this, I separated the coding Pane for the first time. The main orchestrator handled only the overall design and instructions, while delegating large-scale code typing and compilation-error debugging to Gemini Flash, whose overwhelming speed began keeping the main context clean and protected.

Stage 2: Heterogeneous dual reviewers that shattered the belief that "the code I wrote is perfect"

Although I had separated the coding Pane, I soon encountered another problem. After coding was complete, asking the agent that wrote the code or a single developer to "review it" resulted in nothing but a soulless response—"All requirements have been perfectly satisfied"—due to self-confirmation bias. Eventually, bugs made their way into the main branch.

To address this, I created two independent review Panes using different models that conducted destructive reviews under the assumption that "this code must contain a hidden flaw." I assigned claude-review to identify architecture violations and domain invariants, and antigravity-review to investigate Null safety, SQL N+1, and transaction rollback. In particular, I ran both reviewers simultaneously (Parallel) rather than sequentially, cutting the wait time in half and completing a mutually independent, multidirectional cross-verification network.

Stage 3: It is too late to overturn everything after coding is finished—introducing design verification (design-verify)

However, even when coding and reviews were flawless, another major source of waste remained. Only after coding was completely finished and the review stage began would we sometimes discover fundamental flaws, such as "the basic domain modeling is wrong" or "the transaction boundary design is misaligned." Each time this happened, we had to roll back hundreds of lines of hard-won production code in their entirety and start over from scratch.

To fundamentally prevent this massive rework, I adopted a strategy of moving defect detection to before coding began. I added a design-verify Pane that immediately opened the actual source code and compared it against the design document as soon as the document was written. By eliminating edge cases and architectural flaws 100% during the design phase before starting to code, the number of iterations in the overall development cycle decreased, cutting development time in half.

Step 4: Separate the Commander and the Designer — Independent design Pane

Once the design verification loop had settled into place, a new bottleneck emerged. Because the main orchestrator was directly responsible for writing detailed domain design documents spanning hundreds of lines, its context window rapidly ran out during the deep design reasoning process. The cognitive capacity of the commander, who was supposed to coordinate and control multiple Panes while communicating with the developer, was deteriorating.

In response, we established the principle that "the orchestrator must not write documents directly and must focus solely on command and gatekeeping," and independently separated a design Pane dedicated to deep object-oriented reasoning and design.

Step 5: Do Not Design from Imagination — Isolate the research Pane

Even after separating the Pane dedicated to design, incorrect designs occasionally emerged. When the design agent was asked to handle both research and design at once, it began skipping the exploration of the vast codebase and starting the design based on its own memory.

To prevent this at the source, we independently established a research Pane that investigates only the package dependencies, DB schema types, asynchronous event flows, and existing implementation patterns in the codebase before design begins, and compiles them into a fact sheet. We established a strict division-of-labor rule: "The designer must not search through the code based on assumptions; it must design solely on the basis of the objective fact sheet submitted by the investigator."

Step 6: The Counterattack of the Logs — Separate the test Pane

The final remaining obstacle was running the full test suite. Every time gradle test was run, thousands of lines of build output and baseline failure logs from other agents that had already been identified flooded the terminal, seriously consuming the main orchestrator's conversation window and Context.

To prevent this, we separated a test Pane (Gemini Flash) dedicated to running the full test suite and determining defects, isolating the heavy log output within the sub-Pane. The Agent running on the Gemini Flash model processed endlessly long test logs all at once at high speed.

Step 7: Ready as Soon as the Session Starts — Completing Hook-Based Automatic Provisioning

The system of 7 specialized Panes was now complete, but manually splitting 7 windows and injecting the respective tools and prompts every time Herdr was started created yet another inconvenience.

We automated this with a script in the session-start hook. Now, as soon as a Herdr session opens, a complete workspace consisting of 1 Main Orchestrator + 7 specialized Specialist Panes, organically arranged, automatically unfolds in one second.

6. 1 Orchestrator + 7 Specialists

Through the gradual separation process described above, the system has now finally converged on a total of 8 Panes: 1 main orchestrator dedicated solely to command and quality gatekeeping, plus 7 specialized subordinate Agent Panes.

Each Pane no longer has a redundant or ambiguous role. In accordance with the single-responsibility principle, each is assigned its own dedicated mission and an LLM engine optimized for it, and operates independently.

The main orchestrator Pane does not read or write code directly. It only delegates tasks to the 7 specialized Panes defined below through clear protocols, then verifies and integrates their results.

Pane Name	Dedicated Mission	Model	Selection Rationale and Core Role
main	Overall pipeline command & gatekeeping	Claude Sonnet	Communicating with the developer, delegating by stage, and controlling Git commits/merges
research	Empirical investigation of codebase facts	Gemini 3.7 Flash	Exploring packages, DB schemas, and call flows with high speed and extensive context
design	Writing architecture and detailed design documents	Claude 3.7 Opus	Writing design documents based on deep reasoning capabilities
design-verify	Adversarial design verification	Gemini 3.7 Flash	Attacking defects and edge cases under the premise that "this design is wrong"
coding	Code implementation and compilation	Gemini 3.7 Flash	High-speed coding with overwhelming speed and adherence to framework conventions
claude-review	First code review (structure/DDD)	Claude Sonnet	Reviewing architecture-layer violations, coupling, transaction boundaries, and business invariants
antigravity-review	Second code review (bugs/stability)	Gemini 3.7 Flash	Reviewing null safety, SQL/N+1 issues, missing exceptions, idempotency, and coding conventions
test	Full test suite regression verification	Gemini 3.7 Flash	Run all Gradle tests

7. End-to-End Multi-Agent Workflow

No matter how many outstanding specialized agents you deploy, without strict and deterministic workflow rules, a multi-agent system can quickly descend into chaos and inefficiency. The key needs for workflows that I have experienced while working with agents are as follows.

1. Preventing the failure of 'laissez-faire autonomy': If you give agents the autonomy to "discuss among yourselves and develop the feature," they may jump into premature coding or waste tokens in endless back-and-forth conversations. A pipeline that enforces clear input and output contracts for each agent is essential.

2. Realizing the 'Shift-Left' principle of software engineering: The later a defect is discovered, the more exponentially the cost of fixing it increases. Eliminating as many defects as possible during the design documentation stage, before coding begins, is the best way to shorten the overall development lead time and eliminate code rollbacks.

3. Deterministic convergence through quality gates: Through strict gatekeeping such as "repeat verification until there are no issues" and "confirm zero test failures," the output always converges to production-level, defect-free quality regardless of the LLM's condition or probabilistic variation.

4. Preserving the cognitive energy of human developers: When the process is clearly defined, developers do not need to intervene anxiously in every detail of the agents' work.

Developers can focus their energy only at the most important control points: "final approval after design verification is complete" and "the final merge."

To achieve this, I arranged seven specialized Agent Panes under the orchestrator agent to operate according to the following workflow. As the workflow operated, the responsibilities among the agents became increasingly clear, and a structure was completed in which every process other than design reviews and final verification—where developer intervention is required—could proceed naturally without developer intervention. Moreover, because developer intervention was reduced in this way, I was able to focus more on important review and verification processes.

8. Four Changes I Experienced After Introducing a Multi-Agent Workflow

In a team-based backend project environment, I was able to experience dramatic changes firsthand by building and applying this workflow to handle the complex feature tickets assigned to me.

First, my mental fatigue and anxiety decreased. In the past, I spent a great deal of energy debugging AI-generated code line by line, worried that hidden bugs might be lurking within hundreds of lines of code. Now, with research, design-verify, and two independent reviewers conducting multistage reviews, developers can devote their full cognitive energy to approving core business designs and making architectural decisions.

Second, large-scale rework decreased because defects were blocked early during the design stage. The waste of discovering domain-modeling errors only after the AI had finished coding and then having to replace the entire codebase disappeared. By filtering out defects in advance during the design stage, implementation could be completed to a high standard without unnecessary trial and error after coding began.

Third, I became able to achieve both speed and quality. Although I handle the ticket alone, I am now contributing to the team's codebase with the highest level of quality—as if a dedicated senior squad had thoroughly completed preliminary research, a detailed Markdown design document, two rounds of cross-review, Korean Javadoc, and full regression testing.

Fourth, automated design documentation and a transparent decision-making history became organizational assets. Unlike in the past, when documentation was omitted due to busy schedules, simply running through the workflow leaves the measured factsheet, domain design document, and adversarial verification feedback intact as files, allowing them to accumulate as the team's permanent knowledge assets.

9. Conclusion: Finding My Own Optimized Multi-Agent Workflow

The 1 Orchestrator + 7 Specialists configuration introduced in this article is my own result, developed through repeated trial and error over approximately two weeks. This configuration is not a 'one-size-fits-all answer' for every developer and every project. In a UI-focused frontend environment, a visual regression testing agent would be central, while an early-stage startup where rapid hypothesis validation is important might be better suited to a lightweight configuration of 2–3 Panes.

What matters is not the number, but the 'principles'.

1. Purity of roles: Do not assign too many roles to a single agent; separate research, design, implementation, and verification to maximize focus.

2. Adversarial cross-validation that breaks self-confirmation bias: Do not blindly trust your own design; have agents with different perspectives attack it for defects.

3. Concise context: Isolate verbose raw logs within individual agents and communicate using only refined outputs.

4. Final control by the developer: Do not delegate every decision to AI; the developer must retain the key control points, such as design approval and final review.

After building a Multi-Agent Workflow, my role evolved into that of an agent leader who directs my own autonomous agent team and gives final approval to quality gates. The true future of AI coding does not lie in relying on an "even larger single prompt," but in directly designing and evolving the most reliable collaboration pipeline for your own project and needs. I hope you will now build an AI autonomous collaboration team tailored precisely to your own technology stack and development environment.

informalife