In brief: For sixty years, software has treated three kinds of interaction as three different problems: people talking to people, people operating machines, machines calling machines. Large language models have collapsed all three into a single medium, and that medium is language. This essay draws the architectural consequence. When every participant in a system speaks, the world model is no longer a database but the discourse itself; capabilities are speech acts with explicit conditions and effects; and the graphical interface stands revealed as what it always was, a curated selection from a larger whole. The argument ends in one concrete design principle: build the complete linguistic surface first, and derive every other interface, visual, API, agent, or voice, from it.
Die Grenzen meiner Sprache bedeuten die Grenzen meiner Welt.
("The limits of my language mean the limits of my world.")
— Ludwig Wittgenstein, Tractatus 5.6
1. The Convergence
1.1 Three Interactions, One Medium
There have always been three kinds of interaction in software systems, and they have always been treated as fundamentally different problems.
Human-to-human interaction runs on language. It always has. People negotiate, coordinate, and make decisions through conversation, email, documents, and spoken exchange. The medium is natural language in full: ambiguous, context-dependent, loaded with implicature and performative force. No one has ever needed to design a protocol for it. Language is the protocol.
Human-to-computer interaction was different. Humans think in language, but machines could not process it. So an entire engineering discipline grew up around the problem of translation: how to take what a person means and convert it into something a machine can act on. Graphical interfaces offered visual metaphors, command lines imposed grammatical constraints, forms decomposed intentions into discrete typed inputs. Every one of these was a compression scheme, and every one lost information in the conversion. The person meant something rich and contextual. The machine received something flat and typed.
Computer-to-computer interaction was the most constrained of all. Machines talked to machines through rigid protocols: REST APIs with fixed schemas, RPC calls with predetermined signatures, message queues with typed payloads. Context was excluded by design, and ambiguity was treated as a defect.
These three categories are no longer separate. They are converging into a single medium, and the medium is language.
1.2 The Evidence
The convergence is not theoretical. It is happening now, in production systems, at scale. Consider a small scene that would have been science fiction five years ago:
User: "Set up the usual project structure for the client work
we discussed yesterday, and make sure the CI agent
knows about it."
System: "Creating project 'Hartmann Relaunch' from the agency
template. One question: staging on the shared cluster,
as with the last two client projects?"
User: "Yes. And tell it to skip the load tests for now."
CI agent: "Pipeline registered for 'Hartmann Relaunch'. Load
tests disabled until further notice."
Three participants, one human and two machines, and every exchange runs on the same medium. Nothing in this scene was compiled into a form, a schema, or a fixed API signature before it could take effect.
Human-to-computer interaction has shifted this way across the industry. Users describe what they want in full sentences; systems interpret, ask clarifying questions, and act. The exchange follows the structure of conversation: turn-taking, reference to prior context, accumulation of shared understanding over a session. The translation layer between human intent and machine execution is not thinner. It is absent.
Computer-to-computer interaction has shifted in the same direction. Agent protocols such as MCP, the standard through which agents discover and call external tools, work through natural language. An agent reads a description of what a tool does, decides whether it fits the current task, formulates a request in language, and interprets the result. Two machines coordinate through discourse, using the same pragmatic structures of context, reference, and clarification that humans have used for millennia. The interaction between a coding agent and a deployment tool now looks, structurally, like a conversation between two colleagues.
Human-to-human interaction has not changed. It did not need to.
The three columns have collapsed into one.
1.3 What Changed
The constraint that separated these three interaction types was never architectural. It was material: machines could not process language. That single fact forced every interaction involving a machine to pass through a translation layer, and the translation was lossy, expensive, and required constant maintenance. An entire ecosystem of tools grew up to manage it: ORMs, schema validators, type systems, serialisation formats, API specification languages, frontend state management libraries. Each tool bridged one segment of the gap between what someone meant and what the machine could handle.
The gap closed. Large language models made language a computational medium, not a better input format but a medium in which computation actually occurs. The tools that bridged the gap are still running. The gap they bridge is gone.
2. Language as World Model
2.1 What This Means
When every participant in a system, human users, application logic, and external agents alike, operates through language, the world model of the system is no longer a database that language queries or a state machine that language triggers. The world model is the discourse itself.
The easy misreading of this claim is idealism, the notion that external reality depends on what anyone says. That is not the claim. A build server fails or succeeds regardless of the conversation about it. The claim concerns the system's internal representation. The system knows the build is failing because an agent reported it, and that report carries information a boolean field cannot: who reported it, when, in response to what query, with what confidence, and with what implied scope. The build server is external fact. The system's model of the build server is discourse.
The practical difference from state-centric design is informational density. A database row for a project stores name, status, owner as typed fields. The discourse record of the same project stores all of that plus temporal scope (when each property was established), defeasibility (under what conditions it might change), pragmatic conditioning (was "high priority" global or sprint-scoped?), and the full chain of commitments connecting the current state to the history that produced it. A database stores facts. Discourse stores facts, reasons, conditions, and obligations. State is a snapshot. Discourse is the complete record from which any snapshot can be derived.
2.2 Speech Acts as the Grammar of Reality
If language is the world model, its atoms are speech acts. Every meaningful interaction performs a specific type of act with identifiable force.
Directives command action: "Create a project," "Archive the old files." They carry authority, scope, and urgency that a write operation does not encode.
Declarations create facts: "This project is now high priority," "The deadline is Friday." They bring new realities into the world model. A database UPDATE does the same thing but does not record who declared it or whether they had standing to do so.
Commissives create obligations: "I will review this by Thursday," "The system will notify you when the build completes." These persist as active commitments, accountable and defeasible. The state-centric equivalent, a flag or a scheduled job, captures the obligation while stripping away its social character.
Assertives contribute information: "The build is failing," "Revenue is up twelve percent." They establish propositions in the shared ground, available for reference and reasoning.
Expressives register evaluations: "This architecture is elegant," "The performance is unacceptable." They shape the evaluative dimension of the world model without changing entity properties.
Interrogatives request information without mutating the world model: "What projects are due Friday?", "Who owns this repository?" The classical taxonomies file questions under directives, as requests that the hearer supply an assertive, and the classification is defensible but flattens what questions distinctively do. A question shifts what the conversation is about without changing what exists: after "What projects are due Friday?", the word "them" in the next utterance points at the answer. Interrogatives are the most common interaction in most systems, and their contextual effect deserves first-class treatment.
2.3 Context as Interpretive Ground
If the world model is discourse, then the current "state" of the system at any moment is the interpretive ground of that discourse: what has been established, what is presupposed, what is topical, what commitments are active. Call this the Context Field. It is not a cache. It is the system's understanding of the world as constituted by the conversation so far.
Two of its components carry most of the weight.
The referential field tracks which entities are available for reference by pronoun or description, ranked by salience. Recency matters, topicality matters, discourse prominence matters. When the field is well maintained, "archive the big one" resolves to the right project. When it is not, the phrase resolves to the wrong entity with full confidence, which is worse than not resolving at all. State-centric systems have no equivalent; every query arrives as though the previous one never happened.
The commitment store holds mutual obligations between participants. "I will notify you when the build completes" persists here as a live obligation until fulfilled or explicitly cancelled, not as a scheduled job that has forgotten it ever promised anything. Most state-centric systems do not represent commitments at all, which is why they routinely fail to do what they said they would.
Three further components complete the ground. The current topic determines how words like "it" and "that" resolve, pointing them at whatever holds attention in the discourse. The presuppositional ground carries background that no one should have to renegotiate: once "the team" has been established as the backend engineering group, it stays established, where state-centric systems force users to re-specify such context with every interaction. And the register marker tracks where the interaction sits between formal and informal, governing parsing strictness and output style.
3. Terminal-First Design
3.1 Why the Terminal
Every graphical interface is a cage. This is not rhetoric; it is an observation about the structure of spatial representation.
A GUI presents a selection of the system's capabilities. A designer chose which speech acts get buttons, a product manager decided which entities get displayed, an information architect determined which relationships get visual representation. Everything outside those decisions is not merely restricted but invisible: the user does not know it exists.
This is not a failure of design. It is a consequence of the medium. A screen has finite space, a layout implies hierarchy, and every button, card, and menu item is a decision to include, and therefore a decision to exclude everything else. The more polished the visual interface, the more thoroughly it constrains the user's sense of what the system can do. Wittgenstein's sentence at the head of this essay describes the situation precisely: the limits of the interface's language are the limits of the user's world.
The terminal makes no selection. Its input is language, and language can express any act the registry defines. There is no screen real estate to allocate and no information architecture to funnel attention. The full world model is accessible at every moment, constrained only by the user's ability to articulate what they want.
This is the argument for terminal-first design. Not that terminals are faster, not that experts prefer them, but that they are complete. The terminal is the only interaction surface that does not amputate the world model. The GUI adds spatial cognition, pattern recognition, gestural manipulation, simultaneous visual scanning, and these are real cognitive affordances. But the GUI pays for them by selecting, on the user's behalf, which fraction of reality to make visible. These are not comparable costs. Losing a cognitive convenience is one thing. Losing access to capability is another.
The design principle that follows is concrete: every application must expose a direct linguistic input connected to the full Speech Act Registry. Not a search bar, not a chatbot in the sidebar, but a first-class input surface through which any act the system can perform is expressible. The GUI is the curated gallery. The linguistic input is the door to the building. An application without that door has locked its users inside the gallery and told them it was the world.
The objection comes quickly: users do not want the full world model. They want simplicity, progressive disclosure, guided paths. This is true, and it is the GUI's genuine contribution.
But for thirty years, the guided path has been confused with the territory. Users were not choosing simplicity; they had no alternative, and their contentment was mistaken for preference. In a language-native architecture, both exist. The GUI curates, the terminal completes, and one must come first in the design process: the complete one. You cannot derive completeness from a subset. You can only derive subsets from completeness.
If your users can do only what you imagined they would want to do, you have not built a tool. You have built a guided tour.
3.2 The Speech Act Registry
If the terminal is to expose everything the system can do, something must define what the system can do, once, in a form every surface can read. That is the Registry. Each entry specifies a speech act: its type, the conditions for its success, and its effects on the world model. In the example below, note that the conditions specify who may speak and what must already hold, not merely which parameters are required:
speech_act:
id: create_project
type: directive
felicity_conditions:
authority: speaker can create projects
preparatory: project name is unique within scope
sincerity: speaker intends the project to exist
parameters:
name:
type: string
discourse_effect: establishes reference for later mention
template:
type: enum[web, mobile, api]
default: web
effects:
- project entity comes into being
- project becomes current topic
- system commits to maintaining the project
composability:
sequential_with: [assign_team, set_deadline]
compensating_act: delete_project
The Registry is interface-agnostic. It does not know about buttons, endpoints, or voice grammars. It knows the grammar of action in this system: what can be said, what must hold for the saying to succeed, and what the saying does to the shared world.
When a new speech act enters the Registry, every interaction surface gains access simultaneously. The terminal matches it through natural language patterns, the template engine generates a form, the API layer exposes an endpoint, and an agent discovers it through its linguistic description. No per-surface implementation is needed. The complexity has not disappeared; it has moved from interface duplication into the discourse kernel, where it belongs.
Compositionality. Real interactions are rarely atomic. "Create a project and invite the team" is a sequential compound. "Archive the old files unless they're referenced by active projects" is a conditional directive. The Registry handles composition through three connectives. Sequential: A then B, where B's success conditions may depend on A's effects. Conditional: A unless P, where P is evaluated against the current Context Field. Parallel: A and B independently. Failure semantics follow from act type: if B fails in a sequential compound, A's compensating act is available but not automatic, because the decision to compensate is itself a speech act. Atomicity is a declared property, not an assumed one.
3.3 The Context Engine
If the Registry defines what can be said, something must track what has been said and keep the interpretive ground coherent. That is the Context Engine. It maintains the world model, resolves references, and validates the conditions under which acts succeed.
Reference Resolution. When a participant says "archive the big one," the Engine consults the referential field: which entities are salient, which match the description, which is the strongest candidate given recency and prominence. If resolution is ambiguous, the Engine does not fail. It asks:
Input: "Archive the big one"
Resolution: ambiguous. Project Beta (2GB) vs Project Gamma (1.8GB)
Clarification: "Two projects are close in size: Beta at 2GB
or Gamma at 1.8GB?"
User: "Beta"
Resolution proceeds: archive(Project Beta)
Context update: Beta archived; Beta becomes current topic;
"it" → Beta
This is not error handling. It is normal operation. Ambiguity is a feature of language, and the architecture handles it through conversation. The alternative, Error: ambiguous reference, is the response of a system that can parse but cannot listen.
Epistemic Authority. When multiple participants issue conflicting declarations, timestamps are not enough. "Priority is high" from one user and "Priority is low" from another, issued simultaneously, require something beyond temporal ordering. The Context Engine resolves this through authority scoping: every speech act's success conditions include an authority dimension specifying who can perform it and over what scope. A team lead's declaration about sprint priority supersedes a team member's because the authority condition is satisfied at a higher level, not because the timestamp is later.
When authority is genuinely equal, the Engine does not pick a winner. It marks the conflict as unresolved and surfaces it to participants. Competing assertions coexist as contested propositions until someone with sufficient authority, or the disputants by agreement, issues a resolving declaration.
Checkpointing. Reconstructing the full world model from the complete discourse history is expensive, and under model versioning it is potentially non-deterministic. The architecture addresses this with checkpoint declarations: the system periodically issues a summary speech act that materialises the current Context Field as an explicit assertion. Three conditions trigger checkpoints: discourse length exceeding a threshold, elapsed time, or explicit participant request. The checkpoint preserves what entities exist, what properties they hold, what commitments are active, and what the current referential field contains. It discards the inferential chain, the sequence of resolution steps that produced the current state, because the chain is diagnostic, not constitutive. It remains in the full transcript for forensic use but is not needed for forward operation.
Conflict Resolution. For sequential operations, temporal precedence governs: later utterances supersede earlier ones unless they explicitly defer to prior context. For concurrent operations, authority scoping governs. Time settles sequence. Authority settles disputes.
3.4 Register Adapters
Every other interaction surface is a translation of the same discourse, and the architecture treats it as such.
The Visual Adapter generates graphical interfaces from the Registry. A directive with three parameters becomes a form with three fields; related entities become tables or cards. The rendering derives from speech-act definitions, so the GUI cannot offer a capability the Registry does not define. But it will always offer fewer than the Registry contains, because screens are finite and design requires selection. The Visual Adapter's job is to select well, not to pretend selection is not happening.
The remaining adapters follow the same logic for other registers. The API Adapter produces formal, context-stripped endpoints for machine-to-machine use: speech acts become endpoints, success conditions become validation rules, effects become response schemas. The Agent Adapter serves external agents and, unlike the API Adapter, preserves context: an agent can maintain a session, build referential ground, and issue compound requests. The Voice Adapter handles the particulars of spoken interaction, from prosodic cues to turn-taking.
Each adapter is thin by construction. Intent resolution, felicity checking, context maintenance, and world-model mutation happen in the discourse kernel. The adapters render. They do not reason.
4. Implications
4.1 The Relocated Boundary
The frontend-backend divide does not disappear. It moves. The old boundary separated presentation logic from business logic, requiring both sides to implement the same reality independently and then stay in sync. The new boundary separates the discourse kernel from the register adapters. One side defines what can be said; the other determines how it is rendered. The sides no longer drift, because the adapters derive from the kernel rather than reimplementing it.
4.2 Testing as Felicity Checking
Unit tests verify that speech acts with satisfied success conditions produce expected effects. Integration tests verify that sequences of acts maintain coherence: references resolve, commitments persist, presuppositions hold. Regression tests verify that the same utterance in the same context produces the same resolution, guarding against interpretive non-determinism.
4.3 Debugging as Discourse Replay
When something goes wrong, the question shifts from "what was the state of variable X?" to "how did the system interpret utterance N in the context at that point?" When a user's "archive" hit the wrong project, the debug path traces meaning assignment, not call sequence: the referential field, the salience ranking, the resolution chain. The transcript is the log. The context field is the state. The resolution chain is the trace.
4.4 Multi-Participant Discourse
A single discourse can include humans, application agents, and external services. A user says "create a project and have the CI system set up a pipeline." The system decomposes this into a directive to its own Registry and a delegated directive to an external agent. The agent interprets, checks the conditions, acts, and reports back into the shared discourse. All participants operate in the same medium, differentiated by register and authority, not by category.
5. Limitations and Open Problems
Non-determinism under model versioning. Upgrading the language model may change how utterances are resolved. Checkpoint declarations limit the blast radius but do not eliminate the risk. A robust implementation records not just utterances but the resolutions they produced, so that historical reconstruction reflects what actually happened rather than what the current model would do.
Latency. Contextual resolution costs more than direct state lookup, and reconstruction from a checkpoint plus subsequent discourse interpretation introduces delay. Checkpoint frequency is a tradeoff: at the limit, checkpointing after every utterance converges on a database write. The architecture does not claim to be faster. It claims to be more complete.
Spatial cognition. Graphical interfaces enable cognitive operations linear discourse cannot: simultaneous element scanning, spatial pattern recognition, gestural manipulation. A Kanban board makes bottlenecks perceptually immediate; a scatter plot reveals correlations before they can be articulated. These are real computational affordances, and the terminal does not offer them. This essay does not argue that the terminal replaces the GUI. It argues that the GUI has been mistaken for the whole when it was always a selection, and that the correction is not abolition but addition: every system must maintain a complete linguistic surface alongside its visual surfaces. The question is not which is better. The question is whether the user has access to the full capability space.
Multi-user context negotiation. When multiple users share a discourse, context management becomes social coordination. Whose presuppositions govern? Whose topic is current? The epistemic authority model handles explicit conflicts. The subtler problem of divergent presuppositional grounds, users who take different things for granted, remains open.
NLU as structural dependency. The quality ceiling of the system is the quality ceiling of its language understanding. Misinterpretation in a state-centric system produces a bad API call. Misinterpretation in a discourse-native system corrupts the world model itself. Felicity checking and clarification provide defence in depth. The dependency remains.
6. Conclusion: After the Detour
For sixty years, software architecture has been a discipline of translation. Machines could not process language, so language was compiled into formal structures before computation could begin. Schemas, APIs, type systems, interface specifications, state management libraries: each component bridged one section of the gap between how humans think and what machines required. The bridges were often ingenious. The gap they spanned is now closed.
What remains is simpler. Capabilities defined once, as speech acts with explicit conditions and effects. A context engine that maintains the interpretive ground. Register adapters that render the same discourse into whatever form the situation requires, each surface a coat of paint on the same wall, none of them the wall itself.
Every application gets a direct linguistic input. Not because it is fashionable, but because an application without one has decided, without asking, what fraction of its own capabilities its users are allowed to discover.
Build the terminal first. The rest is paint.