Private today

The system is running. Early access is next.

Living Code OS already runs in a private deployment. Public access is not open yet. Leave your email to hear when a personal deployment is ready, directly from the builder, with no drip campaign or sales sequence.

The list

Email is the only required field. The rest helps us reply with something useful instead of a form letter.

Your details stay with Duval Software. No drip, no resale.
Plain terms

What this list is, and isn't.

A waitlist is a promise in both directions. Here is ours, in full.

What you get

First word, from a person.

When there is something to hand you (a deployment to try, a walkthrough, an update worth reading), you hear before it goes anywhere public. If you wrote something worth replying to, you get a reply. That is the whole promise.

Why that last question matters

The system is built around one living context, an authority boundary you set, and a human approval area for everything outside it. Knowing what you would want it to notice, handle, or build tells us which part to show you first.

What you don't

No drip. No call. No sharing.

No marketing sequence. No sales call. Your details stay with Duval Software. No drip, no resale: what you write here is not handed to a tool, a list, or a partner, and a note to lucas@duvalsoftware.com removes you.

What the dollar figures on this site mean

They describe what the system costs to run, metered call by call in its own cost ledger, not what anyone is charged.

Who this is for

Three kinds of people.

Someone whose spoken and digital life is scattered across tools, with recordings in one place, threads in another and files in a third. Someone who wants a system that acts inside rules they set, rather than asking about everything. Someone who wants a missing capability built into the system rather than bolted on beside it. If you would rather read the architecture before believing a word of this, start there. In every case it is one person, one instance. The system is yours: point it at a company, or several, and it holds everything about them. People who work together each run their own instance and share only the rooms they choose.

What "the authority boundary" means

You set the authority boundary. Inside it the system acts on its own, so it can follow up, file, schedule and keep things moving without asking. Outside it, anything with a real-world effect (an email, a calendar move, a merged pull request, a new agent, a paid build) lands in a human approval area as a card showing the exact action that will run. Nothing outside the boundary executes until you resolve it, and what is in the fields at approval is what runs.

Not sure yet?

Ask Jeffery on the home page. He remembers the whole overview and will say plainly when he doesn't know something. Jeffery is this deployment's resident agent; every deployment names its own.