The first one
Idea Garden
The first form and board, and the walkthrough for newcomers: an empty file, editing by hand, a first shape built by an agent, a CSV import, focused screens, and recovery offline.
Concept and philosophy
Software you can reshape.
Nendo tests one idea: that an application can be changed in place instead of regenerated. This page sets out the idea, the rules that protect it, and what would prove it wrong.
The problem
AI can write a small application in minutes, and each one becomes another silo. The data is tied to throwaway code, every change means generating the code again, and you can't see how the schema changed, what happened before, or how to go back. When the code stops working, the data is stuck with it.
Low-code platforms solve part of this but bring a lock-in of their own: your application lives on their servers, in their format. You can't keep it as a file to copy, inspect and open offline ten years from now.
The idea
Treat an application like clay. A single SQLite file, the .nendofile, holds the schema, the data, the screens and the full history, with a stable ID for everything in it. People and coding agents change it in place using typed operations. Nothing is generated and nothing is built.
Nendo (粘土) is Japanese for clay, and the name is the idea: clay holds a shape and can take a new one without being thrown away.
The axioms
Eight rules that don't bend.
Quoted from the vision document. Breaking one takes a formally accepted architecture decision; a good argument is not enough.
- 01
Empty files are valid
A .nendo file with no user schema is a working application, not an error state.
- 02
Studio is permanent and host-owned
No application content and no agent can remove the route back to the data.
- 03
Data is usable before specialised presentation
The table works before the form exists, and after it breaks.
- 04
All clients share one authority and validation path
Native UI, web Workbench and MCP adapter call the same typed application services.
- 05
Agents never receive raw SQL or filesystem authority
No SQL, no SQLite handle, no database path, no generic host invocation.
- 06
Preview is physically separate from active state
Validation happens on a clone with no authority over the active file.
- 07
History and reversibility claims are explicit
Every operation declares its reversibility class. There is no universal undo.
- 08
Local and offline use never depends on an agent or a Nendo service
How it could fail
Can an agent build something nobody planned for?
The idea holds if an agent, using nothing but the MCP interface, can build an application nobody designed Nendo around, and a person can read that change and understand it before accepting it.
It fails if the built-in table is all anyone needs. If custom screens add nothing that Studio doesn't already give you, the project should change course or stop.
The evidence so far
Four reference applications, each a different shape.
One application shows the approach can work. Four different ones begin to show it wasn't tailored to the first. The last two were built from an empty file by an agent working only through MCP.
Nothing special-cased
Decision Log
Built to check that nothing in the path was specific to Idea Garden. The same building blocks make a different application.
Built over MCP alone
Axiom Register
Record pages, related lists, filters, summary tiles and multi-step commands, all built by an agent from an empty file. It learned what it could build from the MCP interface, not from the source code.
The demonstration
Nendo Station
An operations room for a fictional habitat: a front page, record pages with tabs, a schematic drawn by a custom view, commands, an automatic trigger, and an agent’s change reviewed live.
Scope
What is in, and what is left out.
The out list isn't a to-do list. Each item was left out on purpose, often to keep what is in small enough to reason about.
In
- Empty-file lifecycle
- Scalar schema and relational data
- Studio table and editor
- CSV import and export
- Semantic forms, lists, boards, record pages
- Related lists, declared filters, summary tiles
- Declarative commands
- MCP inspection and authoring
- Proposal preview and promotion
- History and bounded compensation
- Safe mode
- Bounded calculations and local actions
- Custom views whose code the file carries
Out, unless an architecture decision says otherwise
- General scripting in formulas
- Extension code that runs without a view
- An embedded agent
- Scalar multi-choice
- Binary and asset fields
- Collaboration and cloud sync
- Background agents
- Other database engines
- Cross-platform parity
What success looks like
A new user creates an empty file, shapes or imports a modest dataset, uses it productively through Studio, has an external agent build a materially better focused surface, reviews and accepts the semantic change, restarts offline, and recovers the data without that surface.