Humans and AI, as equals.

One decision about how the app stores and shares state is what makes everything else in Houston possible.

Two kinds of users

In a Houston app, the user isn't just the human. It's the human and the AI, both.

They use the same app. They see the same data. They take the same actions.

Neither has powers the other doesn't have.

The shared workspace

Houston stores everything in files. A folder on the user's computer. Not a hidden database. Not a server.

~/Documents/Houston/MyWorkspace/MyAgent/ .houston/ clients/ jdoe.json # one file per client acme.json invoices/ inv-2026-001.json pages/ client-detail/ page.json # what the page looks like prompt.seed.md # how the AI should handle it prompt.local.md # learned rules CLAUDE.md # agent instructions

Both the human and the AI can read these files. Both can write them.

When the human creates a client through a form, a file is written. When the AI creates a client from a chat message, a file is written.

Same file. Same folder. Same format.

Reactivity is built in

When either side changes a file, the other side sees the change instantly. Houston uses a file watcher that invalidates the UI and re-renders. You don't have to wire sync yourself.

What "equal" actually means

In traditional apps, the AI is a guest. It gets access through an API. The app decides what it can see and what it can touch. The app is the host, the AI is the visitor.

In Houston, there's no host-guest distinction. The AI and the human both work on the same workspace at the same level.

The AI isn't calling your functions. It's operating your app.

Why this decision matters

This single decision — symmetric access to shared state — is what makes everything else in Houston possible.

Because of it:

Take this away and none of the rest is possible.

What stays the same

You still write React. You still write TypeScript. You still write Rust if you want a backend. Houston is built on the tools you already know.

What changes is what you're designing.

You stop designing workflows. You start designing capabilities.

You stop asking "what screen does the user click through?" and start asking "what files does my app care about, and what can the AI do with them?"

Your app is a set of primitives. Your users' AI composes them.