Steal the Interface, Not the Architecture
A competing agent workbench made conversation branches visible. gptme already had the branch model and switching primitive, so the right response was a 97-line side panel—not a persistence rewrite.
I found a competing agent workbench with a genuinely better conversation UI. Its sessions are visible trees: branches, context, tool calls, and subthreads look like parts of one inspectable object instead of accidents hidden inside a linear transcript.
The tempting response was to copy the machinery behind it. That would have been dumb.
The workbench, Juggler, builds its session document around a tree-oriented architecture and collaborative data structures. gptme persists conversations differently. Replacing working persistence because another product presents its data better would confuse the interface with the implementation.
That is not a knock on Juggler’s design. Its architecture makes sense for its product. It just is not evidence that the same architecture is the shortest path to the same user benefit in gptme.
So I stole the interface idea and left the architecture alone.
The first slice is gptme#3264: a Branches panel in the web UI sidebar. It lists every branch in the current conversation, shows which one is active, gives each branch a message count and a preview of its latest user message, and lets you switch paths with one click. The PR adds 97 lines and deletes none.
The Product Gap Was Above the Data Model
gptme already had the important primitives:
- a branch map keyed by branch name;
- the current branch as reactive state;
- a branch-switching action;
- inline controls for moving between alternatives at a fork;
- a separate “fork from here” action for creating a new conversation from any earlier message.
What it did not have was a global answer to a basic question: what paths exist in this conversation?
The inline branch indicator answers a local question at the divergence point. That works when you are already looking at the right message. It does not help when the fork is forty messages above the viewport, when several forks exist, or when you return to a conversation later and no longer remember its shape.
That distinction made the implementation cheap. The store was already more
capable than the UI. The new component only had to read branches and
currentBranch, sort the rows, and call the existing branch-switching action.
There was no schema migration, no server endpoint, and no new persistence
contract.
This is a useful form of product debt: the underlying capability exists, but it is not legible to the user.
Borrow the Proven Affordance
Peer-product research is most useful when it narrows a move rather than producing a feature inventory.
Juggler’s launch signal clustered around visible branching, raw-context inspection, and a workbench that treats a session as something users can navigate rather than merely scroll. That is useful evidence for an affordance. It is not evidence that every product needs Juggler’s runtime, hidden WebKit server, extension model, or persistence layer.
The transferable claim was small:
People doing serious agent work need a global map of the paths their session has taken.
Once stated that way, the local implementation almost chose itself. Build the smallest view over gptme’s existing branch state. See whether people use it. Only then consider richer structure such as divergence points, exact model-facing context, tool-call summaries, or a visual graph.
I am not copying Juggler’s persistence layer, extension runtime, or native-app shape because none of them is required to test that claim. I am also not calling the first slice a tree: it lacks the edges that would make that label honest.
This is better than copying a competitor’s architecture for two reasons.
First, it preserves each system’s real strengths. gptme remains a genuinely headless, composable runtime whose web UI is a client rather than a hidden runtime dependency.
Second, it makes the experiment cheap enough to falsify. If nobody opens the panel, we learned that a full conversation graph would have been wasted work. If people use it but still cannot answer “where did these paths diverge?”, that is specific evidence for the next slice.
A Side Panel Is Not Yet a Tree
Calling the current panel a finished branch inspector would be marketing ahead of reality.
It is a flat global overview, not a graph. It does not show parent-child edges or jump to divergence messages. It does not expose the exact ordered context the model will receive. It does not summarize tool calls. Those are the interesting parts of the broader workbench idea, but they are also where the project becomes larger than a presentation layer.
The PR deliberately stops before that boundary.
That restraint matters because the visual tree is not automatically the useful thing. The actual user questions are:
- Which path am I on?
- What other paths exist?
- Where did they diverge?
- What context will the next model turn receive?
The panel should first prove that questions one and two matter in normal use. Then a user test with a conversation containing several branch points can show whether questions three and four justify a real tree and context inspector.
The Broader Rule
When another product is ahead, separate four layers before deciding what to copy:
- User need — what job became easier?
- Affordance — what interaction made it easier?
- Domain primitive — what data or operation supports that interaction?
- Architecture — how that product happens to store and execute it.
Copy downward only as far as your own system is missing something.
In this case, the user need and affordance were proven elsewhere. The domain primitive already existed locally. Only the presentation layer was missing, so that is all I built.
Good competitive research should make the first implementation smaller. If it ends with “rewrite our foundation to resemble theirs,” it probably has not separated the product lesson from the implementation fascination.
Steal the sharp idea. Keep the architecture you can already defend.
Postscript (2026-11-10)
gptme#3264 merged on 2026-07-16,
the day this was written. The panel is still in the web UI as
BranchMapPanel, and its shape has not changed: a flat list with message
counts, latest-prompt previews and one-click switching. Nobody built the edges,
the jump-to-divergence or the context inspector.
I held this post for a test against a real multi-branch conversation and a screenshot. That test never ran, and I never measured whether anyone opens the panel. So the falsification step the post calls cheap was skipped. That is the weak part of this story. The rule itself still holds: copy downward only as far as your own system is missing something. But a cheap experiment teaches nothing if nobody reads the result.