Most AI-native software ships the same interface: a chat box. That sameness is not a feature. It is a decision nobody made. The model returns conversation, so the product presents conversation, and every kind of work a person does with AI gets squeezed through a single interaction style.
My own setup ended up as three runtimes instead of one. Not because three is tidy, but because interaction design worked most of this out decades before large language models arrived, and the conclusions still hold. All three run every day. Two of them are tools I built; the third is borrowed, because the first-party version is a backend still waiting on its front end. That split is worth stating up front, since the argument here is about the three modes rather than about my particular software.
Three primitives, three kinds of thinking
I find it useful to sort interaction into three durable primitives. Two of them come straight out of the literature. Ben Shneiderman named direct manipulation in the early 1980s: visible objects, immediate feedback, reversible actions. Its counterpart is the conversational mode, where instead of acting on the world yourself you describe what you want to an intermediary that acts for you, a contrast Hutchins, Hollan, and Norman drew sharply in 1985. The third is my own addition to that pair rather than anything the field settled: the procedural mode, oldest of all in practice, the script and the batch job and the workflow you define once and run many times. HCI has never treated it as a peer of the other two, mostly because for decades it was not an interface at all. Once an agent can execute your procedures on your behalf, it becomes one.
Each primitive serves a different kind of thinking. Conversation is for ambiguity and discovery: you do not yet know exactly what you want, and the back-and-forth is how you find out. Procedure is for repetition and predictability: you know the steps, and the value lies in never re-deciding them. Direct manipulation is for exploration and curation, where the state is in front of you and judgment moves fastest through eyes and hands.
Large language models made the conversational primitive far more capable, and they became a new engine behind the other two. A fourth primitive never arrived. The collapse onto chat comes from confusing the engine with the interface.
What the collapse costs
Route a known, repeated procedure through chat and you re-litigate the steps every run. The model re-derives the plan, slightly differently each time, and drift accumulates exactly where you wanted none. Nondeterminism is a gift when you are exploring options and a defect when you wanted the same result as yesterday.
Route visible state through chat and every glance becomes a question. Which projects are stale? What went out under my name today? A conversational answer is a paragraph you read serially and then interrogate further. A rendered page answers at a glance and lets you act at the point where you see.
The mirror failures are just as real. A direct-manipulation tool asked to handle ambiguity grows menus until nobody can find anything. A workflow engine asked to handle discovery becomes a form you must complete before you know what you want. Anyone who has fought an expense system knows the shape.
None of this argues against chat. The argument is against chat as the only door.
The three runtimes
The methodology I practice, synthesis engineering, treats the choice of interaction primitive as the first design decision and the model wiring as the last. The family of open-source tools I build and run maps one runtime to each primitive.
Ragbot is the conversational runtime: a chat-led assistant that runs over my own workspaces rather than the open web. It indexes repositories of markdown and YAML that I maintain, retrieves with citations, runs skills (portable capabilities defined in markdown), speaks Model Context Protocol in both directions (as client and as server), and runs local models with frontier fallback. Across the releases that landed in May 2026 it grew from a retrieval assistant into a runtime with an agent loop, durable memory, and visible confidentiality boundaries between workspaces. I wrote about that release arc separately.
The procedural runtime is the one I have not finished building, and today it is not a product of mine at all: my procedures run as portable skills executed by whichever coding agent I am working in. That is a real runtime and it works, but it is borrowed, and the skills are the only part of it I own. Ragenie is where that lane is getting a first-party home, an agentic system extending Ragbot with multi-agent workflows built on LangGraph. Its backend services, retrieval pipeline, and workflow graphs are complete; the web frontend and the Ragbot integration are not started and no release is tagged. I am naming it here because the design of this lane is what the article is about, not because you can go and use it.
synthesis-console is the direct-manipulation runtime. It renders the plain files of my project management practice (project indexes, working context, lessons, daily plans) as browsable, searchable pages. No database, no import step; it reads the files on every request. Recent versions turned it from a viewer into a surface I work from: a queue of agent-drafted messages with approve, edit, and skip actions; a ledger of open commitments; a digest of everything agents sent on my behalf, with permalinks. The name is deliberate: a dashboard is a display you glance at; a console is a place you act from.
How a day routes across them
The abstractions earn their keep in the routing. When I am still figuring out what I want, that is conversation: asking Ragbot what I decided about a design question months back, or where a half-remembered lesson lives, and getting answers with citations into my own files. When the steps are known, that is procedure: the morning ritual that syncs repositories, pulls meeting transcripts, and generates the day’s plan runs as skills executed by agents, not as anything I type. When state needs my judgment, that is the console: a morning pass over the plan, the draft queue, and the on-my-behalf digest, approving and skipping in minutes.
The test compresses to three questions. Do I know the steps? Then it is procedure; write it down once as a skill. Do I need to see state to decide? Then it is direct manipulation; render it. Am I still discovering what I want? Then converse.
One substrate, three views
Three runtimes sound like three times the maintenance. They are not, for one reason: none of them is the system of record. The durable layer is files. My knowledge lives in plain-text repositories under version control. Configuration lives once in a shared home that every tool in the family reads. Capabilities live as skills, one folder-of-markdown format that runs unmodified in Ragbot and in external agents such as Claude Code, Codex CLI, Cursor, and Gemini CLI. Ragbot indexes the repositories. The console renders the same files as pages. The agents that run my procedures write the same files. Nothing is exported or migrated between the three, because there is nothing to move.
Files as the source of truth sounds unfashionable next to a hosted platform. It is also the property that makes the runtimes disposable. I can rewrite or retire any of the three without touching the substrate, and if all three disappeared tomorrow the knowledge would still be sitting in git, readable by whatever comes next. That is my test for whether a substrate is real: would the state survive the products?
Choosing for your own stack
If you are assembling a personal AI stack, the transferable part is the order of decisions. Choose the substrate first: plain files you own, in version control, readable without any product in the loop. Then attach one runtime per primitive as the need appears, and let each one be good at exactly one mode. When you evaluate a tool, ask which primitive it actually is underneath. A product that promises all three in one window is usually a chat box wearing menus.
New primitives will arrive; voice and spatial interfaces are the obvious candidates. When one matures, it gets the same treatment: its own runtime over the same files, with nothing else needing to change. The engine will keep improving on its own schedule. The interface is still a decision, and it is yours to make.