HN Explorer

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

6 points by neilbb ↗ HN
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.

3 comments

[ 5.3 ms ] story [ 18.0 ms ] thread
parsak
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?

maxbeech
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.