Underlay is an exploration of how software changes when intelligence becomes part of the interface and the work itself. Memos is where we document the questions, experiments and decisions that emerge while building it.
Why this exists
Product documentation explains how a system behaves. Code records what was shipped. Neither always preserves the reasoning that connects an intent to an interface, a runtime decision or a boundary of authority.
Memos exists to keep that reasoning legible while it is still alive. A note can start from a UX problem, a runtime behaviour, a visual experiment or a product hypothesis. Architecture is one of the tools used to answer it, not the only door in.
What belongs here
The subject is the work around useful agents: how an experience hosts intelligence, how a runtime plans and coordinates, how tools meet the world, how context is composed, and how execution stays observable and governed.
That includes interaction design, generated interfaces, brand, harnesses, contracts, MCP and human control. MCP is part of the picture. It is not the definition of the system.
From questions to decisions
The writing will separate what exists today from what a system is moving toward. A current constraint, a target model and an open question are useful in different ways. They should not be presented as the same thing.
A memo can start in the interface and end in the runtime, or the other way around. The test is whether the reader can see a trade-off, not whether the note used the right vocabulary.
Designing Underlay
Underlay is a design and technology project. The product should make work visible and keep chrome quiet. Three principles will keep coming back.
Less interface, more work. Reduce the weight of menus. Keep goals, content and actions in the centre.
Interfaces that respond to intent. The experience should adapt to the job, instead of forcing the job into a fixed structure.
Clarity creates trust. States, confirmations, limits and results should be readable. They should not hide behind the magic of a model.
A full design guideline, with discarded alternatives and motion, belongs in a later memo. Here it is enough to show the sensibility.
Close to the work
The questions collected here come from building, testing and revising real systems. That proximity matters because abstract ideas become useful only when they survive contact with interfaces, constraints and failure.
This is still an independent publication, not a product feed or a changelog. The work is the source of the questions, not the subject of every answer.
Open does not mean finished
Writing in public creates pressure to make every thought sound definitive. This space is meant to resist that. A memo can be provisional without being careless, as long as facts, interpretations and open questions remain distinguishable.
Clarity matters more than cadence. Memos will grow when the work produces something worth keeping, not because a publishing schedule needs to be filled.
