Edge cases at runtime.

The hardest problem in every real-world app is the one you couldn't predict. Houston gives the user's AI the authority to handle it on the spot.

The edge case problem

Every real app has edge cases the vendor didn't anticipate.

• One client needs a different column in the export.
• Brazilian clients need the date written as DD/MM/YYYY.
• When the total is over $10k, add a discount row.

In traditional apps, the user has three options. Email support and wait. Do without. Take the output to another tool and fix it by hand.

None of these are good.

What Houston does differently

In a Houston app, the user's AI can edit the local code that handles their workflow.

A Python script that generates an export? The AI can edit it. On the user's machine. For this user only.

Next time the user exports, the new code runs. Done.

The user never talked to you. You never shipped a custom build. They got what they needed.

What the AI can and can't touch

The AI can only write inside the agent folder: ~/Documents/Houston/{Workspace}/{AgentName}/.

Inside that folder, it can touch:

• Scripts the user's workflow depends on.
• Data files.
• Learned rules (prompt.local.md).
• Page manifests (page.json).

It cannot touch:

• The Houston framework itself.
• The app binary.
• Files anywhere else on the filesystem.

This boundary is enforced by the framework, not by a prompt. The AI isn't asked nicely to stay in its folder. It physically can't leave.

Rules as data, not code branches

There's a pattern that makes this work well over time. Keep variance in data, not in code.

The script stays small and general. The rules live in a file like rules.json. The script reads the rules and applies them.

Most of the time, the AI edits the rules file, not the script. The script only changes when the shape of the rules changes, which is rare.

Without this pattern, six months of edge cases becomes spaghetti. With it, the script stays clean and the rules file grows into a record of everything the user has asked for.

When a rule repeats across clients, the AI can suggest lifting it to a default:

Tests and rollback

Code changes are higher stakes than rule changes. Houston treats them that way.

When the AI edits a script, three things happen:

1. The change is committed to git with a plain-English message.
2. The user sees a one-line summary of what changed, with an undo button.
3. Where possible, the AI writes a test alongside the change and runs it. If the test fails, the change doesn't land.

Rule changes are eager — they apply immediately. Code changes pause for a beat. That asymmetry is on purpose: rewriting logic deserves more care than rewriting an English sentence.