---
title: "Spaces: how do we hold work together across tools?"
code: "RP-0127"
language: "en"
canonical: "https://regentspark.ai/RP-0127/"
html: "https://regentspark.ai/RP-0127/"
markdown: "https://regentspark.ai/RP-0127.md"
updated: "10 April 2026"
---
# How Do We Build Interfaces Over Messy Data?
*This is a bridge essay. The public thesis is that computing is missing primitives. This piece asks the next question: if that is true, what would a system actually need to do for the ordinary mess of work?*
> **Summary:** Work becomes incoherent when it crosses tools. A durable substrate should hold the people, objects, spaces, memory, and relationships of a live situation so different interfaces, including AI-generated ones, can reveal the same work without owning it.
## The work is scattered
> **Summary:** Modern software stores fragments very well, but it does not preserve the thing the user actually cares about: the live situation that stretches across files, people, tools, and time.
You open your laptop to answer a simple question: where are we on this?
Forty minutes later you have twelve tabs open.
The contract is in email. The last real decision was made in chat. The meeting where everyone agreed something important is sitting in a calendar invite. The working draft is in a local folder with the wrong name. The screenshot that explains the bug is on your phone. The same person appears as an email address, a phone number, a Slack handle, and a Figma commenter. There is also a note somewhere that you distinctly remember writing and cannot find.
Nothing here is unusual. This is just work now.
The problem is not that your tools failed to store the pieces. They stored all of them. The problem is that the *situation* did not survive crossing those tools.
The work still exists, but only as a reconstruction happening in your head.
> **Alt text:** A desk covered with a laptop email inbox, phone messages, notes, blueprints, a planner, and labeled binders showing a project scattered across many tools.
> **Visible text:** email; THE CITY; PROJECT ARCHIVES; MATERIAL STUDIES; reminder
> **Description:** The illustration shows a work desk viewed from above and slightly front-right, with the main cluster centered on a laptop displaying an email inbox UI, suggesting one of several tools involved in a larger project. To the left of the laptop is a coffee cup near the table edge, and below it a smartphone with stacked chat/message bubbles, while the lower center holds loose handwritten notes and a pen, indicating ad hoc reminders. To the right of the laptop are overlapping paper blueprints or floor plans, a rolled plan, and a small USB stick, with a stack of binders/books at the far right; the visible spine labels read "THE CITY," "PROJECT ARCHIVES," and "MATERIAL STUDIES." An open paper planner sits in the lower-right area with a calendar grid and a visible bell icon next to the word "reminder," reinforcing the theme of fragmented tasks and scheduled follow-ups. In the background, a window brightens the desk and the objects feel grouped into separate but related evidence sources rather than one unified workspace. Overall, the image communicates a project assembled from scattered artifacts across devices, paper, and files that must be mentally held together.
> **Image source:** content/RP-0127/illustrations/messy-data-kitchen-table.png
### The project lives in your head
What users call a project, a case, a trip, a renovation, a launch, or a hiring process is not one file type. It is a bundle of people, artifacts, decisions, deadlines, conversations, and memory.
Software still treats those as separate territories.
Email knows messages. Calendar knows time. Drive knows files. Chat knows threads. A notes app knows notes. Each tool is good at its own local ontology. None of them are good at holding the whole thing together.
That is why people feel perpetually behind even when nothing is technically lost. They are paying a constant tax in mental reconstruction.
Doug Engelbart's real target was not document editing. It was augmenting a human being trying to hold a complex situation in view. That remains the right target.
```mermaid
flowchart LR
Email[π¨ Email] --> Head[π§ Your head]
Chat[π¬ Chat] --> Head
Files[π Files and screenshots] --> Head
Calendar[π
Calendar] --> Head
Notes[π Phone note] --> Head
IDs[π€ One person, four identities] --> Head
Head --> Situation[𧩠The actual situation]
```
The current workaround is familiar: search harder, make another folder, star the thread, pin the chat, forward the email to yourself, write a recap no one will update, keep more of it in your head.
That is not a user failure. It is a primitive failure.
### A situation is not a folder
The old model says: if you organize the artifacts well enough, the work will become coherent.
It doesn't.
A folder can hold files, but not the conversation about the files, not the person who owes you an answer, not the meeting where the scope changed, not the sense that one document matters because it overturned a decision made three weeks ago.
A situation has shape. It has momentum. It has active edges between people and things.
It also has continuity through time, which is where current software really falls over. When you return after a week, the computer gives you the same fragments back. It does not give you the state of play.
"An object without a space is a lost object" is a sharp way to say it. Most of our computers are orphan factories.
> **Alt text:** Three linked room-like interface boxes sit in a row while a person walks past them, suggesting multiple views connected by the same underlying system.
> **Description:** The illustration shows three small room-like structures arranged horizontally across the middle of the image, sitting on low platforms in front of a stone wall and sparse trees. On the left is an open-front box with a dark green interior; in the center is a closed box with a dark wood face and a large glass sliding door; on the right is another closed box with a peach-toned frame, dark side paneling, and a frosted-looking glass front. A person in a long green coat walks in the foreground from left to right between the center and right units, leaning toward the central structure as if interacting with it. Thin glowing lines run between small circular connection points on the boxes, visually linking the three units and implying shared data or continuity across separate views. The overall composition communicates that multiple interfaces or rooms can be connected to the same underlying system rather than existing as isolated objects.
> **Image source:** content/RP-0127/illustrations/messy-data-app-rooms.png
## The substrate has to take the mess
> **Summary:** The system cannot demand clean structure up front. It needs a durable layer that can absorb messy inputs first, then let intelligence enrich and relate them over time.
### Capture first
If the system only becomes useful after everything is neatly classified, it dies on day one.
Real work begins in ambiguity. A thing arrives. You know a little about it. Then you know more. Then you discover it matters to another thread entirely. Good software must be able to start from that rough first trace.
This means the bottom layer has to be boring in the right way. It should be able to hold people, spaces, objects, memory, and relationships without demanding a perfect schema before the work can begin.
This essay is not the full Four Primitives argument. It sits one step downstream of it. The point here is narrower: whatever primitives we settle on, they must be able to receive ugly reality as it arrives, not only after it has been cleaned for presentation.
The semantic web kept trying to make the bottom layer smarter and stricter. Useful humility turned out to scale better than formal completeness.
### Two layers, two jobs
Once you accept the mess, the stack becomes clearer.
The lower layer has to preserve what should survive interface changes: identity, provenance, explicit relationships, permissions, history, and enough structure that the work remains portable.
Above that sits a semantic layer: summarization, clustering, retrieval, identity resolution, ranking, suggestion, maybe agentic help.
These are both necessary. They are not the same thing.
If you collapse them, you get a very smart system that cannot be trusted, or a very rigid system that cannot cope.
```mermaid
flowchart TD
Sources[π¨π¬ππ
Messy sources] --> Adapters[π Adapters and capture]
Adapters --> Substrate[𧩠Durable substrate\npeople, spaces, objects, memory\nprovenance, permissions, event history]
Substrate --> Semantics[π§ Semantic layer\nresolve, summarize, suggest, rank]
Semantics --> Views[πͺ Views and actions]
Views --> Renderers[π Dossier Β· room Β· timeline Β· briefing]
```
This is the core claim: value should live in the substrate, not in one privileged interface and not inside one model's interpretation.
AI matters enormously here, but downstream. It can help the system notice, compose, retrieve, and explain. It should not be the sole owner of what is true.
### Explicit links and inferred links
A lot of modern software blurs a crucial distinction.
Some relationships are explicit and govern action.
This person approved this draft.
This file came from this email.
This meeting changed this deadline.
This note explains this decision.
Other relationships are inferred.
These two contacts are probably the same person.
These notes seem related.
This chat likely belongs to the same project.
Both kinds are useful. Only one kind is durable enough to build on directly.
```mermaid
flowchart LR
subgraph Durable[𧩠Durable and inspectable]
Person[π€ Person]
Draft[π Draft]
Decision[β
Decision]
Space[π Space]
Person -->|approved| Draft
Draft -->|belongs to| Space
Draft -->|led to| Decision
end
subgraph Semantic[π§ Semantic and assistive]
ContactA[π¨ Sarah on email]
ContactB[π¬ Sarah on WhatsApp]
Note[π Phone note about kitchen]
Hint[Likely same person\nProbably related note]
ContactA -.-> Hint
ContactB -.-> Hint
Note -.-> Hint
end
```
The durable layer needs inspectable edges. The semantic layer can propose, rank, and enrich. If you reverse that order, the whole system becomes slippery.
Embeddings are excellent at surfacing fuzzy relatedness. They are much worse as a replacement for deliberate, inspectable commitments in the world.
## Interfaces should be views
> **Summary:** The interface should reveal and manipulate the substrate, not imprison it. A room, a timeline, a board, or an AI briefing can all be good, as long as they are replaceable views over the same underlying work.
### One substrate, many views
Once the substrate is doing its job, the interface question gets much more interesting.
The same underlying situation might want to appear as:
- a dossier when you need to understand it
- a timeline when you need sequence and causality
- a board when you need execution
- a mobile brief when you are rushing between meetings
- an agent-facing context pack when software is doing the next pass for you
That is a healthier ambition than building one universal super-screen and forcing every kind of work into it.
```mermaid
flowchart LR
Substrate[𧩠Shared substrate] --> Dossier[π Dossier]
Substrate --> Timeline[π°οΈ Timeline]
Substrate --> Board[π Board]
Substrate --> Room[π§ Room]
Substrate --> Brief[π€ Agent briefing]
Substrate --> Mobile[π± Mobile recap]
```
The interface description layer, whether it looks like a DSL or something looser, is useful here. It gives software and agents a bounded way to ask for a rendering.
Show me unresolved decisions.
Show me everything this person is waiting on.
Render this space as a review room.
Give me the last two weeks as a causal sequence, not a chronological dump.
That is powerful. But it only works if all those views are downstream of shared structure.
### Spatial views are optional
Humans are spatial and social creatures. We orient through rooms, tables, presence, adjacency, and shared attention. So yes, embodied or spatial interfaces can be excellent renderers for complex work.
But they are renderers.
That distinction matters because otherwise the metaphor eats the system. We end up confusing "this feels like a room" with "the room is where reality lives."
A room-like workspace is valuable precisely when the same underlying situation can also appear as a quiet reading view on a phone or a structured handoff to an agent.
See Adam Wiggins and Muse for one strong demonstration that spatial arrangement can help thought. The lesson is not that every interface should become a canvas. The lesson is that place is one powerful view over shared structure.
> **Alt text:** Composite illustration showing a case file, a timeline with people reviewing documents, an agent briefing card, and a shared room workspace as different views of the same project.
> **Visible text:** Agent briefing card; 1903; 2013
> **Description:** The illustration is arranged as a set of related panels showing the same work across different views. On the left is a large cream-colored folder or case file opened to reveal layered pages with maps, small profile photos, handwritten marks, and a circular emblem on the cover, suggesting a stored record package. Across the top-right is a horizontal timeline scene with three groups of people standing around papers and a desk lamp, with the years β1903β near the middle and β2013β toward the right, implying continuity across time and repeated review of the same material. Near the lower center-left is a smaller card labeled βAgent briefing cardβ with three headshot thumbnails and short blocks of text, representing a compact summary view derived from the larger case. On the lower right is an isometric room-like workspace where three people sit or stand around a lit table with documents and a glowing central object, surrounded by windows, shelves, a desk, and lamps, communicating that one underlying situation can be rendered as a dossier, a briefing, a timeline, or a shared room.
> **Image source:** content/RP-0127/illustrations/messy-data-many-views.png
### The super-app trap
This is where most current attempts go wrong.
A company notices that users need context across tasks, chat, docs, people, and AI. So it adds all of them. Then another company does the same. Soon every product is trying to become the place where work finally makes sense.
That is not a solution. That is the lock-in race.
The test is brutal and simple:
If the meaning of the work only exists inside one interface, then the interface owns the user.
If the meaning lives in a portable substrate and interfaces compete to serve it well, then the user has something closer to agency.
This is the real divide between a missing primitive and a premium feature. A feature makes one product better. A primitive changes what all products can build on.
## The proof is continuity
> **Summary:** This idea does not need a grand universal rollout to prove itself. It needs one ugly, real project to remain coherent across messy inputs, shifting views, and time away.
### Start with one live project
The wrong demo is a clean greenfield workspace.
The right demo starts mid-stream.
Pick one live piece of work that already leaks across tools. A renovation. A research project. A hiring process. A company formation. A product launch. Ingest a few files, a few messages, a calendar event, a couple of notes, and the overlapping identities involved.
Do not clean it into submission. Preserve source identity. Preserve provenance. Add a few explicit relationships. Let the semantic layer suggest a few more.
Then do the interesting part: switch interfaces without rebuilding the world.
If the user can leave for a week, come back in a different view, and still feel the work holding together, then something real has happened.
### Relief, not novelty
The outcome is not "wow, what a futuristic interface."
The outcome is quieter than that.
It feels like the computer finally remembers what you mean when you say "this thing."
It feels like fewer archaeology sessions.
It feels like less copying and pasting between rooms.
It feels like being able to hand work over without writing a novel first.
It feels like the same reality meeting you in the form you need today.
That is why this essay sits where it does in the sequence. The public thesis says computing is missing primitives. The deeper system work will ask exactly what those primitives are and how they compose. This piece is the bridge between them. It says: before we disappear into ontology or interface theater, here is the practical demand the system must satisfy.
Hold the work together across tools, identities, files, chats, and time.
Everything else is secondary.
> **Alt text:** A person sits at a table reviewing an open notebook with connected notes and papers around them in a calm home office.
> **Description:** The image shows a single person seated at a small table in a quiet room, occupying the center-left of the composition and leaning over an open book or notebook. On the tabletop, the open central book is the main focal object, with a pen near the lower left edge, a small stack of closed notebooks at the front-left corner, and a coffee cup plus a stack of papers or documents on the right side. Behind the person, a bookshelf with a few books sits on the left background, while a potted plant and a bright window occupy the upper middle and right background, reinforcing the indoor setting. Across the table surface, several colored blob-like notes or markers are connected by thin curved lines, suggesting relationships between scattered pieces of information or ideas. The overall image communicates organized thinking, synthesis, or note-taking around a complex project rather than a finished product.
> **Image source:** content/RP-0127/illustrations/messy-data-return-briefing.png