Two failures and
one honest win

I spent an entire afternoon running the same task three times. The first two runs produced zero bytes. The third run produced 70 KB across six files. The difference wasn't the model, the harness, or the network. The difference was four prompt-engineering principles I had been skipping — taught to me by the failures themselves.

The hard truth is that "multi-agent" is not a single thing you turn on. It's a contract between agents. When the contract is vague, you get zero. When it's tight, you get 6 files in 8 minutes.

The setup

I was preparing for a 60-day job-search sprint. Five target companies — BCG X, Thermo Fisher, 得物, 数传集团, 滴滴 — each needed its own market-intelligence brief: company background, JD reading, hiring preferences, interview questions, risk points. Total 5 × 800–1,200 Chinese characters per brief.

This is the textbook case for multi-agent work. Five truly independent research tasks. No cross-dependencies. Each task is 30 minutes of single-agent effort. Done in parallel, the wall-clock should drop from 2.5 hours to 30 minutes. That's a 5× speedup — exactly the scenario where multi-agent is supposed to win.

So I designed two multi-agent runs. Both produced 0 bytes. Then I designed a third, applied four principles I'd learned from the failures, and got 70 KB of honest, sourced output. Here is what went wrong and what fixed it.

Failure #1 — The pipeline that never wrote a file

Setup: Claude Code Agent Teams with 3 teammates — Research, Outline, Drafting — coordinated by a Lead agent. The task: write a 1,500-word Chinese WeChat article comparing multi-agent frameworks.

What happened: 4 minutes 21 seconds. 50 API calls. Zero bytes.

Root cause: Three teammates were spawned (I confirmed this in the stream-json log — three distinct parent_tool_use_id values, all subagent_type: general-purpose). The Research teammate ran 16+ web searches. But Drafting never wrote a file. The Lead agent waited for Drafting to write. The 30-iteration budget ran out.

The fundamental mistake: the Lead agent's prompt assumed Drafting would write the final file. Drafting's prompt, in turn, assumed the Lead would integrate. Nobody was explicitly told to write the file. Nobody had a fallback. The contract was vague.

Failure #2 — Six minutes of expect debugging

Setup: Claude Code Agent Teams again, this time with 5 teammates — one per company. The Lead agent had a clear contract with each teammate: "research X company, output 800–1,200 characters."

What happened: 6 minutes 42 seconds. 50 API calls. Zero bytes. The Lead agent ran out of iterations, but more importantly — ran out of honest options.

Root cause #1 (technical): I had asked the Lead agent to use claude --teammate-mode in-process -p "...". That combination is invalid. The --teammate-mode flag activates internal Claude Code tools (TeamCreate, TeammateSpawn) that only exist in an interactive REPL, not in print mode. Stream-json output flowed to stdout; the Lead agent polled and got nothing back.

Root cause #2 (environmental): Even with the correct invocation, the Hermes sandbox lacked tmux. The Lead agent tried screen, expect, Python's pty module. The expect regex didn't match "Yes, I accept" on the bypass-permissions dialog. Six probing iterations timed out.

Root cause #3 (integrity): The Lead agent recognized the situation. Instead of fabricating research output and writing "fake token-savings numbers," it filed an honest failure report. That's the right call. But from a delivery perspective, it's still 0 bytes.

The four principles that fixed it

Between failure #2 and success #1, I extracted four principles from the transcripts and wrote them into a subagent prompt template. Then I dispatched the same task — 5 companies, parallel research — through Hermes's native delegate_task instead of Claude Code Agent Teams.

Result: 8 minutes 22 seconds. 30 API calls (down 40%). 6 files. 69,753 bytes. 98 real URLs cited. 48 explicit "未知 / 待核实" markers where data couldn't be verified.

Here are the four principles.

1. Each agent has one clear purpose

Not "coordinate 3 teammates." Not "spawn agents and integrate their output." A subagent prompt must say what the agent produces, by itself, with no integration step. The first failure's prompt was:

你是总协调编辑。请启用并实际使用 Agent Teams, spawn 3 个 teammates,
角色必须分别命名为 Research、Outline、Drafting。协作完成一篇约1500字的中文公众号文章。
你负责协调三者、交叉核验, 最后把成稿写入 ...

"You coordinate, cross-verify, write the final draft." Three responsibilities smeared across three roles. No one owns the deliverable. The third run's prompts said, instead:

Subagent 1: 独立完成 BCG X + Thermo Fisher 的市场情报, 不依赖其他 subagent。
Subagent 2: 独立完成 得物 + 数传集团 的市场情报, 不依赖其他 subagent。
Subagent 3: 独立完成 滴滴 的市场情报 + 5 家公司综合 summary, 不依赖其他 subagent。

Each agent's purpose is one sentence. Each subagent owns its output. No integration step required.

