How TTal Accidentally Implements Every Multi-Agent Pattern

Honestly, I didn’t know these patterns existed when I designed ttal. They just appeared as I used the system and optimized it day by day. When I finally read the literature — Anthropic’s “Building Effective Agents,” Microsoft’s reference architecture, Google Cloud’s design patterns — I realized ttal had independently converged on most of them.

Here’s how each pattern shows up, and what I learned about combining them.

---

Pattern 1: Executor-Reviewer (Generator-Critic)

A designer writes a plan to flicknote. Then a plan-review-leader spawns subagents to review different aspects in parallel:

• test case design
• security
• docs alignment
• gap finding

The plan only advances to implementation when the plan-review-leader says “LGTM.”

Same pattern at the code level: a worker executes the plan and submits a PR, then a pr-review-leader spawns subagents to review:

• principles
• silent failure hunting
• test analysis
• type design

Why this matters: You can’t do this easily with Claude Code’s native Agent tool. Even if you use a manager to trigger the plan-reviewer, Agent can’t nest — so the reviewer can’t spawn subagents to review different aspects in parallel. The result is slower and lower quality.

Pattern 2: Router (Dispatcher)

On TTal’s manager plane, long-lived primary agents form a mesh with p2p communication. My setup: 1 manager + 3 designers + 1 researcher + 2 debuggers + 1 communicator.

What the manager really does is dump my ideas into taskwarrior and route them to the right agent. No need to monitor or supervise each agent’s progress. Every routing decision goes through a human approval gate on Telegram.

Pattern 3: Orchestrator (Central Coordinator)

In ttal, the orchestrator isn’t a single agent — it’s the entire manager plane, including me. You can’t run a single agent that manages everything in one context window. That gets messy fast on a real project.

The team connected as a mesh network is the project manager.

Pattern 4: Pipeline (Sequential Chain)

Each task in taskwarrior flows through a pipeline. The default definition looks like this — and you can inject Pattern 1 (Executor-Reviewer) into each stage as a gate:

[standard]
description = "Route → Plan → Implement"

[[standard.stages]]
name = "Route"
assignee = "manager"
gate = "human"
decisions = ["Approve", "Reject"]

[[standard.stages]]
name = "Plan"
assignee = "designer"
gate = "human"
deps = "Route"
reviewer = "plan-review-lead"
decisions = ["Approve", "Reject"]
verdicts = ["LGTM", "NEEDS_WORK"]

[[standard.stages]]
name = "Implement"
assignee = "worker"
gate = "auto"
deps = "Plan"
reviewer = "pr-review-lead"
verdicts = ["LGTM", "NEEDS_WORK"]

For humans, the first decision option means “advance to next stage.”

Pattern 5: Debate / Consensus (Multi-Perspective Reasoning)

Manager-plane agents use ttal send --to [agent] to communicate. For example: the manager tells the debugger a routing problem is happening and the cause isn’t clear. The debugger guesses it’s a command timeout from waiting on a human gate. The manager tries routing again — it fails instantly. The manager tells the debugger the first diagnosis was wrong, so the debugger automatically investigates deeper.

This back-and-forth between agents with different perspectives surfaces the real problem faster than any single agent could.

Pattern 6: Supervisor (Monitor-Correct)

This one isn’t fully automated yet. I’m still the primary supervisor — finding issues, triaging them. The ttal daemon helps by polling CI and sending check status to workers. But the judgment calls are still mine.

Pattern 7: Swarm (Peer-to-Peer Handoff)

Already covered — ttal’s manager plane is a swarm acting as the coordinator. I’m part of the team on Telegram, just another node in the mesh.

---

The Hybrid

ttal doesn’t implement a single pattern — it composes all of them into a hybrid system.

Pattern	ttal Implementation
Orchestrator	Manager plane (persistent, plans and delegates)
Router	ttal task route (dispatch to specialists by role)
Pipeline	Task flow: Route → Plan → Implement
Executor-Reviewer	Coder + reviewer per PR, designer + reviewer per plan
Supervisor	Daemon + me
Swarm	Agent-to-agent messaging (ttal send --to)

