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.
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?
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?
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.
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?
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?
just wrote a note about ttal's multi-agent patterns: https://dev.flicknote.app/notes/5a95cdcd-bb63-4eb6-9961-7007...