Agent interfaces are young enough that their default shape is still an accident. Using familiar landmarks, cars have had about 140 years since the Benz Patent-Motorwagen; graphical personal computing has had 53 since the Xerox Alto, the Web 37 since Tim Berners-Lee’s first proposal, and touch-first mobile interfaces 19 since the first iPhone.
Interfaces for agents that use tools, write code, and manage other agents are younger still. We handed them a chat box because it was available, not because several generations of designers tested every alternative and declared the rectangle victorious.
Ernie began inside that gap. It is a desktop interface for Prime Agent, a runtime that can recursively reorganize its work while the window around it remains mostly fixed.
The recursive part matters. A Recursive Language Model, or RLM, does not have to hold the whole problem inside one model call. It can use code to inspect and divide the available context, call models on smaller pieces, then recursively repeat the process when a subproblem is still too large. The model can express and carry out the decomposition itself instead of following a workflow chosen entirely in advance by the application.
Prime Agent gives an agent this kind of working environment: tools, code execution, artifacts, and other agents it can delegate to. Ernie still has to present the resulting work through a familiar shell.
What exists today is narrower but real. Ernie connects to Prime Agent’s daemon, keeps sessions attached to repositories and Git worktrees, exposes typed UI capabilities to agents, and hosts lifecycle-managed plugins. On Aug 16, 2026, it shipped its first Apple silicon alpha. The build is private and ad-hoc signed while the project is experimental; public distribution still needs Developer ID signing and Apple notarization. The task-shaped interface described below is the next experiment, not a finished feature.
Meet Ernie
A macOS interface for durable Prime Agent work.
- v0.1.0
- Apple silicon
- Private alpha
That produced a question: if the RLM can change the shape of the work, why can’t it change the shape of the interface?
I want Ernie to become an RLM-able interface: one the agent can treat as part of its recursive decomposition, not merely a screen it can remote-control. The interface itself should become a trusted language the agent can use while organizing the work.
If the task becomes coding, the interface should bring out the worktree, diff, terminal, tests, and review state. If it becomes research, it should bring out the notebook, sources, graphs, datasets, and experiment runs. The useful objects are different because the work is different.
Instead, we tend to pour both jobs into a transcript and ask the rectangle to remain optimistic.
I call the alternative jellyware: software whose interface waits to see what the work becomes before settling into shape. It is not an interface that squirms continuously or lets a model improvise arbitrary pixels. The jelly is in the composition. The shell can stay stable while the surfaces inside it form around the task.
This idea was hiding inside a feature Ernie already had. Ernie exposes a UI CLI. An agent can inspect a live, versioned capability manifest, then issue typed commands to focus the window, choose a light or dark theme, show or hide the sidebar, and set its width within a declared range.
The agent is not clicking coordinates and hoping the application feels cooperative. It speaks a small, explicit language for changing the surface.
That is interface control, not yet interface orchestration. The available nouns and verbs remain written by the host: window, theme, sidebar; focus, show, hide, resize. Jellyware asks for a larger but still trusted language, one in which task decomposition can select and compose useful surfaces rather than merely operate controls decided in advance.
The chat box is opinionated
A chat box looks neutral because it accepts almost any request. It is not neutral. It assumes that work begins with a message and ends with a response. Branches, files, tests, experiments, failures, and child agents must return as text before the interface knows what to do with them.
The model may have changed. The interface is still waiting for the answer.
This connects to a live argument in agent research. A scaffold is the software around model calls: the machinery that decides how a task is decomposed, which tools run, what gets observed, and whether the process continues. RLMs widen that decomposition language instead of leaving every strategy frozen inside the scaffold.
The Mismanaged Geniuses Hypothesis proposes that some limits we attribute to models may instead come from the systems managing them. One result in that work makes the narrower point vividly. On MRCRv2, a synthetic long-context retrieval benchmark, RLM(Qwen3-4B-Instruct) performed near 0% at one million tokens with eight hidden “needles.” After its recursive policy was trained on a much easier setting—32,000 tokens with one needle—it reached 100% on the larger eight-needle setting. This does not turn the base model into a universal genius. It shows that a learned decomposition policy can generalize from an easier retrieval problem to a much larger one.
MGH is about composing model calls, not interfaces. The extension is mine: if decomposition changes what an agent can accomplish, perhaps the visible environment should preserve and participate in that decomposition. A research subtask that creates a source set, notebook, and graph should not have to melt back into prose before the person can work with it. The interface could retain the structure the agent discovered.
The workbench has been loosening
The boundary has been moving for years. Neovim made the workbench programmable, Herdr made terminal panes agent-aware, and bb lets agents extend an IDE through threads, worktrees, panels, commands, and plugins. Mitchell Hashimoto’s announced direction with Superlogical pushes toward durable sessions that outlive any one local window.
These systems move different boundaries: programmability, agent awareness, self-extension, and session durability. Jellyware asks the remaining question: can the task decomposition itself determine why a trusted surface exists, what makes it valid, and when it should leave?
Cordis gives composition a where and a when
If decomposition should remain visible at the interface, the runtime underneath it must also be compositional.
This is why I am happy DeepSeek Harness exists. In its current developer preview, DeepSeek describes models, tools, skills, sessions, sandboxes, storage, loops, scheduling, and even the UI as plugins in a shared runtime. The point is larger than its feature list: the harness does not have to be one sacred loop with accessories bolted around it. It can be assembled from capabilities.
DeepSeek Harness shows what Cordis can look like inside an agent system. Cordis gives software a way to ask three useful questions: what capabilities are available here, how long is this arrangement valid, and who owns the consequences when it ends?
The details involve contexts, fibers, and effects. The larger idea is simpler. A component should appear only where its requirements are satisfied, remain only while that situation is valid, and clean up what it changed when it leaves. Jellyware needs exactly that discipline. A task-shaped notebook, diff, or browser is useful only if the host also knows why it exists and when it should disappear.
Cordis cannot make a dishonest cleanup function honest or recover an effect nobody registered. It provides the structure for ownership; people still have to use it correctly. DeepSeek Harness does not yet prove recursively composed task interfaces either. Together, they show that the runtime underneath such an interface does not have to be a monolith.
Ernie had already found part of the problem
Ernie had already reached part of this lifecycle problem before I encountered Cordis through its announcement. Ernie did not begin as a Cordis implementation, and it still is not one. Cordis showed me that a local bug belonged to a much larger design problem.
Ernie’s plugin host already treated interface contributions as a transaction: commands and views became visible only after activation succeeded. But that transaction covered publication, not every resource acquired along the way. If a plugin acquired a native resource and failed later in activation, it could exit before returning the final cleanup that owned the resource. From the interface, the plugin would never have arrived. In the host process, its resource could remain very much among us.
The lesson was not specific to browsers. A temporary interface can disappear cleanly while leaving its consequences behind.
Ernie now pairs each successful acquisition with its cleanup immediately through an EffectScope. If activation fails halfway through, everything acquired so far still gets a chance to leave. The mechanism matters, but the larger shift matters more: interface pieces are not merely pixels to mount. They have owners, dependencies, and lifetimes.
Ernie’s API v3 plugin host also activates providers before consumers, reverses that order during teardown, and restores demanded consumers when providers return. It still does not implement Cordis’s broader context model.
Those are still only Ernie’s first steps. Today its UI CLI can focus a window and resize a sidebar. The ambition is an RLM-able interface that can bring forward a trusted diff, notebook, dataset, or browser because the task needs it, connect that surface to the capabilities that make it useful, and release it when the context ends. The workbench becomes part of the recursive program rather than a remote-controlled backdrop.
The medium is still unfinished
Capability is only half the design problem. A workbench that can change shape still needs judgment about which shape to take.
The useful interface may become clear only after the task’s objects and relationships become visible. That does not mean every dataset wants to become a rotating donut. It means the fixed screen is one answer, not a law of nature.
Charles Eames gives the experiment a necessary constraint. Eames, the American designer, architect, and filmmaker who worked with Ray Eames, described design as arranging elements toward a purpose and as a method of action within limits. The designer’s skill lies partly in recognizing the constraints.
Jellyware acquires an impressive pile of them: attention, permission, accessibility, latency, screen space, resource cost, reversibility, and lifetime. A surface may be available but distracting. It may fit the task and fail the person using a screen reader. It may be useful for thirty seconds and expensive for thirty minutes. Malleability does not remove design judgment. It gives judgment more moments in which to fail.
Wilson Miner supplies the heavier reason to care. As digital tools become part of where people live and work, interface decisions shape more than a session. They make some actions easy, teach habits, preserve or hide evidence, and set expectations about how work should proceed. We shape tools, then continue living inside the behavior they encourage.
Toolmakers have a convenient way to shrink that responsibility: I only make Electron apps. The sentence sounds modest. It can also hide the scale of what tools become. Cars began as vehicles and helped reshape cities around roads, parking, and distance. Screens began as displays and helped shape the internet around pages, tabs, feeds, and notifications. A tool can outgrow the job description of the person who made it.
An RLM-able interface will make some evidence prominent and other evidence easy to miss. It will make some actions feel natural, decide what counts as finished, and teach people what deserves attention. Those are design decisions even when a model selects the panel and the panel lasts thirty seconds.
That responsibility does not evaporate because a surface is temporary or an agent requested it. A generated research view can privilege one source. A coding surface can make shipping easier than reviewing. A disappearing task panel can leave behind files, processes, permissions, or learned habits. If an agent composes the workbench, the host remains responsible for what may appear, what may persist, and how it leaves.
This is where Cordis’s rather technical concern with effect ownership becomes a design ethic. Temporary form still needs accountable consequences.
The interface should follow the work
I want Ernie to become a place where the task can bring its own working shape without gaining permission to redecorate the universe.
A coder should meet the diff, worktree, terminal, tests, and review state created by the work at hand. A researcher should meet the notebook, sources, graph, dataset, and experiment runs that the inquiry produced. The interface should not guess a profession from a dropdown and swap dashboards. It should follow the objects, capabilities, and lifetimes emerging from the task. Stable chrome can keep orientation while the middle changes: a firm bowl for the jelly, because even a metaphor needs accessibility and window controls.
MGH widens the decomposition language available to models. DeepSeek Harness makes the agent runtime compositional. Cordis supplies a model for contextual capability and owned lifetime. Ernie is testing whether the visible interface can join the same system.
We are not only making Electron apps. We are choosing the environments in which people and agents will think together: what they notice, what they trust, what they consider finished, and what follows them after the interface disappears.
The best software is yet to be made because most software still chooses its shape before the work begins. Jellyware waits for the work to answer—and knows when to let go.