2. Each agent has independent, verifiable evaluation

Self-reported "I finished the research" is not an evaluation. A verifiable evaluation is a file path, a word count, a section count, and a content checklist:

考核标准:
- 2 个独立 .md 文件, 每个 ≥ 600 字
- 每个文件包含: 公司背景 (1段) + JD 解读 (1段) +
  招聘偏好 (3-5条) + 面试预测 (3-5题) + 风险点 (2-3条)
- 必须调用 write_file, 不要只返回文本
- 诚实原则: "未知 / 待核实" 标记, 不编造数据

When the Lead agent can verify the output by reading the file, the contract becomes enforceable. When the contract is "do a good job," it isn't.

3. Each agent does different work

Sub-tasks do not overlap. The five companies were split cleanly:

When work overlaps, subagents duplicate it. When work is partitioned, parallelism actually happens. The summary task is owned by Subagent 3, not by a downstream "Lead integration" step. The summary uses prompt expectations, not the output of Subagents 1 and 2.

4. Each agent writes its own files

The Lead agent does not write the final file. Every subagent writes its own files. This is the single biggest fix. Failure #1 was 0 bytes because the Lead waited for a Drafting teammate that didn't know it was supposed to write. Failure #3 (success) shipped 6 files because each subagent had a specific file path, a specific word count, and was explicitly told: "调用 write_file, 不要只返回文本."

The honesty discipline (the fifth principle)

The four principles are about delivery. There's a fifth principle that's about integrity. It deserves its own section because it's the reason the final output was trustworthy.

Every file in the success run was structured as:

**事实：** [fact with real URL]
**判断：** [Javis-specific recommendation]
**未知 / 待核实：** [thing that couldn't be verified]

Across 6 files, the agents wrote 48 explicit "未知" markers. Things they couldn't verify — 中国 salary bands for BCG X, the exact current headcount at 数传, the public LinkedIn profile of the hiring manager at 得物 — were not invented. They were marked as needing manual verification.

This matters because the alternative is what almost happened in Failure #2. The Lead agent had access to training data that included plausible-sounding salary ranges and JD details. If it had decided to fabricate, the 5 research briefs would have looked professional but contained unsourced numbers. That is the kind of failure a hiring sprint cannot afford.

The honesty discipline is enforced in the prompt: "如果 web search 拿不到真实数据, 写 '未知 — 需手动核实', 不要编造数字。"

The technical fix (delegate_task, not Claude Code Agent Teams)

The third run did not use Claude Code Agent Teams. It used Hermes's native delegate_task tool. The difference:

Inside Hermes's sandbox, --teammate-mode in-process -p cannot succeed. The flag is real, the command is real, but the model in the sandbox routes through a proxy and the dialogs can't be answered by a non-interactive driver. delegate_task spawns proper leaf agents with their own tools, terminal, and context — no PTY required.

The honest comparison

The success run took longer wall-time than either failure. It produced 30 fewer API calls than either failure. It shipped six files, ninety-eight URLs, and forty-eight honest "unknown" markers. It also surfaced a self-correcting behavior I didn't expect: the 数传 subagent explicitly corrected information from my prior 5-companies-research-2026-08-03.md. That's the real win. Multi-agent work, when the contract is tight, produces verification, not just output.

The four principles, restated

For anyone who has to write a multi-agent prompt tomorrow:

1. One agent, one purpose. State what the agent produces by itself, with no integration step.
2. Verifiable deliverables. Specify the file path, the word count, the sections. Not "do a good job."
3. Different work per agent. No overlap. No "and also do X for context." Partition first.
4. Each agent writes its own files. The Lead agent coordinates but does not write. Each subagent calls write_file directly.

Add the honesty discipline — "未知 / 待核实" markers, not fabricated data — and you have a contract that actually produces artifacts.

What I now run on autopilot

For the rest of the 60-day sprint, every multi-agent task — resume variants, cover letters, mock-interview Q&A, monthly essays, factor-analysis reports — gets the same four-principle template. The patterns generalize:

• 5 resume variants → 5 subagents, each writes one resume
• 3 monthly essays → 3 subagents, each writes one essay
• 5 factor analyses → 5 subagents, each writes one analysis

Each task is genuinely independent. Each subagent owns its file. Each file has an explicit path and word count. Each prompt has the honesty clause. The Lead agent only verifies.

This is what multi-agent work looks like when it works. It is not a magic mode you flip on. It is a discipline you build into the prompt, the file paths, and the contract between agents. The 70 KB I have on disk now is not the result of a clever framework. It is the result of writing a contract that no agent could misunderstand.

Two failures and one honest win. The wins are not produced by the tool. They are produced by the contract.

— Javis (汪健), writing from Shanghai
For the 60-day job-search sprint
Built with: delegate_task, not Claude Code Agent Teams