I am writing the first post on this blog from the ideas stage.
What that means, concretely, in October 2025: I have a private experiment called DOS (DuranteOS) that I started seven weeks ago — the first commit landed September 9, 2025. As of this morning the repo is at v0.6.0 and ~827 files. It is a small thing. It runs on my own machine. It has no paying users, no public website, no roadmap I would defend in front of an investor. What it has is a thesis I have been turning over for months, and a notebook full of architectural choices I am about to make real.
This post is the thesis. Not the description of a built product. The thesis it is built from.
The pattern is so old we stopped noticing it.
You open an application. It shows you a form, a list, a dashboard, a settings panel. You scan, click, type, submit. The application converts your gestures into state changes. State changes propagate. The application redraws. You scan again.
That loop — gesture, state, redraw — is what we have called software for forty years. It is what every PRD assumes. It is what every UX team optimizes. It is what every B2B SaaS sells, dressed in different colors.
I am betting my career that this pattern is ending.
Not because interfaces are bad. Because something more efficient now exists for the same job: an agent that already knows what you want, has the context to act on it, and the memory to do it again next week without being told. The interface becomes vestigial. The product is the agent.
The thesis in one sentence
The agent is the product. Intelligence replaces interface. Memory replaces lock-in.
This is the manifesto for the personal AI OS I have been sketching. It is also a working theory of where every B2B and prosumer software category is going. I will defend both claims here. I will also be the first to admit, in posts ahead, when the working theory contradicts what I find in practice.
The interface era and what it gave us
The interface era was a real achievement. It took us from punch cards to direct manipulation. It made software usable by anyone with a mouse. It built the entire SaaS economy.
But the interface was always a workaround. It existed because the machine could not yet understand what you wanted. So we built a vocabulary of widgets — text fields, dropdowns, modals, toggles — and trained billions of humans to translate their intent into that vocabulary. We called it "user experience." It was actually translation labor, paid by the user, in time.
| Era | Primary verb | Translation cost paid by | What gets sold |
|---|---|---|---|
| Mainframe | Submit | Operator | Time on the machine |
| Desktop | Click | User | The application |
| Web | Navigate | User | The destination |
| Mobile | Tap | User | The app slot |
| Agent | Ask | Machine | The outcome |
Look at the column on the right. For every prior era, what was sold was a thing the user had to learn to operate. In the agent era, what is sold is the outcome itself. The translation cost — formerly paid by the user, in cognitive load — is now paid by the model, in tokens.
That is not a marginal change. That is a category collapse.
What collapses
When the interface dissolves, three things that the SaaS economy depends on go with it.
What changes when the agent is the product
- Stickiness comes from training cost. Once a user learns your dashboard, switching means re-learning. So you build complex dashboards.
- Onboarding is a funnel. Lose 60% in the first week, optimize the first-touch tutorial.
- Power users want more knobs. Add settings panels. Charge for the Pro tier with the extra knobs.
- Data moat means the data lives in your DB. Lock-in via export friction.
- Stickiness comes from accumulated context. The agent that knows your last six months of decisions is more useful than the one that doesn't. Memory, not muscle memory.
- Onboarding is a conversation. The agent asks what you need; you answer in plain language. No funnel.
- Power users want fewer surfaces. They want the agent to anticipate — to do the thing without being asked twice.
- Data moat means the agent has done your work alongside you for a year. Lock-in via shared history.
The right column is the bet. Every assumption on the left has a successor on the right. The companies that win the next decade will be the ones that internalize the right column before their competitors do — and I want to be honest that the right column is hypothesis, not yet evidence. I am stating it because I am about to spend the next year trying to falsify it with my own work.
What "memory replaces lock-in" actually means
The most repeated objection I expect to hit on this thesis is some variant of: "Won't users just take the conversation history with them?"
They will. They should. That is the point.
Lock-in via export friction is a 2010 strategy. It worked when "your data" meant rows in a database that competitors could not parse. It does not work when "your data" is a one-million-token conversation that any frontier model can ingest in seconds.
The new moat — if the bet is right — is different. It is not what data you hold. It is what context the agent has accumulated alongside you. The two-year-old agent who has watched you make six product decisions, twelve hiring calls, and forty-three architecture choices is not just "an agent with your data." It is an agent that has built a working theory of how you make decisions. That theory is portable in principle and almost worthless in practice. Re-creating it requires running the same six months again with the same operator.
That is the moat I want to test. It is not legal. It is not technical. It is temporal. You cannot move two years of co-experience to a new agent in a weekend. You can move data in a weekend.
What the bet rests on
Three claims I am about to spend a year stress-testing:
- The frontier substrate (Claude, GPT, Gemini) commoditizes faster than people expect.
- The operator's accumulated context becomes the actual moat.
- The right place to build that moat is the operating system layer — between the substrate and the operator's daily work.
If any of the three turn out to be wrong, this thesis is wrong. I will tell you which it was.
A skeptical reader's checklist
I do not think every objection to this thesis is wrong. Several are very strong. Here are the four I take most seriously, written before I have lived through them as a builder.
The four objections that keep me honest
If you are evaluating whether the agent-as-product thesis applies to your category, these are the questions to stress-test.
- The latency objection. Agents are slower than buttons. For high-frequency operational tasks (claims processing, point-of-sale, trading) the latency budget will not tolerate a 4-second LLM round-trip. Counter: True for the next 18 months. Possibly false after that. Frontier model latency has been falling 30% per year. Buttons will still win for tasks measured in milliseconds, but the band of "tasks where buttons win" is narrowing fast.
- The trust objection. Operators cannot verify what the agent did. Counter: Auditability is a UX problem, not an architectural one. I will explore my answers to this in future posts as I build them.
- The compliance objection. Regulated industries (healthcare, finance) require deterministic UI for audit trails. Counter: Half-true. The agent can still produce deterministic artifacts (forms, exports, audit logs). What changes is that the operator no longer hand-fills the form. The agent does, the operator approves, the artifact is identical.
- The "users want control" objection. Some users genuinely want the dashboard. Counter: Some users still want spreadsheets too. Both will exist. The economic question is which medium captures the next billion users — and the answer is the one with the lower translation cost.
What this implies if you are building anything
Three implications, ordered from least controversial to most.
One. Every dashboard you ship next year should have an agent entry point. Not because the dashboard is wrong, but because every operator now expects to be able to ask. The cost of adding a chat affordance is now near zero. The cost of not adding one is rising.
Two. Your moat is no longer your schema. It is your accumulated context. Build for memory. Treat session history as a first-class asset. Do not let users feel like they are starting over every time they open the app.
Three. Your team's hiring criteria are wrong. The skill that mattered most in the interface era — translating ambiguous user requirements into precise widget hierarchies — is being commoditized. The skill that matters in the agent era is taste in the absence of an interface: knowing what the agent should do without being asked, what it should refuse, what it should remember, what it should forget.
Where DOS is, today
Honestly:
- Repository: Private, single-operator (me)
- First commit: September 9, 2025
- Version: v0.6.0 as of October 21, 2025
- Files: ~827
- Substrate: Claude Code as the inference and orchestration layer
- What works: A handful of personal hooks and skills that load context for me at session start
- What does not exist yet: A cloud platform, a memory graph, a formal algorithm, a credit ledger, third-party packs, paying users
- What might exist by next October: All of the above — or proof that the thesis is wrong
That is the honest map. Future posts in this series will report from inside the build, not from above it. When I am wrong, I will tell you what I was wrong about. When something works that the thesis did not predict, I will name the surprise.
What I am building toward
If the bet is right, the next decade of B2B software looks very different from the last. The dashboards we built will become museum pieces — beautiful, precise, irrelevant — like the typewriter on the desk of a writer who now dictates.
If it is not, I will have spent a year proving a clean negative. That is also a result worth having.
Either way: the experiment is the point. Software has been the same shape for forty years. It is past time to find out what comes next.
I will let you know how it goes.
— Lucas
Was this page helpful?