15:I[981,["658","static/chunks/658-a698693f56d0116a.js","183","static/chunks/183-6beeeb801c274aaa.js","474","static/chunks/app/%5Btype%5D/layout-e8e83705b5c8d3b7.js"],"Posts"] 16:T728,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.17:T482,The idea started with on

Spectre (1977) [video]