My last article was about the front door: texting my house. This one is about what's behind it, how almost everything in my home now runs through a single Claude Code loop, and why that changes the economics of building software.
Here's the thing nobody told me about coding agents: they aren't only for coding.
A coding agent is a reasoning loop with four verbs. It can read a file, write a file, run a command, and call an endpoint. That's the whole vocabulary. And once I sat with that, something clicked that I haven't been able to un-see:
Almost every app you use is an opinionated wrapper around those same four verbs.
A calendar app reads and writes events. A home app calls device endpoints. A finance dashboard runs a fetch and renders the result. A scouting tool scrapes, caches, and reads back. Strip the UI away and most software is a thin, branded shell over read/write/run/call, plus the judgment of knowing which one, when, and with what arguments.
A coding agent already has the four verbs. So if you give it the judgment, and a stable place to stand, you've absorbed most of what those apps were doing for you.
That realization is the entire reason Hopper exists. I stopped thinking of Claude Code as the thing that writes my code, and started thinking of it as the thing that operates my computer. Once it was operating the computer, it could operate the house. And once it could operate the house, I stopped building apps. I started wiring tools into one loop.
The loop never changes. Only the tools do.
This is the part that still surprises me daily. Every request my family sends, wildly different on the surface, collapses into the exact same shape:
- Read the context.
- Decide what needs to happen.
- Call the right tool.
- Return the result.
"Make a printable calendar for the month" means read the calendar API, run a Python renderer, and return a PDF.
"Who are the boys playing this weekend and how tough is it?" means read the schedule, call a scouting service, run a scrape job, and return a matchup card.
"Log my usual breakfast" means read what "usual" means, call the nutrition endpoint four times, and return a confirmation.
"Are Needohs back in stock at Target?" Don't judge, anything for my daughter. That means run a shortcut, read the log it wrote, and return the answer.
"Turn the house down for the night" means call four scenes in parallel and return done.
Five requests. One loop. The model isn't doing anything structurally different in any of them. It's selecting verbs and arguments. That's the whole trick, and it's why the system can grow sideways forever. A new capability isn't a new app. It's a new tool the same loop can reach.
The layers that make the loop trustworthy
If the loop is the center, everything else is a ring around it: the layers that turn a clever demo into something I'd let near my front door locks and my kids' schedules. Top to bottom:
The interface layer is whatever surface I happen to be touching: a text thread, a watch, or a browser. The only rule that matters here is that every surface funnels into one runtime. I don't fork the brain per device. I adapt the transport and keep the mind singular.
The routing layer is a small local server that catches the request, tracks which conversation it belongs to, intercepts a handful of cheap control words like status, cancel, and reset that should never cost a model call, and otherwise hands the request to the loop. It's deliberately dumb. Dumb routers age well.
The reasoning layer is Claude Code itself: the four verbs plus judgment. This is the only layer that "thinks," and critically, it's general. I didn't train it on my house. I didn't fine-tune anything. I pointed a stock model at a stable environment and let it reason.
The grounding layer is where the house actually lives, and it's just a file. One hand-maintained document that the agent loads as context: every endpoint and its quirks, the device IDs, the URL-encoding gotchas, and the rule that the office ceiling lights are wired behind a fan controller and won't light until the fan is on.
This is the layer people underestimate. It's not a fine-tune. It's an operating manual, and I can improve it by editing a file instead of retraining a model. A stock model plus a great grounding file behaves like a system that's worked in my house for months, at a rounding error of the cost.
The memory layer is the same idea, but it writes back. One fact per file: a preference, a correction, a piece of project state. "Log my usual breakfast" only works because somewhere there's a small file that knows what "usual" means. The grounding document is what the house is; memory is what the house has learned.
The tool layer is plain HTTP and local scripts. No SDK per integration, no bespoke connector framework. The house exposes a self-describing REST surface. Deterministic work, such as rendering a PDF or laying out a calendar, lives in real code the agent calls, not in tokens it generates.
The model supplies intent and routing. The tools supply correctness. That division, model for judgment, code for determinism, is the single most important design choice in the whole stack.
The guardrail layer is what makes "an agent with real actuators" a sentence I can say without flinching. No user-facing claim is made without evidence fetched this turn. Destructive operations refuse to run until re-issued with explicit confirmation. Locks, thermostats, bulk writes, and print jobs all stop and ask first. Restricted surfaces like a watch or text thread run on a tighter tool allow-list and auto-deny what they can't get a human to approve. Autonomy is real here, but it's fenced.
The autonomy layer lets the loop run without me in the thread. A saved instruction fires later, once or on a schedule, spins up a headless turn with full read/write/run/call access, and texts me the result. The catch that makes it safe is that every scheduled action is born in a pending-approval state and can't execute until I say yes. The model is never allowed to approve its own future work.
The delegation layer is my favorite tell that this is a runtime and not a product. When a job is better suited to another model, image generation, for example, Claude shells out to Codex or Gemini like any other command, writes the result to a file, and returns it down the same path.
The harness isn't loyal to one model. It treats other agents as callable tools. That's the difference between an agent and a router of agents.
Nine layers, and only one of them thinks. The rest exist to make the thinking layer capable and trustworthy. That ratio is the point.
The impact on the cost of a new feature
In the app model, every new capability is a project: a UI, a data model, a login, a place to live, a thing to maintain, and a thing to convince your family to open. The marginal cost of capability number twenty is roughly the same as capability number two.
In the runtime model, the loop already exists. Adding a capability means writing one tool and adding a few lines to a grounding file so the loop knows the tool is there. The interface is free because it's the text thread I already use. The reasoning is free because it's the same loop. The marginal cost of the twentieth capability rounds to an afternoon and a paragraph.
That's the compounding. My house didn't get smarter because the model got smarter. It got smarter because the cost of teaching it something new collapsed. Calendars, home control, finance briefs, sports scouting, nutrition, travel timing, image generation, and printing are not apps in my world. They're tools on one loop, and the list grows whenever I have a free afternoon and a need.
And the most absurd part is that when a tool doesn't exist yet, the loop can write it. A coding agent's native talent is producing code. So a missing capability isn't a roadmap item. It's a prompt. I can ask the system to build the very tool it's about to use, and then use it in the same conversation.
The honest caveats
This isn't magic, and the failure modes are real. A general loop with real actuators is exactly as dangerous as it is useful, which is why the guardrail layer isn't optional decoration. It's load-bearing.
The grounding file can rot if you don't maintain it. State that crosses a hardware bridge can lie to you, so the system treats unverified device state as stale rather than fact. And "the agent can build its own tools" is thrilling right up until you remember it needs the same review, logging, and version control you'd give any code with write access to production. It gets all three.
The self-improvement here is diff-able and auditable, not a black box editing its own weights.
But within those fences, the experience is genuinely different from using software. I don't go to my tools anymore. I describe what I want, and the loop reaches for whichever verb and tool fits.
The inversion
That's the whole shift, and it's bigger than my house.
The app model says the user comes to the software. You open the thing, learn its shape, and translate your need into its menus.
The runtime model inverts it. The software's capabilities come to one place the user already is. You describe the need in plain language to a loop that knows what tools exist, and the right capability reaches back out to you.
Apps make you come to them. A runtime comes to you.
I didn't build twenty features. I built one loop and kept handing it verbs. It turns out that almost everything, calendars, locks, lights, money, sports, dinner, and travel, is the same four verbs underneath, waiting for something general enough to reason across all of them.
It turns out a coding agent was general enough the whole time.
