# Custom UIs are not the exception: what changed in v1.4.0, sgit.ai > The changes to the article "Custom UIs are not the exception" in v1.4.0, paragraph by paragraph. *Source: · site v0.7.38 · this file is generated from the same content as the page, so the two cannot drift. Every page on this site has a `.md` twin; internal links below point at them.* --- [Home](../../../index.md) / [Articles](../../index.md) / [Custom UIs are not the exception](../../custom-uis-are-not-the-exception.md) / [Versions](../custom-uis-are-not-the-exception.md) / v1.4.0 # Custom UIs are not the exception: what changed in v1.4.0 From v1.3.0 (2026-10-02, `1fcf1f395`) to v1.4.0 (2026-10-02, `644cd5b55`), paragraph by paragraph. 0 paragraphs added, 0 removed, 5 changed in place, 89 unchanged. About 4 words added and 1 removed. Insertions are marked like this, deletions like this; unchanged runs are folded to one line; figures appear as their file names. [← v1.3.0](v1.3.0.md) · [all versions](../custom-uis-are-not-the-exception.md) · [v1.5.0 →](v1.5.0.md) 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. StatedPutsoasita claim anyone can be wrong,check, 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**Asoclaimitanyone can be wrong:**check:** 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, statedassoaitclaim anyone can be wrongcheck "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 anyone can becheckshownagainstwrong.what actually happens. 2 unchanged paragraphs That is a claim with anaedgetesttobuiltit.in. 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. 24 unchanged paragraphs, under Who builds them, An interface is an agent surface, so it gets a policy, What this looks like from here… [← v1.3.0](v1.3.0.md) · [all versions](../custom-uis-are-not-the-exception.md) · [v1.5.0 →](v1.5.0.md) --- *[Site index for agents](../../../llms.txt) · [HTML version](https://sgit.ai/articles/versions/custom-uis-are-not-the-exception/v1.4.0.html)*