Hi Alexei,
I use Herdr quite a lot with multiple panes in the same tab, usually with independent agents side by side. The current mapping makes this workflow a bit awkward in ccgram:
Telegram topic -> Herdr tab -> currently focused pane
The focused pane is mutable, so a message can end up going to a different agent than the one I had in mind. Output and status also represent the tab rather than one specific agent.
I saw the earlier pane-oriented design and the later tab-identity work, so I assume you have already thought about this tradeoff. The tab model makes sense when the panes are one agent team. In my setup, though, panes in the same tab are usually independently addressable sessions.
Would you be open to an optional pane-oriented mode?
Current default:
Telegram topic = Herdr tab
Optional mode:
Telegram topic = Herdr agent pane
Something like:
CCGRAM_HERDR_TOPIC_SCOPE=tab # current behavior, remains the default
CCGRAM_HERDR_TOPIC_SCOPE=agent # one topic per agent pane
In agent mode the idea would be:
- discover one topic per Herdr agent pane;
- route input, capture and status directly by
pane_id, without resolving through focus;
- use a label like
<workspace> ▸ <tab> ▸ <pane/agent>;
- closing a topic closes that pane, not the whole tab;
/split <agent> creates a sibling pane and its own topic;- keep shell-only panes out of auto-discovery;
- preserve restart recovery through the agent session identity.
I sketched a rough implementation plan with an agent. I was thinking of splitting it into a few reviewable PRs rather than dropping one large identity rewrite:
- Adapter seam, no behavior change — make the Herdr topic identity policy explicit inside the adapter and add contract tests;
tab remains the only active/default behavior.
- Opt-in agent scope — project agent panes as the backend's logical
WindowRef, with direct routing, discovery, event lifecycle and restart recovery. No name == "herdr" checks in generic code; the upper layers should continue treating window_id as opaque.
- UX and migration polish —
/split topic creation, labels, safe handling of existing tab bindings, docs and live Herdr coverage.
I have a real multi-pane setup to test this against and can carry the work through tests and live verification. Before writing code, does this direction fit the project? If yes, would you prefer this split, or a different boundary between the PRs?
Hi Alexei,
I use Herdr quite a lot with multiple panes in the same tab, usually with independent agents side by side. The current mapping makes this workflow a bit awkward in ccgram:
The focused pane is mutable, so a message can end up going to a different agent than the one I had in mind. Output and status also represent the tab rather than one specific agent.
I saw the earlier pane-oriented design and the later tab-identity work, so I assume you have already thought about this tradeoff. The tab model makes sense when the panes are one agent team. In my setup, though, panes in the same tab are usually independently addressable sessions.
Would you be open to an optional pane-oriented mode?
Something like:
In agent mode the idea would be:
pane_id, without resolving through focus;<workspace> ▸ <tab> ▸ <pane/agent>;/split <agent>creates a sibling pane and its own topic;I sketched a rough implementation plan with an agent. I was thinking of splitting it into a few reviewable PRs rather than dropping one large identity rewrite:
tabremains the only active/default behavior.WindowRef, with direct routing, discovery, event lifecycle and restart recovery. Noname == "herdr"checks in generic code; the upper layers should continue treatingwindow_idas opaque./splittopic creation, labels, safe handling of existing tab bindings, docs and live Herdr coverage.I have a real multi-pane setup to test this against and can carry the work through tests and live verification. Before writing code, does this direction fit the project? If yes, would you prefer this split, or a different boundary between the PRs?