Human-computer interaction and canonicality in enterprise AI
Mitchell Hashimoto’s new company, Superlogical, will “begin with a terminal multiplexer”:
[Work] today spans local machines, remote hosts, sandboxes, services, and production systems. [Software operates] interactively with a human developer, automatically through [continuous integration] and background processes, and increasingly through agents working in parallel.
Superlogical hints at a product vision to “span applications and environments.”
Over the last several years, Mitchell has explored the multiplexer form factor over Twitter. His palpable fascination with the product craft — terminal interactions and performance as a predominant design goal — proves commonly imagined lines between frontend, backend, and infrastructure design and engineering have little relevance when trying to reach an ambitious product goal.
Focus on the frontend craft for a second. The craft encompasses, and now demands, not only aesthetic concerns, but also the fundamental question Superlogical’s announcement poses: In the time of the LLM, how are we going to use, and be served by, computers?
The entrepreneurial and conceptual ferments around pins that record interactions, the person who feeds conversations to Claude to learn how to be a better person, the newest VR goggles, Git worktrees and agent swarms, hill-climbing and /goal, agentic prospecting pipelines, AI pastors and girlfriends — engage, on a form factor level, the very same concern as Mitchell’s company.
While LLMs do not supplant traditional computing, they shift, evolve, and introduce discontinuities within, the human-computer interactivity paradigm itself. Moreover, technical advancements in LLMs and harnesses, like long-horizon agents, imply actually new modes of interactivity.
That very dynamic dialectic between capability and interactivity is a rich site upon which to set epistemological and psychological lenses. I would like to explore what these new circumstances require of design in a regulated enterprise context.
Help from domain driven design
In this discussion, we need to be able to think about what is true in an enterprise, what a software system records, and how data gets changed. Domain driven design has great language for this out of the box.
From a domain driven design perspective, we can look at software as just modeling the sets of domain objects and events. There is some underlying reality out there that the system models and expresses in its user interfaces.
Because we especially need to focus on mutations and who causes them, we also need a notion of datastores and actors, a category that includes both humans and agents.
The quality of canonicality
When designing with LLMs for the enterprise, canonicality of output data is what we need to try and achieve.
In an enterprise, a system of record is canonical. We would often call a system of record a “golden source.”
Canonicality is distinct from ground reality and even from the quality of strictly according with some actual truth in the world. But it is the closest we can practically get. In the locus of an organization, if something is canonical, it can be said to be true, and it often is true. So, critically, the quality of canonicality is at least a sociotechnical one.
Organizations try to maintain a desired degree of truthfulness in systems of record. Implicitly, and already in a pre-LLM world, human inputs are not fully trusted.
The degree of trust depends on sociological factors. From the perspective of the organization, the data an expert person puts into a system is seen as canonical. Typically, organizational hierarchy and management structure are also modeled in role-based access control (RBAC) role and permission schemes.
Establishing trust through evals
AI evals transform non-deterministic operations on an ambiguous problem domain into structured measures anyone can understand.
Existing enterprise regimes like quality control, content moderation, and audit can be understood as trust-establishing mechanisms. They strive to ensure information put in the system by humans actually reaches a desired degree of truthfulness.
When you have LLMs writing into the system, evaluations become critical cause they give you a socially agreed-on, digestible set of measures. Together, these core qualities help establish trust.
Designing evals raises the same challenges non-AI analytics already raise: Are you measuring the right signal to solve the problem you care about? Do your measurements actually detect the circumstances you think they do? From what I’ve seen, getting these questions right on a business and instrumentation level is a core challenge for product teams.
Information provenance and mutations
In production systems that incorporate LLMs, design must clarify where information comes from.
Information provenance is already a first-class concern in enterprise software. You would always be able to tell who approved a loan. An audit log would always tell you who modified an object, and sometimes even who just looked at it.
So to conceive of a system or datum as canonical is actually an observation upon an accretion of mutations over time.
| Actor | Mode | Example |
|---|---|---|
| Human | Manually | |
| First-party system | Recorded automatically | Updates performed by the system itself, like recording an |
| Second-party system | Arriving via payload | A separate, other traditional system sends information via API integration |
| First-party agent | Various models | Human-in-the-loop paradigm |
| First-party-agent from elsewhere in the enterprise | Model context protocol server usage | Query specialized data from another team |
| Second-party agent | Computer use or end-user-exposed MCP | Agentic finance |
| Third-party agent | Unusual | - |
As is probably obvious by now, I think we can reuse a lot of UX/UI paradigms for review of human-caused mutations.
The core limitation of this approach is the speed and scale at which LLM-generated mutations occur. This interactivity paradigm breakdown is seen today in code review; in GitHub outages; in open-source projects forbidding pull requests from LLMs; and in other cases like LLMs submitted small courts claims and property tax reassessment requests.
Staged, proposed, or untrusted information
Now, things are different. You might have a value that was inferred. An important design question here is how and whether to stage the data as “to-be-accepted,” in opposition to the canonical data comprised of the set of that object’s properties.
-
Designate information as untrusted
-
UIs to carry out review
-
UIs to inspect object history
-
Self-reported LLM confidence
We would wish to avoid poisoning a broadly canonical data source with unverified LLM outputs.
So a design goal for enterprise AI is to inform the user what is trusted and what is not.