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?

the way i handle it in pane: every pane is one worktree, and the diff viewer + keyboard shortcuts (squash, rebase, merge) are right there before you ever push. so the review step isn't a context switch -- it's just... the next thing in the same window

the harder problem you're pointing at is agent-to-agent coordination. i don't try to solve that at the orchestration layer. i keep it simple: one agent per feature, and they don't touch each other's worktrees. when feature A needs something from feature B, i merge feature B first. boring, but it doesn't blow up

the ADR / architectural governance point from agilevibecoding.org is interesting though -- have you seen teams actually ship something like that in practice? or is it mostly theoretical at this scale?

i built this because i was running claude code and cursor on the same repo and they kept overwriting each other's files -- that sentence is exactly what motivated pane too.

git-lanes solves the isolation problem cleanly as a CLI layer. pane approaches it from the other direction -- the worktree isolation is baked into the UI model itself (one pane = one worktree), so there's nothing to run or remember. you just open pane, create a pane for your feature, and the worktree exists.

curious if you considered going the desktop app direction or if the CLI-only scope was intentional? there's something appealing about a zero-dependency shell tool.

github.com/Dcouple-Inc/Pane -- fully open source (agpl-3.0) if you want to compare approaches.

the "containers manually vs compose" framing is exactly right -- that's the coordination layer that's missing from raw worktrees.

one thing i'm curious about with chatml: how's the experience on windows and linux? you mentioned it's running but with bugs. i built pane specifically because conductor and most of the other tools in this space were mac-first (or mac-only), and a huge chunk of the multi-agent dev community is on windows or linux.

pane is the same app, same shortcuts, same UI across all three. not "cross-platform eventually" -- ships to all three now. built on xterm.js (same engine as vs code) so terminal compatibility isn't a thing you have to debug.

if anyone on windows or linux is hitting walls with chatml or conductor, pane might be worth a look: github.com/Dcouple-Inc/Pane

the persistent markdown approach to context drift is clever - treating state files as a first-class primitive rather than hoping the agent remembers between sessions is the right instinct.

one thing i've noticed: even with perfect context files, multi-agent setups still hit the physical isolation problem - multiple agents in the same working directory stepping on each other's files mid-session. the context drift and the file conflict problem are separate issues that both need solving.

i've been working on the isolation layer: pane gives each agent its own git worktree (isolated filesystem per feature) so context drift from file collisions is removed entirely. fully open source (agpl-3.0): github.com/Dcouple-Inc/Pane - the two approaches actually complement each other pretty cleanly.

the "45 minutes watching one agent" framing is exactly right - the serial bottleneck is the real problem, not the model.

one thing worth thinking through as shard matures: the management layer for those parallel agents running in worktrees. decomposition and dispatch is one side; the human staying oriented across 4 concurrent sessions - seeing what each is doing, switching between them, reviewing diffs inline, handling the merge step without context switching overhead - is the other.

i built pane for that layer specifically. fully open source (agpl-3.0), works with any cli agent. curious how you're handling the merge step when tasks in the dag have soft dependencies - like when two tasks touch overlapping files but aren't explicitly linked: github.com/Dcouple-Inc/Pane

Oh, arguably the best part (which I forgot to mention) is that our terminals continue running in the cloud, so dev work isn't blocked by our computers going to sleep.