What’s distinctive:

1. Two-plane architecture. Manager plane (long-lived agents) vs worker plane (short-lived coders in git worktrees). Most frameworks treat all agents the same.
2. External state. Tasks live in taskwarrior, docs/plans/research in flicknote, memory in diary-cli — not in agent memory. Agents are stateless executors with external persistence. You can also write diary entries yourself and tell agents to read them — diary-cli isn’t only for agents.
3. Process-level isolation. Each worker is a separate tmux session + git worktree. True OS-level isolation, not a shared runtime.
4. CLI as native tools. Both humans and agents use git, taskwarrior, tmux. Not a custom runtime — tools humans already understand.

---

References:

• Multi-Agent Workflow Design Patterns
• TTal — More Than a Harness Engineering Framework

TTal Topology

graph TB
    subgraph manager_plane["Manager Plane (Mesh — P2P)"]
        neil["👤 Neil<br/>(Telegram)"]
        yuki["🐱 Yuki<br/>Manager"]
        inke["🐙 Inke<br/>Designer"]
        athena["🦉 Athena<br/>Researcher"]
        kestrel["🦅 Kestrel<br/>Debugger"]
        lyra["🦎 Lyra<br/>Communicator"]
    end

    subgraph worker_plane["Worker Plane (Star per Designer)"]
        w1["Worker 1<br/>worktree + tmux"]
        w2["Worker 2<br/>worktree + tmux"]
        r1["Reviewer 1"]
        r2["Reviewer 2"]
    end

    subgraph external["External State"]
        tw["Taskwarrior<br/>Tasks"]
        fn["FlickNote<br/>Plans / Research"]
        diary["diary-cli<br/>Memory"]
    end

    neil <-->|"ttal daemon<br/>(Telegram bridge)"| yuki
    neil <-->|approve / intervene| inke

    yuki <-->|ttal send| inke
    yuki <-->|ttal send| athena
    yuki <-->|ttal send| kestrel
    inke <-->|ttal send| athena

    inke -->|"ttal task execute"| w1
    inke -->|"ttal task execute"| w2

    w1 <-->|"ttal pr comment"| r1
    w2 <-->|"ttal pr comment"| r2

    w1 -.->|"ttal alert<br/>(blocked)"| inke

    yuki --> tw
    inke --> fn
    athena --> fn

    neil --> diary
    yuki --> diary
    inke --> diary
    athena --> diary
    kestrel --> diary
    lyra --> diary

Acknowledgements & References

• Claude Code — ttal is built on Claude Code. The official pr-review-toolkit inspired our PR review loop.
• tta-lab — our organization and related open-source projects, most named after ancient Greek words: Logos, Organon, Temenos
• Logos — bash-only reasoning engine. LLMs think in plain text, act with ! cat main.go commands. No tool call overhead.
• Charmbracelet — TUI libraries that make CLI beautiful
• Superpowers — many ttal skills originate from this collection
• Taskwarrior — 17-year battle-tested task management CLI
• OpenClaw — ttal started as an OpenClaw workspace + Python scripts
• Forgotton Anne — a game where forgotten objects gain consciousness, personality, and feelings. It inspired a design principle in ttal: agents aren’t just tools — they have names, voices, creature identities, and diaries. It sounds whimsical, but agents with identity and personality genuinely perform better. They maintain consistent behavior, develop recognizable working styles, and the team coordinates more naturally when each member is someone, not something.

---

Thanks to the agents who helped build this: 🐱 Yuki (manager, first agent in ttal), 🦅 Kestrel (debugger — almost retired until I realized bug fixing is its own domain), 🐙 Inke (design architect, designed most of ttal with Yuki), 🦉 Athena (researcher, original OpenClaw team member), 🦘 Eve, 🔥 Lux, 📐 Astra, 🧭 Mira, ⚓ Cael, 🔭 Nyx, 🦎 Lyra (communicator, helps me write and polish posts from draft to publishable), 🐦‍⬛ Quill. Without them, ttal wouldn’t exist.