You split a big task into five kanban cards, five agents start working in parallel, and everyone delivers on time. Then you merge it all and realize the problem: two workers independently invented different answers to the same design question, one file got reshuffled by three cards at once, and nobody reviewed any of it — because “review” was never part of the loop. That is the most painful part of multi-agent collaboration, and it is exactly what a cluster of PRs merged on August 10, 2026 (#83412, #83423, #83424, #83428) fixes: Hermes kanban now has a first-class review lifecycle, plus three guardrails against the chaos. Here is the whole flow — from submitting work for review to getting it bounced back — and the conventions that keep parallel agents honest.

The review loop: implementer → review lane → verdict

Kanban cards now have a proper review phase. When an implementer finishes, they submit via kanban_request_review:

kanban_request_review(
  task_id="T-42",
  summary="Implemented the export feature; verified with 3 sample files",
  reviewer="code-reviewer"    # optional
)

summary is required — it tells the reviewer what was built and how it was verified; reviewer is optional; submitted content is automatically redacted. The card moves into the review lane, where a reviewer profile picks it up and the sdlc-review skill loads automatically. The reviewer gives one of three verdicts:

Verdict	Action	Meaning
Approve	kanban_complete	Acceptance criteria met, task wraps up
Request changes	kanban_comment + kanban_request_changes(reason=...)	Fixable defects remain; card returns to the original implementer
Escalate	kanban_block	A human decision or external prerequisite is needed

Provenance is preserved: if the implementer fixes the card and requests review again without naming a reviewer, it routes back to the same reviewer profile — no random reassignment, continuous review context.

Rotating review lenses: round 1 cold read, round 2 run it, round 3 audit the contract

The sdlc-review skill has a clever design: each round looks at the work through a different lens instead of repeating the same inspection. The round number is the count of prior changes_requested attempts plus one (round 1 = zero bounce-backs, round 2 = one, and so on):

• Round 1 — Artifact: read the diff or deliverable cold, before the implementer’s summary; form an independent judgment, then compare it against the handoff narrative and investigate every mismatch;
• Round 2 — Execution: check the work out and actually run it via terminal — build, test, and exercise the reported behavior yourself instead of re-reading the artifact;
• Round 3+ — Contract: re-read the card’s original task body and acceptance criteria, then audit the deliverable strictly against them, and verify that every item from every prior request_changes round actually landed.

The same principle applies when you fan out ad-hoc parallel reviewers via delegate_task: give each reviewer a different brief (one diff-only, one full-context, one checkout-and-run) rather than identical ones. Identical briefs produce correlated verdicts and duplicate findings; varied lenses cover more defect classes for the same review spend.

Guardrail 1: decision ownership — one owner per question

The classic multi-agent failure mode is “split brain”: two workers independently settle the same design question with different answers. A new decision-ownership contract in KANBAN_GUIDANCE blocks that path directly:

• Design decisions belong to the orchestrator and are made before fan-out;
• No two subtree cards may decide the same question;
• Every child card body must carry the decisions it depends on — because workers cannot see their siblings’ context.

The docs’ example says it perfectly: an exporter card and an importer card must not each “invent” the file format. The orchestrator picks the format first and stamps both card bodies, so the two workers each write to the same contract and nothing clashes at merge time.

Guardrail 2: collision hotspots — flag, don’t pile on

Parallel edits to the same file will collide; the new convention handles it up front. When a worker notices that the file they’re about to touch keeps attracting conflicts from sibling cards, they leave a kanban_comment starting with hotspot: (e.g. hotspot: src/config.py — three cards are editing this file) and surface it in the completion metadata. An orchestrator that sees 2+ flags on one path creates a decomposition card — splitting that hot file out of the queue before dispatching more work that touches it. For conflicts that already happened, the merge-reconciler arbitrates.

The takeaway

Together these changes turn kanban from “dispatch work, collect results” into a full development loop: review, rotating perspectives, decision ownership, and conflict early-warning. The sweet spot is obvious — repositories where multiple agents work in parallel and quality needs a gate; a single agent doing small tasks doesn’t need a workflow this heavy. For the complete kanban command surface, see the hermes-kanban command reference; for more conventions in multi-agent setups, we also wrote about the AGENTS.md directory chain.