The Adventuring Party: Multi-Agent Orchestration với tmux — Từ Sub-agents đến AI Team thực sự

Hành trình từ frustration đến kiến trúc

Alex Ivison bắt đầu với một vấn đề đơn giản: code review của một AI agent thường bỏ sót bugs mà một AI agent khác có thể catch. Giải pháp tự nhiên — dùng hai AI — nhưng kết nối chúng với nhau lại phức tạp hơn nhiều so với tưởng tượng ban đầu. Hành trình của anh qua 3 giai đoạn từ tháng 1 đến tháng 3/2026 là bài học quý giá cho bất kỳ ai muốn xây dựng multi-agent system nghiêm túc.

Giai đoạn 1: Sub-Agents (Tháng 1/2026) — Vấn đề communication

Approach đầu tiên: dùng Claude's sub-agents làm messenger giữa Claude và Codex (GPT-5.3/5.4). Về mặt lý thuyết elegant — một agent orchestrate, agent khác execute.

Thực tế: sub-agents thêm một layer communication không đáng tin cậy. Messages bị misinterpret, context bị mất khi pass qua intermediary. Agent "nói chuyện về" work thay vì thực sự làm work.

Giai đoạn 2: Direct CLI Integration (Tháng 2/2026) — Vấn đề synchronization

Giải pháp: loại bỏ intermediaries, để Claude gọi thẳng Codex qua Bash. Tốt hơn — nhưng nảy sinh vấn đề mới: synchronous bottlenecks. Claude phải đợi Codex respond trước khi tiếp tục. Pipeline trở thành sequential thay vì parallel.

Giai đoạn 3: tmux-Based Transport (Tháng 2-3/2026) — Breakthrough

Insight quan trọng: đặt agents trong neighboring tmux panes cho phép bidirectional, persistent communication với shared context — và quan trọng hơn, cho phép asynchronous operation.

Hai agents có thể làm việc đồng thời trong cùng terminal environment, giao tiếp qua tmux messaging, mà không cần đợi nhau. Đây là breakthrough thực sự.

Kiến trúc "Adventuring Party" — tên không phải ngẫu nhiên

Alex đặt tên system theo D&D party của mình — mỗi "nhân vật" có role và strength riêng:

Party Session: 3 tmux panes

• Codex pane: Reviewer — GPT-5.3/5.4, xuất sắc trong việc catch implementation bugs
• Claude pane: Implementor — tạo ra code, architecture
• Shell pane: Test execution, build verification, evidence collection

Master Session Orchestrator

Spawn và monitor nhiều "party sessions" cho batch task processing. Một orchestrator quản lý nhiều parties làm việc song song trên different features.

Custom TUI Tracker

Built với Bubble Tea (Go framework) — real-time progress monitoring dashboard hiển thị trạng thái tất cả agents và tasks.

Evidence System: Không ai tự approve work của mình

Insight sâu sắc nhất của hệ thống: agents không thể self-approve. Alex build evidence system với JSONL logging tied to diff-hashes:

• Mỗi task phải có documented evidence trước khi được approve
• Evidence được tie vào specific code diff hash — không thể dùng lại evidence cũ
• PRs bị reject tự động nếu thiếu verification documentation

"Separate your implementor from your reviewer, make agents prove their work with evidence, and never let anything self-approve." — Alex Ivison

Pipeline 5 gates của mỗi task

1. Scope verification: Đối chiếu với requirements — agent có làm đúng những gì được yêu cầu không?
2. RED/GREEN testing: Failing tests trước (RED), sau đó implementation (GREEN)
3. Sub-agent critics: Code correctness check + bloat detection từ specialized critics
4. Deep multi-model review: Codex + Opus cùng review — hai models, hai perspectives
5. Evidence gate: Reject incomplete documentation — không có evidence = không có merge

Dispute Resolution tự động

Khi Claude và Codex disagree về approach, system có automatic debate mechanism:

• Cả hai agents trình bày argument của mình
• Orchestrator tổng hợp reasoning
• Decision được log với rationale rõ ràng

Không cần human intervention cho mọi disagreement nhỏ — chỉ flag lên khi cả hai agents đều uncertain cao.

Cross-model advantage: Tại sao cần cả Claude và Codex?

Testing thực tế của Alex xác nhận: reviewers catch implementation bugs mà implementors miss. Nhưng quan trọng hơn — các models khác nhau miss những bugs khác nhau.

Claude thường mạnh hơn về architecture và long-context reasoning. Codex thường tốt hơn về catching specific implementation bugs. Kết hợp hai = coverage rộng hơn nhiều so với một model review hai lần.

Tech Stack và Tools

• tmux: Inter-agent communication backbone
• Go: Testable, type-safe orchestration logic (thay thế Bash scripts)
• Bubble Tea: TUI development framework cho monitoring dashboard
• Custom skills: Enable natural agent-to-agent messaging
• GitHub: github.com/alexivison/ai-config

Bài học thực tế

1. Agents hiểu tmux một cách tự nhiên

Không cần viết special skills để dạy agents cách dùng tmux — chúng hiểu terminal environment đủ tốt để navigate và communicate qua tmux naturally.

2. Terminal familiarity có giá trị cao

Developer quen với terminal environment sẽ build agent systems tốt hơn nhiều. Investment vào learning tmux, shell scripting pays dividends khi xây orchestration.

3. Abstraction layers mỏng tốt hơn dày

Alex deliberately tránh thick abstraction layers vì "existing AI tools change fast enough that anything with a thick layer will lag behind on features." Bash script + tmux = maintainable. SDK wrapper on top of SDK on top of SDK = tech debt.

Khi nào áp dụng kiến trúc này?

Kiến trúc Adventuring Party phù hợp với:

• Projects có quality requirements cao — code đi vào production, không phải prototype
• Teams muốn automate code review hoàn toàn
• Use cases cần dual-model validation
• Developers thoải mái với terminal và Go/Bash

Không phù hợp với:

• Quick prototypes và exploration
• Teams chưa quen với terminal tools
• Projects nhỏ — overhead không justify

So sánh với Claude Code Agent Teams chính thức

Kiến trúc của Alex predates và complements Claude Code Agent Teams chính thức của Anthropic. Điểm khác biệt:

• Alex's approach: cross-model (Claude + Codex), custom evidence system, Go orchestration
• Official Agent Teams: single-model (Claude only), built-in task management, simpler setup

Cả hai có use cases riêng. Official Agent Teams tốt cho speed và simplicity. Alex's approach tốt hơn khi cần dual-model review và rigorous evidence tracking.

Tổng kết

The Adventuring Party là ví dụ tốt nhất về DIY multi-agent orchestration trong năm 2026. Không phải vì technology phức tạp — mà vì design principles rõ ràng: tách implementor khỏi reviewer, require evidence cho mọi approval, và dùng minimal tooling thay vì thick abstractions.

Nguồn tham khảo

• The Adventuring Party: Multi-Agent Orchestration với tmux — Alex Ivison (DEV Community)
• GitHub Repository: alexivison/ai-config