Each surface knows something about what I am working on. What crosses between them is a pile of handoff artifacts, and nothing owns which of those are still true.
I have multiple Claude surfaces open on any given day, and the count keeps growing. Four of them carry this essay. There is the claude.ai chat window, where I do most of my thinking-out-loud writing. There is Claude Code, where the actual code lives. There is Cowork, which sits on my desktop and lets me hand off structured file work. And there is Dispatch, which runs longer background tasks and (theoretically) delivers them back to me when they are done.
Each of these knows something about what I am working on. Together, they know almost everything. And yet the joint of the system, the seam where these four surfaces meet, is the place where the work pays a toll.
The pain, concrete
Yesterday I spent thirty minutes in Claude chat working through the framing for a piece I am drafting. Angle, register, what the reader needs to arrive believing. The chat window ended with a sharp outline and a shared understanding of what "good" looks like for this particular piece.
The handoff out of that session was the usual kind. The outline landed in a file, the decisions in a handoff note, in a shared folder every surface reads; some of it I wrote, most of it the session wrote itself on the way out. Cowork picked the artifacts up and started drafting.
And the switch still cost me, because artifact handoff has its own physics. Drift: a note captures Tuesday's state, nothing updates it when Thursday overturns a decision, and the next reader takes it as current. Erosion: every handoff is a re-distillation, a summary of a summary; the note carries the conclusions and none of the pushback that produced them, and each repackaging shaves off a little of what made a conclusion trustworthy. Bloat: the shared folder fills with overlapping files about the same piece of work, and the first job of every new session is deciding which three of the eleven still bind.
The same toll again at Claude Code, and again when Dispatch handed back a result into a context that had moved on. The tax did not disappear when I stopped retyping; it changed form. I curate: which artifacts to hand the new surface, which to warn it off, what changed since they were written. Minutes at every switch, me doing it every time, multiplied by the number of pieces I am running at once. The transfer exists. What is missing is anything that owns it. The reflex is to call this a memory problem and reach for a better store. Hold that reflex; none of the three frictions is a storage failure, and the rest of this essay is about what is.
The reframe
I have been building systems where the interesting problem is the inverse. In the voice-assistant work I do at nights and weekends (I have written about the shape of that world before, in Voice Conversation ≠ Text Chat + Audio), an assistant is running four or five background tasks: a websearch, a calendar check, a long tool call. The design problem is which of those tasks should interrupt me, and when. The user is one; the tasks are many; the channel to the user is scarce.
The idea I have landed on for that shape is that something in the system has to decide what reaches the user's attention and when. Not everything can. Nothing shouldn't. Call the layer that does this arbitration the attention plane, borrowing from control plane and data plane (no relation to the transformer component). The point of the name is that it is a distinct plane of the system, not another feature bolted onto the model.
Cross-surface AI has the same problem in reverse. The tasks are one; the surfaces are many; my attention across those surfaces is what is scarce. Nothing arbitrates. Every surface starts from an unaudited pile.
At first I took the symmetry for a cute observation. I now think it is an architecture claim. Both directions need the same two things: an up-to-date picture of what I am on, and a mechanism that makes decisions against that picture. Control theory solved this shape decades ago and named the solution: keep the estimator separate from the controller. One component maintains the state estimate; other components act on it. The voice case and the cross-surface case are two controllers consulting one estimate, in opposite directions. And the thing missing from the products I use is not the controllers. It is the estimator.
Fig. 1: One estimate, two controllers. Voice funnels many tasks toward one user; cross-surface fans one piece of work across many surfaces. Opposite directions of flow, consulting the same estimate of what I am on.
Vocabulary
If I am going to think about this out loud, I need words for it.
Focus. My focus at any moment is a small set of live threads: which piece I am drafting, which repo I am in, which conversation I am resuming, which decision is up. It is the working-memory view of what I am on right now. It is stable within a task and changes when the task changes. Focus is state, not machinery.
Focus plane. The machinery that maintains that state: it notices when I switch, keeps the picture current, and can answer, for any candidate piece of context, how it relates to what I am on. Borrowing from control plane and data plane again: a distinct stratum of the system whose one job is knowing what the user is on. The focus is the estimate; the focus plane is the estimator.
Relevance. For any incoming candidate context (a prior chat, a file I edited, a Dispatch result, a decision I made two weeks ago), the question is: does this belong in the current moment's picture? Not "is it about a related topic," which is what search gets you, and not "did I see it recently," which is what history gets you. The question is whether right now, given my current focus, this candidate would help.
Importance. Distinct from relevance. Importance is what I care about generally: my kids' school schedule matters more than a coding side-project deadline. Importance is stable across days and does not depend on where I am sitting in my work. It is the thing I would set explicitly if the interface asked me to. Relevance is what changes with the focus; importance is what changes when my life changes.
Two-axis surfacing. The upshot: what an AI surface should pull from prior context is not the top-K by similarity, and is not the last-K by recency. The two axes that matter are relevance and importance, and they act at different moments. Relevance governs what fills the picture: which few items claim a slot in the bounded context a surface starts from. Importance governs what may claim me: what interrupts, what holds, what waits for a lull. I first wrote this as one ranking, top-K by importance × relevance, and building the thing corrected me: the axes never multiply into a single score. Relevance turned out to be a structural question (does this candidate share a live thread with what I am on), coarse by design, because a number there is fake precision. The voice-side design I published earlier scored relevance numerically; the version that survived contact with use replaced the score with a relation. Importance is user-configured (the system may notice stable patterns and propose a default, but it becomes a weight only when I confirm it), and it is consulted at the interrupt decision, not the retrieval. Both are needed. Neither may impersonate the other: "related" is not "important," and no candidate gets to declare its own importance. The opening scene already had both axes in it: deciding which three of the eleven files still bind is the relevance question, and the Dispatch result landing in a context that had moved on is the importance question.
Fig. 2: Two axes, two moments. Relevance is recomputed hourly and spent filling the context a surface starts from; importance is set by the user and consulted only when something asks to interrupt. Each axis has its own owner and its own moment, and the lanes never merge into a single score.
None of this vocabulary is new in isolation. What I do not see, in the products I actually use, is a component whose job is to compute the relevance axis in real time. Retrieval systems index; memory systems store, and lately they summarize and even supersede; search matches. None of them ask "what is the user's focus, and what serves it?"
Applying the pattern to cross-surface AI
Take my morning again, with the vocabulary applied.
When I move from Chat to Cowork, my focus transitions but does not reset. Same piece, same argument, same audience, but a different surface and (crucially) a different tool. A focus-plane-aware Cowork would ask, when I open it: is this a continuation? If yes, from where? And on getting the answer, it would pull the top-few items from the Chat session by relevance to the current file operations, not the whole transcript. Not the raw history. The subset of the history that serves the focus.
The signal that identifies the focus does not have to be exotic. In my case it is mostly: what did I have open, what did I most recently work on, what does the surface I am entering have to do. A first-pass discriminator ("you were writing about X, and you are now opening a file named X.md, so likely: continue") gets you most of the way. I can now say that from evidence rather than hope: in the voice-assistant work, the first-pass version shipped as a small deterministic function, no model in the loop, and when the focus is empty the context selection quietly degrades to plain recency, which is exactly the behavior every surface has today. The hard parts are what happens when the signal is ambiguous, and when the previous context is the wrong context (I switched projects, and the model should let go).
I do not need the AI to remember everything. I need it to know what to remember for this. That is the discriminator, and it is currently missing.
The examples I actually have
The context that survives the seam worst is decisions, not facts.
The fact-shaped ones ("the file is at path X") are cheap to repeat and cheap for the model to accept. If I tell Cowork the path, it uses the path. Fine.
The decision-shaped ones are the expensive ones. "We decided to go with the second title, not the third, because it read as more editorial." "We decided to route the piece to the personal blog, not the higher-friction venue, because the argument is dated and the venue turns it around slowly." "We agreed the reader is a practitioner, not a decision-maker, so drop the ROI framing."
Those decisions are the entire useful output of the Chat session. They cross the seam as conclusions stripped of the reasoning that produced them, sometimes already superseded, and so the new surface argues with me for choices I already resolved. That is the tell that something is missing. It is not that I want a bigger prompt or a persistent history dump. I want the conclusions propagated, weighted by my current focus.
And there is a property of decisions that makes this worse than it sounds. Facts age gracefully: a slightly stale file path fails loudly and gets corrected. Decisions do not age; they get overturned. A title I rejected on Tuesday can be un-rejected on Thursday, and any system that carries my conclusions forward has to know which of them are still standing. A propagated decision that has since been superseded is the most expensive kind of context there is: confidently wrong, and wearing my own authority. So conclusions need more than storage. Each one needs a live-or-superseded answer, and the mistake is to store that answer as a bit someone remembers to flip. In the version I run, liveness is derived from the record at read time, and the component doing that read is the focus plane.
Fig. 3: Facts age loudly; decisions are overturned quietly. A stale path fails at the point of use. A superseded decision propagates unflagged, wearing my own authority, unless something owns the live-or-superseded answer.
What is genuinely hard
Every time I make this argument I have to remind myself of the reasons it is not already built.
Privacy across surfaces. Some of what I say to Chat is not what I want Dispatch to have. Not because Dispatch is dangerous, but because the mental model of "each surface is a room, and I am choosing what to bring into each room" is often correct behavior and not a bug. A focus-plane system that lifted everything into everywhere would break that trust. So the arbitration has to be explicit about what it is pulling and why, and revocable per surface. This is design work, not just plumbing.
Cross-surface identity. For the system to compute relevance across surfaces at all, it needs a stable notion of "me" and "my work" that spans them. Today that is fragmented: different product teams, different session models, sometimes different accounts. A shared identity substrate would help; enterprise readers will note that a shared identity substrate is also a security surface. Both are true.
Latency. The moment a surface opens, I want context. If the relevance computation takes several seconds while I sit staring at the cursor, the feature is worse than not having it, because it slowed me down while promising to help. This constrains what "relevance" can do at surface-open time and pushes some of the work upstream (into background summarization) or downstream (into progressive disclosure). It also means the naive "just embed everything and vector-search" answer is not obviously right.
Filter-bubble effects from prior context. If the system pulls in what worked last time, it makes the new session look like the last session. That is often useful. It is occasionally very bad. When I am trying to think about a problem differently, the last conversation is exactly the ballast I want to drop. A relevance engine that only reinforces prior framing is a straitjacket masquerading as help. Some way to say "start from empty, this is a different focus" needs to be first-class.
Knowing when the focus has changed. The signal that "the same piece, on a different surface" is a continuation is different from the signal that "a different piece, on the same surface" is not a continuation. Getting both right is a UX problem before it is an algorithm problem. It is not obvious to me that the discriminator lives inside any single surface; it may need to be a shared component that all four surfaces consult.
I do not have crisp answers to any of these. I have the shape of what is needed and a clear sense that "just do memory" is not it.
This is the discriminator, not the store
Memory (the store) is the substrate a focus plane runs on. But memory alone is not focus. A big pile of remembered facts, unfiltered, arriving at the start of every new session, is worse than no memory at all: it drowns the current signal in prior signal, and it makes the AI feel like it is guessing at what I want out of an over-full drawer.
Notice that the three frictions the essay opened with are not storage failures. Drift is a liveness question: which conclusions still stand. Bloat is a selection question: which three of the eleven files still bind. Erosion is a provenance question: a pointer to where the conclusion came from instead of a copy of it. All three are questions you ask at read time, against the current focus, and a bigger or tidier store answers none of them.
The interesting layer is not the drawer. It is the hand that reaches into the drawer with the right filter for the moment. That hand is the focus plane, and it is what I do not have across surfaces yet.
What I am not sure about
Two things I am uncertain of, worth writing down so I remember to test them.
First, whether the focus is really one flat thing, or several nested contexts. My work focus and my personal-life focus are clearly distinct. Within work, my drafting context and my building context feel distinct too. Nested contexts are more expressive and much harder to reason about; I do not know yet whether the simpler flat model breaks in practice or holds.
Second, whether the right home for the estimator is the AI provider, the operating system, or a third piece that sits between them. There is a case for each. The provider has the models. The OS has the context (which surface is frontmost, which app is active). A third piece has the neutrality to arbitrate across providers, which matters when tomorrow's assistant is not from a single vendor. I would guess the third piece, but that is a guess.
The smallest version already exists (badly)
The first draft of this essay ended with the question I most wanted answered: what is the smallest useful version of a cross-surface relevance engine that a single person could ship and validate, without needing every AI provider to agree on a schema?
Then I noticed I already run one. By hand.
Every project I work on has grown the same organs. A decisions log that records what was settled, when, and what superseded what. A source-of-truth page per draft, so stale copies cannot argue. A session-close note that the next session reads before doing anything else. When I start a work session, the first thing any assistant does is read that state; when the session ends, the last thing it does is write conclusions back. Conclusions, not transcripts. That is a focus plane. It is manual, it is markdown, and it works: the switch tax this essay opened with has mostly disappeared from the projects that run this way.
So the smallest shippable version is not a research program. It is a small state store with a discriminating read, exposed behind a protocol every surface already speaks (MCP would do), holding the live threads, the standing decisions, and the open loops, each entry a pointer back to where it came from. The store half already exists: there are shared-memory MCP servers today (OpenMemory is one) that give several assistants a common pile of remembered facts. Which proves the point about the plumbing, because what they do not have is the read side: no model of what I am on, no switch detection, no way to ask what serves the current focus. The plumbing is not the hard part. The hard parts are the schema, and the discipline of keeping the object small enough to read in one breath.
A schema is something one person can draft. I have drafted it: a short spec and three JSON schemas, permissively licensed, sitting in a directory on my laptop.
Writing it down changed it, which is the part I did not expect. The first draft treated the interesting fields as things the system stores. In revision they kept turning out to be things the system derives, because a stored field is a field that can quietly disagree with the record it came from, and a stale entry wearing my own authority is the exact failure this essay opened with. The spec got smaller as it got more correct.
What I have not done is run it against anyone else's surfaces. That is the step where a schema either becomes an interface or stays an essay, and it is not a solo job.
What keeps striking me is how unexotic the missing piece turned out to be. Not a bigger model, not a longer context window, not a new kind of memory. A small object that knows what I am on, and the discipline to keep it small enough to read in one breath. That seems worth a few evenings.