TTal – CLI that turns Claude Code into a multi-agent software factory

6 points by neilbb 106 days ago | 4 comments

I built TTal because I got tired of babysitting Claude Code sessions. Every PR meant switching between windows, copy-pasting review feedback, telling the coder what to fix, and repeating until it merged. I wanted to manage all of this from my phone while doing other things.

TTal is a Go CLI that orchestrates multiple Claude Code sessions in a two-plane architecture:

Manager plane — long-running agents that persist across sessions. They draft plans, break them into tasks, assign priorities, and unblock workers when they get stuck. You manage them from Telegram.

Worker plane — short-lived agents spawned per task. Each gets an isolated git worktree + tmux session. They implement, review, triage feedback, and merge — the full PR loop runs autonomously with CI logs fed back in. When done, everything auto-cleans up.

Agents, workers, and humans all communicate through a p2p message bridge — any agent can message any other agent or the human directly.

The other problem I had: I needed dedicated, long-lived Claude Code agents for planning and research — not just throwaway coding sessions. TTal's manager plane gives me that. My orchestrator agent drafts plans, my researcher explores codebases, and workers just execute.

The stack is intentionally composable — taskwarrior for task management, flicknote or use plain markdown for knowledge/memory, Telegram as the human-in-the-loop interface. Everything talks via CLI, no SDK required.

  brew tap tta-lab/ttal
  brew install ttal

GitHub: https://github.com/tta-lab/ttal-cli

I also built a bash-only subagent runtime with zero tool call overhead: https://github.com/tta-lab/logos

Happy to answer questions about the architecture or multi-agent workflows in general.

parsak 105 days ago |

the two-plane idea here is really interesting -- separating long-lived planners from short-lived workers is a clean mental model.

curious what happens when you're on windows though? tmux + ttal means you're locked out of a decent chunk of potential users.

been building in this space too -- pane (github.com/Dcouple-Inc/Pane) takes a different approach, standalone desktop app, no tmux at all. each pane maps to one worktree + n terminals, agents spin up and tear down cleanly. works the same on windows, mac, linux.

the telegram interface for managing from your phone is a nice touch -- does it block if the manager agent gets stuck waiting for human input?

neilbb 105 days ago | |

1. Windows users would need WSL. Currently focusing on macOS and Linux.

2. The manager never blocks. She helps me dump tasks into taskwarrior and route them. Since the manager plane is a mesh with p2p communication, no single agent becomes a bottleneck. Each designer connects to 1 or more workers in a star topology, and when workers get blocked, they alert the designer directly rather than waiting.

3. Pane looks interesting. How are you embedding the terminal into the desktop app? Is it a PTY wrapper or something like xterm.js?

neilbb 105 days ago | | |

just wrote a note about ttal's multi-agent patterns: https://dev.flicknote.app/notes/5a95cdcd-bb63-4eb6-9961-7007...

maxbeech 102 days ago |

nice architecture -- the two-plane model is something i've been thinking about too, from a slightly different angle.

i built something for this actually (openhelm.ai) -- the problem i was solving is less about orchestrating active PR loops and more about scheduling claude code jobs to run unattended on a cron-like schedule. user describes a high-level goal, it gets planned into a set of tasks with a next_fire_at, and those run autonomously in the background even when they're not at their desk.

the piece i found hardest: deciding what requires human approval vs what can auto-proceed. we landed on "no plan runs without user sign-off" as a hard rule, but even within an approved plan, mid-job blockers that need human input are more common than you'd expect.

curious how TTal handles tasks that get legitimately stuck mid-execution -- does the manager agent have heuristics for detecting "stuck vs slow"? the watchdog timeout approach (we sigterm after 30 min) is blunt but works.