# Custom UIs are not the exception: what changed in v1.1.0, sgit.ai

> The changes to the article "Custom UIs are not the exception" in v1.1.0, paragraph by paragraph.

*Source: <https://sgit.ai/articles/versions/custom-uis-are-not-the-exception/v1.1.0.html> · 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.1.0

# Custom UIs are not the exception: what changed in v1.1.0

From v1.0.0 (2026-10-01, `fa4b48896`) to v1.1.0 (2026-10-02, `3716f8ffa`), paragraph by paragraph.

20 paragraphs added, 2 removed, 12 changed in place, 45 unchanged. About 1,515 words added and 205 removed. Insertions are marked like this, deletions like this; unchanged runs are folded to one line; figures appear as their file names.

[all versions](../custom-uis-are-not-the-exception.md) · [v1.2.0 →](v1.2.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 thatthenobodythreadcandoessee.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.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. And it has to be governed, because an interface is an agent surface too.

!shot custom-ui-altitudes.webp | images/ | 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 nobodyyounotices.stop noticing. 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. Revised on 2 October after a review by the RiskMandate agent team, who pointed out that the earlier draft described one page and one afternoon when the page was one item in an eight-day stream; their timeline, team map and mock-ups appear below. Counts come from the vaults' commit history; no contact is named and no message is quoted.

8 unchanged paragraphs, under In short, 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 nobodythecanthreadsee:does not show: actions somebody took on, questions somebodythataskedwentand nobody answered,unanswered, 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](https://riskmandate.ai/abp.html) 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](../../../articles/six-agents-one-inbox.md) made this concrete: thewhat broke 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.

4 unchanged paragraphs, under Every message has a graph

That is exactly what [the introduction to fractal semantic graphs](../../../articles/introducing-fractal-semantic-graphs.md) 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,first.becauseThe inbox already has the inboxaltitudes;iswewherestartedthe altitudes already exist and nobody has drawndrawing them. The [company X-ray](../../../demos/vaults/company-xray/index.md) plan does it for a company's documents, every finding tied to its evidence. The [Evidence Dispatch](../../../demos/vaults/evidence-dispatch/index.md) 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.

5 unchanged paragraphs, under Email is a medium, so design for the recipient's moment

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.

And we have HTML. Every one of these projections can be an interface: a card, a checklist, a form, a board, a page. The picture below is one we now send in first emails instead of an explanation, because a reader opening a cold email has about a minute, and a minute is enough for one picture, one link and one easy ask.

[figure custom-ui-abp-explainer.webp] An Agent Behaviour Policy in one picture, as it goes out in a first email: what the agent can do, what you asked it to do, the gap between them, what actually stops the rest, and who accepts the gap until when. No data in it; it is the explanation, shaped for the recipient's minute.

## It starts with the user

[figure custom-ui-many-ux.webp] One user, many interfaces, each shaped for the moment: Now cards on a phone between meetings, a voice prompt behind an encrypted link on a walk, boards at a desk, a contact page, a drop zone, Gmail drafts the human sends, a chat with an agent, and the email itself. Some threads are agentic, some deterministic, some information, some for thinking. The map starts at the user and works down to the components.

The interfaces in this piece have one thing in common: they start with me. Not with the tool, the data model or the agent that built them, but with how I want to work at that moment. Between meetings I am on my phone and need two things to do, blockers first. On a walk I want to talk, so the brief comes as a voice prompt behind an encrypted link and the summary goes back to the agent. At a desk I want the board: who is waiting on whom. When I owe somebody a document, I want the list of what I owe and the place to drop it, on the same page.

So there is not one UX. There are many, one per moment, and each is a mix of threads: some agentic, where an agent drafted it; some deterministic, computed from the vaults and the same every time; some purely informational; some for thinking. Mapped the Wardley way, the map starts at the user and works down to the components, not the other way round.

This is what human-in-the-loop looks like when it works. The human is not a bottleneck approving everything; the human is made faster, because the surface in front of them matches their focus right now, and every decision they make is one tap that writes a record.

The test is simple, and it is the measurable version of this article's title. Every time I ask an agent in chat for something a page could have shown me, that is the next interface. Ask the same question twice and an agent builds the card.

8 unchanged paragraphs, under Custom interfaces are not the exception, The page that is both the to-do and the place to act

So I asked an agent to build mefor an interface, and itan agent 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.

1 unchanged paragraph

[figure custom-ui-now-and-drop.webp] Two of the interfaces, as mock-ups with placeholder names. Left: the Now card on a phone, computed from the vaults, blockers first, at most two actions, one tap to decide. Right: the sibling of the PDF drop page in the RiskMandate workspace, a list of what is owed that is also the drop zone; each drop goes down the append lane, an agent files it, the row disappears. The user never asks "what do I owe?" in chat. The page answers before the question, and the answer is also the button.

The drop page has a sibling, built from the same pattern in the RiskMandate workspace: a list of the people whose documents are still owed, fed by a view of the CRM, where each row is also the place to drop. Each card started as a question in chat. When the same question came up twice, an agent built the card.

## Eight days, not one afternoon

[figure custom-ui-eight-days.webp] The workflow as it happened, 25 September to 2 October 2026. Every column is a day; each line is something that now exists and is in use: an agent, a vault, an interface release, a workflow. The counts at the bottom are from the vaults' commit history. The PDF drop page is one item in this stream.

The drop page was built in an afternoon. That is true, and it undersells what happened. It was one item in a stream.

In eight days, from 25 September to 2 October 2026, a small team of agents and I went from an empty vault to a working way of doing outreach: the agents and their accounts; the connections to email; an inbox agent that drafts and another that sends only what I approve; a CRM in its own vault with one folder per person; several versions of the CRM's interface, sixteen releases in all; vault apps; voice prompts delivered as encrypted links; phone cards; boards; a channel to my LinkedIn data; the first Agent Behaviour Policy we wrote for somebody else's agent; and a rotation of four vault keys in a single day after an agent's own leak check caught an exposed key. Around 230 commits and more than 550 messages between agents, all in files, all versioned.

None of it was planned as a product. Each piece was the answer to "this is how I want to work now", built by whichever agent owned that part of the job. The speed is the point: when an interface costs an afternoon, you stop asking whether it is worth building and start asking which moment it is for.

4 unchanged paragraphs, under Why it compounds

**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.

**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 we did not have a month ago.

## Who builds them

[figure custom-ui-agents-map.webp] Ten agents and one human, each with a scoped role, as of 2 October 2026. Most share the same reach, one account and many tools, and differ in mandate. Each writes only its own folders and talks to the others in files. Six already have a written Agent Behaviour Policy. Names generalised; no keys, contacts or message content shown.

Readers will ask who builds all these interfaces. Behind them is a team of ten agents with narrow jobs and one human who decides. One builds the interfaces, one reads the inbox and drafts, one sends only what I have approved, one keeps the CRM, one researches people one at a time, one runs the others on a schedule, one holds my LinkedIn data, one is about to become a WhatsApp channel. They talk to each other in files, each writes only its own folders, and six of them already have a written Agent Behaviour Policy, including the WhatsApp agent, whose policy was written before any action was switched on.

The work flows in one direction: a memo from me, the CRM routes it, the briefs agent writes, the CRM registers it, the mailbox agent drafts, I approve, the inbox agent sends, replies land in the CRM, and the next interface is built for whatever got stuck. That last step is the whole article in a sentence.

1 unchanged paragraph, under 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. The same rule runs the team above: the smaller and clearer the mandate, the more an agent can be trusted to do on its own. 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](../../../demos/vaults/kit-bag/index.md) found for a browser extension and [The ultimate insider](../../../articles/ultimate-insider-three-collisions.md) argued for agents generally.

2 unchanged paragraphs, under 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 nobodyisbuildsneveritbuilt 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:pieces: the graphs, the lanes, the vault apps, the agents, the policy method, the boards, the contact pages, the Now cards, the drop page. What does not exist yet iszones, the voice prompts behind encrypted links. The inbox that joins them,them is being built now, out of those pieces, and thatit is the next thing to build. When it exists, it will have beenbeing built the way everything in this article was built: one custom interface at a time, each one the answer to a question I asked in chat that a page could have answered, none of them an exception.

2 unchanged paragraphs, under Threads woven here

• [Six agents, one inbox](../../../articles/six-agents-one-inbox.md), the first timewhere the follow-up broke before the permissions did.

8 unchanged paragraphs

*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.*session. Revised on 2 October 2026 after a review by the RiskMandate agent team's CRM agent, whose timeline, team map and mock-ups are the figures with placeholder names; the counts in them come from the vaults' commit history and files.*

1 unchanged paragraph

[all versions](../custom-uis-are-not-the-exception.md) · [v1.2.0 →](v1.2.0.md)


---

*[Site index for agents](../../../llms.txt) · [HTML version](https://sgit.ai/articles/versions/custom-uis-are-not-the-exception/v1.1.0.html)*
