CorTex

CorTex is a personal AI system I’ve been building to run my home — a sensing, reasoning, and acting loop on hardware I own. Rather than executing commands like a typical smart home, it keeps a live model of the house — rooms, devices, environment, daily rhythms — and reasons over it. Data stays home, and the underlying AI engine is swappable, so the system isn’t tied to any one vendor or any one moment in a fast-moving field.

What makes it different

• A live model of the home, not a dashboard. CorTex keeps a queryable model of rooms, devices, environment, and daily rhythms — a reasoning object the system thinks with, not a screen to look at.
• Judgment over rules. It fuses sensor data, spatial context, and routines so it can act with judgment rather than firing fixed if-this-then-that automations.
• Local and private. Fully self-hosted on owned hardware — no household data leaves the network.
• Vendor- and model-agnostic. Modular by design, so the reasoning engine swaps out as the state of the art moves.
• Tactile speed. Known actions route through a fast local path, reserving the heavy model for the judgment calls that actually need it.

Where it stands

CorTex is live in my home and under active development — I keep expanding what it can sense, model, and decide.

---

Dev diary

July 10, 2026 — One product, six interaction models

Today’s CorTex work was less about getting another module online and more about admitting that the surfaces are starting to matter.

The system can talk to its pieces now. That part is working. But the more places I try to make CorTex show up — iPhone, iPad, Apple TV, the Debian tablet, CarPlay, wall displays — the more obvious it gets that “same app everywhere” is the wrong goal.

The iPhone wants to be quick and personal. The iPad wants to be more of a console. The TV needs to work from across the room with a remote. The shop tablet has to be usable while I’m standing there doing something else. CarPlay should barely ask for attention at all. And the wall displays are their own thing: mostly glanceable, occasionally interactive.

So the design work is shifting a bit. Instead of trying to stretch one interface across all of those places, I’m trying to define the shared language underneath them. Planner is the first test case: lanes, task cards, due states, focus, detail panels, completion flows, move flows. Those ideas should feel familiar everywhere, even when the actual screen changes a lot.

That feels like the right kind of consistency. Not one screen copied six times. Not six unrelated apps either. More like one product that knows what kind of surface it’s on.

This is probably the next abstraction CorTex needs: surface families. Shared concepts underneath, native behavior on top. If I get that right, the whole thing should start feeling less like a set of endpoints and more like a system that has some sense of place.

June 9, 2026 — Sprawl, collapse, accelerate: a pattern I keep hitting

CorTex didn’t start as its own thing. It began inside OpenClaw — the plan was for OpenClaw to be the runtime, and I’d build CorTex on top of it.

As I built outward — a reasoning layer, a personal-assistant layer with calendars, control surfaces for the systems in my home, a heavy data-ingest module, another module that pattern-matches on what that one pulls in — it kept becoming clear that to build properly, I had to own the stack top to bottom. OpenClaw’s role shrank with every module, until it was just one small reasoning surface inside something much larger.

Somewhere in there I started noticing a rhythm, and it has repeated enough times that I now trust it:

1. Sprawl. I build outward fast, and the edges get messy — ad-hoc glue, workarounds, parts wired together by hand.
2. Collapse. Eventually the mess gets loud enough that I stop and make one architectural decision that absorbs it — a clean boundary, a real contract — and the sprawl collapses into coherence.
3. Acceleration. With that new foundation under me, everything I build next goes faster.

Then I keep building, and it starts over one layer up.

I’ve watched it happen clearly at least twice.

Module contracts. Owning the stack meant I needed well-scoped modules — but the moment there were more than a couple, they needed a standard way to talk. That was the first time I reached for FastAPI, and it turned a tangle of one-off connections into a durable contract between modules. Sprawl → collapse → and the work sped up.

The agent runtime. OpenClaw was still the heart of the reasoning layer, but its exec-approval boundary was too restrictive to build against reliably, so I kept papering over it with shell-script wrappers to get past the boundary safely — which was, of course, just more sprawl. The fix was to build my own agent runtime inside the reasoning module. Now I can swap the agent harness at will — a frontier model one day, a small local reasoner the next — without rebuilding the whole stack around a single reasoning center. Sprawl → collapse → faster again.

Here’s what I think is actually going on: the sprawl is a signal. It isn’t failure — it’s the project telling me I’ve outgrown the current abstraction and I’m building around it instead of with it. Every time, the fix has the same shape: find the boundary I don’t really own yet, give it a clean contract, and let the mess collapse into it. The speed-up afterward isn’t luck — it’s what you get when you stop fighting your own glue.

I don’t think I’ll grow out of this. It seems inherent to building something this layered: expand, collapse, accelerate, repeat. So I’m going to keep watching for it — because now that I can see the shape, I think I can catch the next collapse sooner, before the sprawl costs me as much.

June 6, 2026 — Bringing coherence across surfaces

CorTex now has a proper internal API for its modules, plus a build pipeline for the different surfaces that consume the data. On any single endpoint, it looks good.

The challenge surfacing now is bringing UI/UX coherence across all of them — and they aren’t the same kind of surface. Some are interactive: the native Debian app, the iOS build. Some are display-only: the big portrait-mounted wall displays. And a few haven’t revealed their true shape yet.

This feels like the moment to pull production into a streamlined dev tool — a node registry, a capability map, and page previews — so I can see and shape every surface from one place, instead of endpoint by endpoint.