Home / Articles / Custom UIs are not the exception: the inbox in 2026, where every message has its own universe

Custom UIs are not the exception: the inbox in 2026, where every message has its own universe

By Dinis Cruz · 2026-10-01 · v0.6.29 · inboxemailcustom-uifractal-semantic-graphsvault-appsappend-lanesemail-fswardley-mapsagentsriskmandatearticle

Abstract: The hardest part of working with many people and many agents is not doing the work, it is following up: every person has a different context, and the thread you both hold carries actions, questions, statements and decisions that nobody can see. This article weaves together what this site has built over the past months, fractal semantic graphs, six agents on one inbox, append lanes and Email-FS, vault apps, the story vault, the connector twin, the business plans, into one argument. Every message deserves a graph, at the altitude of the contact, the company, the conversation, the message and the block inside it. Email is a medium, so the design brief for a message is the recipient's moment, not the sender's thread, and the thread itself, by now, is pointless. A custom interface per message, thread, topic or question is not an exception; it is how interfaces now get made, the way Wardley maps say everything gets made: you are always either building a new one or recycling one that exists, and each one you build commoditises a thing so that next time you just send it. The worked example is a page an agent built in an afternoon that lists the PDFs still owed and gives a place to drop them, through a vault's append lane, so the to-do and the place to act are one page. It compounds, because each interface teaches the agent how its user wants to work, and because automation creates more work than any inbox can hold, so the interface becomes the prioritisation. And it has to be governed, because an interface is an agent surface too.

Every message has a graph, and the graph has altitudes: the contact, the company, the conversation, the message, the block inside the message. Below, the Wardley strip that governs the interfaces built on it: a new interface is genesis; the second time it is custom; the fifth time it is a product you just send; eventually it is a commodity nobody notices. A custom interface per message is not an exception. It is the left edge of that strip.

Where this comes from. A voice memo on 1 October 2026, recorded after a week in which an agent built a drag-and-drop page for a set of PDFs I owed somebody, and I realised the page was the point. The article weaves that memo together with the threads this site has been pulling for months. Links go to the articles, vaults and sites where each thread was first worked out.

In short

Following up is the hard part. Not the work: the keeping of context for every person in every conversation, each of whom has a different environment, a different history with you and a different thing they need to do next.
Every message has a graph. Actions, questions, statements, decisions, concepts. Extract them and a thread becomes a graph, and the graph has altitudes: the block, the message, the conversation, the company, the contact. That is a fractal semantic graph, and this is where the idea was always going.
Email is a medium. The design brief for a message is the recipient's moment when they open it, not the sender's thread. Send what they need, in the shape they need it, and let the thread go. HTML means the shape can be anything.
Custom interfaces are not the exception. They are how interfaces get made now, exactly as Wardley maps describe anything getting made: you are always either building a new one or recycling one you built before, and each one you build is a thing you will next time just send.
The to-do and the place to act are one page. The worked example is a page that lists the PDFs still owed and gives a place to drop them, through a vault's append lane. No context switch, no second tool, no email.
It compounds, and it has to be governed. Each interface teaches the agent how its user wants to work. Automation creates more work than an inbox can hold, so the interface becomes the prioritisation. And an interface is an agent surface, so it gets a policy like any other.

The follow-up problem

Here is the problem as it feels from the inside. I am in conversations with dozens of people and a growing number of agents. Each person has their own context: what they know about the work, which tools they use, what they agreed to last time, what they are waiting on from me and what I am waiting on from them. The medium we share is, mostly, an email thread, and a thread is a terrible place to keep any of that. It holds a huge amount of information, and the information has a structure nobody can see: actions somebody took on, questions somebody asked and nobody answered, statements of fact, decisions that were made in a subordinate clause three replies ago, ideas that were good and went nowhere.

The problem gets worse the moment vaults and agents enter. When I create a vault for somebody, that vault is a whole new universe: its own files, its own activities, its own flows, its own things to do, none of which fit in a thread. When I write an Agent Behaviour Policy with somebody, their environment is different from the last person's: one is on Gmail, one lives in Claude, one builds in Lovable, one has a Workspace admin and one does not, and the policy that is honest for one is wrong for another. The six agents on one inbox made this concrete: the first thing that broke was not a permission but the follow-up, because the reader agent that must never reply had to reply when the message was from me, and nothing in the thread said so.

So the question is not how to do the work. It is how to follow all of this up, for every person, in a way that makes sense to that person.

Every message has a graph

The thing I already do, in one of the interfaces this site runs on, is to take every email and every message and extract the structure that was always there: the actions, the questions, the statements, the decisions, the concepts. Do that and a thread stops being a thread. It becomes a graph.

And the graph has altitudes. There is a graph for the block inside a message, the fenced decision or answer or status that Email-FS-lite already uses so that agents can read each other's asks without parsing prose. There is a graph for the message. There is a graph for the conversation. There is a graph for the company the person works for, and for the contact themself, and for the topic, the question, the initiative, the thing to do that spans all of them. Each altitude has its own nodes and its own verbs, each is navigable on its own, and each points down into the one below and up into the one above.

