Home / Articles / Custom UIs are not the exception / Versions / v1.3.0
Custom UIs are not the exception: what changed in v1.3.0
From v1.2.0 (2026-10-02, 780ddcde4) to v1.3.0 (2026-10-02, 1fcf1f395), paragraph by paragraph.
7 paragraphs added, 0 removed, 1 changed in place, 86 unchanged. About 515 words added and 0 removed. Insertions are marked like this, deletions like this; unchanged runs are folded to one line; figures appear as their file names.
← v1.2.0 · all versions · v1.4.0 →
1 unchanged paragraph
Summary: 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 the thread does not show. 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. It starts with the user: not one interface but many, one per moment, each shaped for how the person wants to work right now. 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; and that afternoon was one item in an eight-day stream in which ten agents and one human built a working way of doing outreach, with more than a dozen interfaces. 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. It is the beginning of what email becomes: the transport stays, and above it the message is a node in a graph, shaped for each reader's moment, one word or the whole map, improved in a loop by the human and the agents. Stated so it can be wrong, the future of email is sender-served structure, read by the recipient's agent, with the inbox as one view of the graph. And it has to be governed, because an interface is an agent surface too.
10 unchanged paragraphs, under In short
• Stated so it can be wrong: the future of email is sender-served structure, read by the recipient's agent, with the inbox as one view of the graph. No install on day one; a plain email still works. The pieces are published, so the claim can be checked.
52 unchanged paragraphs, under The follow-up problem, Every message has a graph, Email is a medium, so design for the recipient's moment…
The future of email, stated so it can be wrong
"The future of email" has been announced before, by Wave, by AMP for Email, by Slack, by Hey, and the inbox outlived every one of them, because the inbox is the lowest common denominator everybody already has. Any version of the claim that needs the recipient to install something, or to see HTML that mail clients sandbox, dies the same way. So I want to make the claim in a form that does not need that, and that can be shown wrong.
Two things are true in 2026 that were not true when those earlier claims were made. The first is that more and more messages are read by an agent on somebody's behalf. Gmail, Apple Mail and Outlook now summarise and reshape mail at the receiving end, whether the sender wanted it or not. So the per-reader shape no longer depends on the sender guessing the recipient's moment. The recipient's own agent knows the moment, and renders for it. The second is that those agents are reshaping badly, because the message gives them nothing to work with: a thread of quoted replies with the decision in a subordinate clause, which they summarise by guessing. That is the problem the token bill article found for websites: agents fetching unstructured pages and paying for it in tokens and in errors. The answer there was publisher-served structure. The answer here is the same, one word changed.
The future of email is sender-served structure, read by the recipient's agent, with the inbox as one view of the graph. The message carries its actions, questions, decisions and status as blocks, so the agent reading it can render one word, a card or the whole graph with fidelity instead of inference. Email-FS is that structure. Agent Contact is how two agents find each other's keys to exchange it. The vault is where the graph lives when the message is only a view of it. And none of it asks the recipient to install anything on the first day, because a plain email still works; it asks their agent to recognise the structure when it is there, and to fall back to the text when it is not.
That is a claim with an edge to it. If recipients' agents never learn to read sender-served structure, or if senders never bother to send it, the inbox stays a thread and the earlier announcements will have one more companion. The pieces are published, so anybody can check which way it goes.
19 unchanged paragraphs, under Who builds them, An interface is an agent surface, so it gets a policy, What this looks like from here…
• The token bill nobody is sending, publisher-served structure, the same answer one word changed.
4 unchanged paragraphs