The mental shift.

Almost every app today treats AI as a feature. Houston is built around a different starting point.

How most apps use AI today

Start with how every app is built, not just AI ones.

Engineers write code. The code defines workflows — the paths a user takes through the app. Inside those workflows, the code calls capabilities: a database, an API, a function, a library.

This shape is as old as software. Every app you've ever used is built this way.

When AI shows up, it's one more capability. The code calls an LLM the way it used to call a function.

The workflow is the app. The AI is a tool the workflow reaches for.

This is true whether the AI feature is a one-line prompt or a sophisticated agentic loop. The workflow is fixed at build time. The AI runs inside it.

Why this hits a ceiling

The workflow was written by an engineer before the user showed up. It covers the cases the engineer thought of.

Every other case falls outside it.

When a user hits one, the AI can't help. Not because the model isn't capable — because there's no path through the workflow that reaches what they need. The AI sits inside a box the engineer built, and it can't step out.

Growing the box means shipping new code. Engineering time, prioritization, a release, an update. For most edge cases, that process never starts.

This isn't a quality ceiling. It's a ceiling on what the user can ask for without calling you.

What AI-native means

An AI-native app flips the relationship. The AI isn't a feature inside the app. It's how the user works with the app.

It can do everything the user can do. It can also do things you never wrote code for.

When an edge case comes up, the AI handles it by adapting. Not by waiting for you to ship a fix.

Claude, meet Claude Code

AI-native apps became possible because of the gap between Claude and Claude Code. Here's why.

Claude is the model you call through an API. You send a prompt, you get a response. It's stateless. It doesn't see your files, it doesn't run commands, it doesn't know your machine exists.

Claude Code is Claude running locally with a set of tools: read a file, write a file, run a shell command, edit code, search a folder. It lives inside a working directory and can do real work there.

An API call to Claude can answer "what columns should this export have?" Claude Code can open the script, add the columns, run the script, and put the file on the user's desktop.

Houston is built on the Claude Code architecture, and Codex or any other local coding agent shaped like it works too.

Two apps, one job

Here's the same job in both shapes: turn bank statement PDFs into a clean Excel workbook.

Both apps work. Both produce a workbook. The difference shows up the moment the user wants something the engineer didn't plan for.

The user wants a new column

In SimpleBooks, the user has three choices. Edit the Excel by hand. File a feature request. Take the file to a different AI.

In SmartBooks, the user says so. Claude Code edits the Python script on their machine. The next export has the new column. Done.

The edge case is for one client only

In SimpleBooks, there's no version of this that works.

In SmartBooks, Claude Code adds a rule that only applies to that one client. Nothing else changes. The edge case is handled.

The key difference

In SimpleBooks, the workflow is frozen. The AI fits where the engineer said it could.

In SmartBooks, the workflow is soft. The AI is in the middle. The code around it is something the AI can change.

This is the shift. Everything else in Houston follows from it.

What this changes for you

You stop trying to anticipate every user need. You stop building rigid workflows that break on edge cases you couldn't see coming.

You ship a set of capabilities instead. The AI figures out how to combine them for what the user actually wants.

Your app becomes a toolkit. Your users' AI becomes the operator.