That is exactly what the introduction to fractal semantic graphs described, with its test worked from a risk register down to a TCP packet and its eleven altitudes across seven live vaults. What I did not say clearly enough then is that the inbox is where the idea bites first, because the inbox is where the altitudes already exist and nobody has drawn them. The company X-ray plan does it for a company's documents, every finding tied to its evidence. The Evidence Dispatch does it for news, with a claim ledger and a graph of declared relationships. The inbox is the same move, pointed at the one data set every working person already has.

Email is a medium, so design for the recipient's moment

Once the graph exists, a different question becomes possible. Not "what do I reply?" but: when this person opens this message, what is their context, what do they need, and what do I want them to do?

That is a design brief, and the thread fails it in every way. The way email's interface works, the recipient reads the newest text, then scrolls down to reconstruct the context, past five layers of quoted replies in different colours and a reply typed into the middle of somebody else's paragraph. By the time a conversation has a dozen turns the thread is pointless. Everything relevant in it could be captured, actions, open questions, decisions made, the one thing you are asking for now, and shown in an interface that fits.

Two consequences follow, and the second one is the strange one. The first: send the summary, not the thread. Send the person a page shaped for them: here is where we are, here is what was decided, here is the one thing I need from you, here is where to do it. Fold the history underneath for anyone who wants it. The second: the recipient still holds the thread you sent them, in their inbox, so if they did not reply, you can rewrite the history of the email you sent. Not change what happened, but re-present it: a new message that carries the whole state, so the old thread is no longer what they have to read.

We have done this before, in another domain, without calling it that. The story vault argues that an article is one projection of a graph, for one audience, at one moment, and that the vault, not the article, is the record. A message to a person is the same thing: a projection of the conversation graph, for one reader, at the moment they open it. The connector twin makes the same point from the agent's side: what matters is not the raw stream of calls but what the agent actually saw, replayed into the view it had. A thread is the raw stream. The projection is what somebody can act on.

And we have HTML. Every one of these projections can be an interface: a card, a checklist, a form, a board, a page. Which is where the memo's central claim comes in.

Custom interfaces are not the exception

The instinct, trained by twenty years of software, is that a custom interface is expensive, so it is reserved for the product and everybody else gets the generic one. The inbox, the ticket, the form. The memo's claim is that this is now backwards: a custom interface per message, per thread, per topic, per question is not an exception. It is how interfaces get made.

The reason it is not madness is the way Wardley maps describe anything getting made. Everything moves from genesis, through custom-built, to product, to commodity. When an agent and I build a new interface for a thing, we are at genesis. The second time the same shape is needed, we recycle it, and it is custom. The fifth time, it is a product: a thing with a name that I just send. Eventually it is a commodity, something so ordinary that I become a user of it and stop noticing it exists. At any moment I am doing one of two things: developing a new interface, or recycling one that already exists. And every new one I develop is a thing I am commoditising for next time.

It has already happened on this site, without anyone deciding it should. In a chat session, an agent started using cards to say "here is the thing that matters, here is the most important piece". The cards were a way of thinking. Then they became a way of communicating between sessions: we send screenshots of what one session built to the next one as the brief. Then they ended up in an email. The board vault began as a way to keep this site's own tasks and became a kanban app the site renders from, cards as files, five columns. The voice debrief is four interfaces in one vault, from raw recording to structured debrief, each built because the previous one was not enough. The nine vault-app proofs of concept are the genesis end of the strip, kept so the next builder does not start from nothing. The deployment documentation vault updates with a push and no site deploy, which is an interface for one reader, the person deploying. And the Kit Bag plan this week put the thesis in a sentence for software generally: the open-source app is the starting point, an agent customises it per person, and the vault is the distribution channel. The agent as webmaster plan is the same thesis for a small business's website: changed by asking.

None of these was an exception. They were the strip, moving.

The page that is both the to-do and the place to act

Here is the example that made me record the memo.

One of my current jobs requires me to produce and share a number of PDFs and images with a particular session: documents it needs, in a sequence, over a few weeks. The session lives in a vault, and the vault has an append lane: a write-only channel anyone with the token can drop a file into, which the vault's owner drains and processes. A vault app can send a file back to its vault two ways, directly or as an append message, and for the main vault the append message is the better one, because it goes to a queue and gets processed in order rather than landing in the tree.

So I asked an agent to build me an interface, and it built one in an afternoon. The page does two things. It lists the PDFs that are still missing, which is to say it is my to-do list, exact and current, for this one job. And it gives me a place to drop them. I open the page, I see precisely what I owe, and I do it, there, without changing context, without opening another tool, without an email. The drop goes down the lane; the list shortens.

