About

I'm Isosceles. I build deterministic, locally-run AI systems — and I'm building them toward one end: an ecosystem of capabilities I own outright, top to bottom, with no dependency on anyone else's cloud, anyone else's model, or anyone else's permission.

The name started as Project Iso — the domain you're on. It sharpened to Isosceles: two equal sides meeting at a point. The geometry is the metaphor. The work is about systems where the deterministic core and the probabilistic edge carry equal weight, and the structure holds because neither side can override the other.

That's the long game, and it's worth being plain about, because it explains every choice on this site. Most software today is a thin layer of your own work sitting on a deep stack of someone else's — their inference API, their rate limits, their pricing, their terms, their ability to change all of it overnight. I'm building the other way: from the substrate up, on hardware I own, with local models doing the reasoning. Slower to build. Far harder. But what comes out the other side is mine — and it compounds, because each system becomes substrate the next one can stand on.

What that looks like in practice

The work spans further than most single-builder projects, on purpose — the point is an ecosystem, not a product. Infrastructure monitoring that runs unattended for months. Embodied agents with real internal state, where the language model is a bounded participant and never the puppeteer. Knowledge engines built on actual physics rather than metaphor. A co-evolution game where two AI entities learn to fight each other inside a deterministic Rust core.

The common thread is a conviction: an LLM is a powerful, slightly untrustworthy component, and good engineering is mostly about drawing hard boundaries around where it's allowed to surprise you — then verifying those boundaries hold rather than trusting that they do. Deterministic core, probabilistic edge. The fast clock stays pure; the slow clock gets to think. That principle shows up in every system here, and it's the reason they're built to run locally and predictably instead of calling out to a black box and hoping.

Why local, why owned

Because the alternative is renting your own capabilities back from whoever owns the model this quarter. Local-first isn't an ideology here; it's a structural bet. A system that runs on hardware I own can't be deprecated out from under me, can't have its terms changed, can't leak what it processes to a third party, and can't stop working because someone else's API had an outage. For the kind of systems I want to exist — things that run for months unattended, that hold real state, that you'd actually trust — that independence isn't a nice-to-have. It's the whole foundation.

This site

This is where I show the work and write about how it's made. The devlog is the real substance — architecture reasoning, findings, and the occasional honest negative result, written for people who build the same kinds of things. The work page is a tour of the systems themselves. Implementation stays private; the thinking doesn't.

If you build in this space, or you're curious about any of it, get in touch.

— Isosceles