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

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.