AI-First OS

What it is, in plain terms

AI-First OS is a research project: a design, and a growing implementation, for a phone operating system built around a single rule. Software agents built on AI models are free to suggest things a phone should do — open an app, send a message, change a setting — but they are never the ones who decide whether it actually happens. That decision is made by ordinary, deterministic code: code that either allows a specific, well-defined kind of request, or it does not, and nothing about how convincing or well-phrased the request sounds changes that.

I think of the two halves as an intelligence layer, which is allowed to be creative, wrong, or ambitious, and a security layer, which is not allowed to be any of those things. The intelligence layer never talks to the security layer in free-form language. It has to ask in a fixed, structured way — the software equivalent of filling in a form rather than making a case — and the security layer only ever reads the form. Nothing about the wording of a request, however it is phrased, can change what the form says.

This project is not a phone skin, a launcher, or an assistant bolted onto an existing operating system. It starts from the operating system itself, precisely because the rule above needs to be true underneath everything, not just in the parts a user can see.

Its own public engineering record, at ai.itisyou.app, calls it ITISYOU OS (AIOS). It is a different project from the x86 research kernel described on the ITISYOU OS page, and I use the name AI-First OS here so the two cannot be confused. The engineering record lists what each milestone showed and how; this page explains why the project exists.

Why I built it

I wanted to find out whether a phone could genuinely let AI act on your behalf without quietly making the AI the thing deciding what is safe. Assistants tend to sit at one of two extremes: they ask for confirmation on almost everything, which defeats the point of delegating, or they are trusted with a wide licence and the design hopes for the best. I wanted to see whether a narrower design was possible: one where the model’s job is limited to proposing, and a separate, boring, reviewable piece of code carries all the responsibility for permitting.

If that split can be made to hold under real pressure — real code, real tests, real conflicting changes from different lines of work on the same design at once — it says something useful about how much of AI safety is actually an architecture question rather than a model question. If it cannot be made to hold, that is worth finding out too, and finding it out early, on a research project, rather than after it is running on somebody's phone.

The problem underneath

The uncomfortable version of the problem is that a model is, structurally, a thing that produces plausible text. It can be prompted, confused, or manipulated, and it can be extremely convincing while being wrong. If a phone lets that kind of output flow into the part of the system that grants permissions, the model has effectively become the security boundary, whatever the design documents claim about it.

My starting position was that this has to be treated as unacceptable by construction, not managed by good intentions. So the question the whole project is built around is a narrow one: can you build a real phone operating system where the answer to "did the AI decide this was safe" is always no, even under the kind of pressure — a badly worded prompt, a compromised model, two lines of work changing the same rule at once — that would make a softer design bend.

How it works, without the jargon

In plain terms, the system is built in layers, and the number of layers matters less than what separates them. Near the bottom is code that behaves the same way every time it is given the same input: it grants or refuses named actions, and it writes down what it did. Above that sits the part where AI agents operate — proposing, planning, drafting — but every one of their proposals has to pass through the same narrow gate as everything else, expressed as a typed, structured request rather than as sentences a person or a model wrote.

The gate does not interpret language; it checks a request against fixed rules and either allows it or it does not. Nothing about how a request arrived — which agent asked, how it was worded, how confident it sounded — can substitute for meeting those rules. Above the agents sits the part a person actually sees and talks to.

The design also assumes the AI part can be switched off or fail, and the rest of the phone is meant to keep working in a reduced way rather than stop, because a system that only works when the model is healthy is not the system this project is trying to build.

What building it taught me

The clearest lesson so far is how much discipline the “typed, not free text” rule demands in practice. The project has automated checks that scan the parts of the code allowed to make decisions and fail if any of them accepts free-form text. When those checks were added, they found existing places that did — small helper functions that looked harmless — and the findings were recorded and fixed rather than exempted.

The second lesson came from running two lines of work on the same design at once and then bringing them back together. Real disagreements showed up in the test suites — not one side obviously right, but genuinely conflicting expectations about the same behaviour. Three of them were written down as findings on 6 September and left visibly failing. One available fix was refused outright: it would have made a test pass by moving the property it guards somewhere the test could no longer see, which is a worse outcome than an honest red. By the integration pass of 7 September the suites passed in full.

The third lesson is about evidence. A result from the development machine and a result from the phone are different kinds of claim, and the project labels every result with where it was produced. That mattered the day the work moved onto the device: the second milestone could be declared passed for exactly what it covered — build, boot and inventory — while things it could not test, such as calls over the mobile network without a provisioned SIM, stayed listed as unverified instead of being waived.

Where it stands today

This is a private research project, not released, and not something anyone else could install or try. The specification is frozen at a named version, and the implementation is growing underneath it in numbered work packages, each of which has to produce its own evidence before it counts. The first milestone — that the design’s core contracts hold, checked with evidence gathered on the development machine — passed on 5 September 2026. The second — a baseline build booted and inventoried on a real development phone — passed on 8 September 2026, with 306 of 306 tests in its closure.

By the integration pass of 7 September 2026 the automated test suites covering the Rust and Python parts stood at 753 and 534 tests respectively, all passing, after three disagreements between parallel branches of work had been recorded, left failing and then properly fixed.

What has not been shown yet matters as much. The project’s own authority code — the deterministic part that grants or refuses requests — is being built and checked on the device now, one piece at a time. Its network rules are designed but not yet demonstrated on the phone. Calls and other features that need a mobile network could not be tested at all. The project is private, and there is no plan to open the source.

Where it may go

Next: finish the authority core and verify it on the device, piece by piece, then prove the network rules there too. Then: close the open items the second milestone recorded rather than waived. Later, if the device evidence keeps agreeing with the design: extend the same discipline — propose, never permit — to more of what the phone can do.

None of this is a release plan. It is a description of the order in which I intend to keep testing the central idea, because a rule that only holds on a development machine is not yet a rule that holds on a phone, and the second one is the one that would actually matter.