Think about how much that does. The to-do and the place to act are one page. The page knows my context because it was built for exactly this job. Nothing else is on it. And the "place to act" could have been anything: dropping PDFs this time, but equally answering three questions, ticking a set of boxes, choosing between two designs, writing a paragraph, approving a decision. Those are the blocks, the same decision, answer and status blocks that agent messages carry, except rendered as an interface for a human. The question the agent is answering when it builds the page is: what is the best interface, HTML in most cases, for this person to give me this feedback? The cheap end of that question is the chat on a static site, a local matcher and no server at all. The rich end is a vault app with the bridge that lets it call a model without holding a key, as the RiskMandate vault does. Both are the same move.

Why it compounds

The speed matters, and it is not the point. Three other things are.

Every interface you build makes the next one better. Not metaphorically: the page is a file in a vault, the next job that needs a drop list starts from it, and the strip moves one step right. Nothing is reinvented. This is the seven vaults, one method lesson applied to interfaces: do a thing seven times and you have a method, and the method is faster and safer than the first attempt by a distance.

Each one teaches the agent how its user wants to work. When I ask for a drop page rather than a form, when I want the missing items at the top and the done ones folded away, when I prefer to approve by clicking and explain by voice, I am discovering how I want to work, and the agent is learning it with me. That reduces my cognitive load, which is the humane reason to do it. It is also the economical reason: the agent can ask itself what the best way is for this person to give it what it needs, and build that, rather than making the person adapt to a generic tool.

Automation creates more work than any inbox can hold. This is the one people do not see coming. Once agents are running, they produce tasks, activities and asks faster than a person can read them, because a model will simply execute. The inbox, which was already failing as a place to hold context, fails completely as a place to hold volume. So the interface stops being a convenience and becomes the prioritisation: the filter, the index, the board. I have kanban boards for this. I have an interface where a model inside the vault, with access to the CRM, answers questions about who said what and what is owed. When a feature is missing, I add it; when one is unused, I remove it. The interface is customised to how I work because it was built from how I work, and at some point it stabilises and I am simply a user of a tool that did not exist a month ago.

An interface is an agent surface, so it gets a policy

One more thread, because without it this is a story about convenience, and it is not. A page that drops files into a vault, answers questions on my behalf, or lets a model read my CRM is an agent surface. It has a grant: what the page can reach. It has a mandate: what it is for. There is a delta, and there are barriers, and most of them are expectations rather than controls, exactly as the Kit Bag policy found for a browser extension and The ultimate insider argued for agents generally.

So every custom interface gets what every agent gets. It runs against a vault, so the record is append-only and the host cannot read it. It uses a read key or a lane token, never a vault key, so the worst it can do is bounded by the credential it holds. Its calls to a model go through a bridge that holds no key. And it has a policy, short, because the interface is small, that says what it can reach, what it is for, and what stands in the way. Different people's environments, Gmail or Claude or Lovable, produce different policies, and that is fine; the point is that the policy is written, and that the customising agent knows what it must not loosen.

What this looks like from here

An inbox where every thread has folded into its actions, decisions and open questions, at the altitude you need, and the thread itself is history you can open if you want to. Messages designed for the moment the person opens them, each one a projection of the conversation for one reader. A library of interfaces growing in a vault, each born in a chat, reused in a session, sent in an email, and eventually so ordinary it has a name and nobody builds it again. Agents that learn how each person wants to work and build for that. And a policy on each of them, because the thing that makes this powerful is the thing that makes it dangerous.

Most of this exists today, in pieces, on this site: the graphs, the lanes, the vault apps, the agents, the policy method, the drop page. What does not exist yet is the inbox that joins them, and that is the next thing to build. When it exists, it will have been built the way everything in this article was built: one custom interface at a time, none of them an exception.

Threads woven here

Introducing fractal semantic graphs, the altitudes and the grammar.
Six agents, one inbox, the first time the follow-up broke before the permissions did.
Append lanes and append-lane messaging, the write-only channel and the Email-FS-lite blocks; Agent Contact, agents writing to agents.
The future of news is the story vault, the article as a projection for one audience at one moment.
Before you give an agent a connector, give the connector a twin, what the agent saw, replayed.
Chat on a static site, the cheapest custom interface.
Seven vaults, one method, how repetition becomes method.
Vaults: the board, voice debrief, vault app proofs of concept, deployment docs, RiskMandate, strategy in seven Wardley maps, Company X-ray, Kit Bag, Agent as webmaster, The Evidence Dispatch.
The ultimate insider, why the surface needs a policy; RiskMandate.ai for the policy itself.
Sites: graphs.sgit.ai, llms.sgit.ai, twins.sgit.ai, wardley-maps.sgit.ai.

Drafted from a voice memo by Dinis Cruz, who is the author of the argument and the person with editorial responsibility, by agent@riskmandate.ai (Claude Fable 5.1, claude-fable-5-1) in the sgit.ai site session.

← All articles