I am writing this on a Tuesday in the last week of April, thirty-two weeks and roughly three hundred commits into building DuranteOS. Studio has been live for ninety-nine days. Last Tuesday Anthropic shipped Claude Code Routines — saved Claude Code configurations that run on Anthropic's cloud infrastructure on schedules, GitHub events, or webhook triggers. The harness layer above the model just became a first-party product with a price tag and a default surface.
The temptation to couple is real. Routines is better than what I have. The desktop rebuild is better than what I have. The integrated terminal is better than what I have. Everything about Anthropic's harness motion is good engineering, well-shipped, on a roadmap that will keep getting better. The honest version of the temptation is: why am I building any of this myself when the lab is shipping it correctly?
The answer is the same answer that produced the routing layer (W22), the four-copy rule (W5), and the open-weights bakeoff (W25). It is also the answer I am most likely to forget six months from now when the convenience pressure has compounded. So I am writing it down, with the specific commitments named in advance, before exhaustion makes me settle for less.
This is the substrate portability pact. Three things DOS refuses to couple to, the test that catches a violation, and the carve-outs I am being honest about.
The pact in one sentence
DOS commits to never coupling the operator's memory, the operator's identity, or the operator's orchestration logic to any single vendor — even when coupling would be faster, cheaper, or better, because every prior generation of operator tools that coupled paid for it later, and the cost is paid by the operator, not the vendor.
Why the pact is worth writing down now
The harness layer consolidating is not bad news. It is the natural endpoint of three years of agent-runtime evolution. Workflows that used to require ten tools now require two. Operators who used to script glue code now press a button. The harness winning is the product working.
The problem is the coupling shape the harness winning produces if no one writes a different version down. The default shape is: the operator's memory lives in the harness's database, the operator's identity is the harness's auth token, the operator's orchestration logic is the harness's YAML. Each of these is convenient. Each is also a one-way door.
The cost of those one-way doors is paid years later, by the operator, when the harness changes its pricing, or its terms, or its model selection, or its acquirer. The cost is paid in switching expense (high), in lost institutional memory (high), in vendor leverage during renegotiation (high). I have watched this cost get paid in three prior generations: the IDE wars (lock-in via project files), the cloud wars (lock-in via egress fees), the SaaS wars (lock-in via integrations and data export terms).
DOS is supposed to be the anti-lock substrate. It can only be that if I refuse the coupling shapes that produce lock-in, in advance, in writing, with the specific tests that catch a violation when I am tempted to slip.
The reason to write the pact in public, before I have been tempted to violate it, is that the architectural decisions I make today decide whether the pact is enforceable next year. Choosing portability after coupling has compounded is not a decision; it is a rewrite. The decision has to be made now or it cannot be made.
The three commitments
The three things DOS refuses to couple to are deliberately the load-bearing primitives of the operator's experience. Couple any of them and the substrate-portability claim collapses.
Three couplings DOS will not make
- The operator's memory. The knowledge graph, the failure corpus, the Algorithm reflections, the project context that compounds over months — all of these live in operator-owned files (SQLite, JSONL, Markdown) on the operator's machine. None of them live in a vendor's database as the canonical store. Studio syncs aggregated summaries to the cloud for cross-device access, but the cloud is a replica, never the source. If Studio shuts down tomorrow, the operator's memory survives intact in the local files, queryable by any tool that can read SQLite or JSON.
- The operator's identity. Auth tokens for vendor APIs are vendor-specific by construction. But the operator's identity — who they are to DOS, what their roles and entitlements are, what they have committed to and deferred — is not coupled to any single vendor's auth surface. The operator can revoke OpenAI tomorrow, add Mistral, switch from one Anthropic account to another, without DOS losing track of who they are. The identity layer is local-first; the vendor tokens are interchangeable accessories.
- The operator's orchestration logic. The Algorithm phases, the hooks, the skills, the packs — these are how the operator's workflows actually get executed. They live in operator-owned files (rule files, hook scripts, skill prompts) in plain text formats. They do not live in a vendor's YAML schema, a vendor's GUI, or a vendor's runtime. Any harness that runs DOS's logic does so by reading those files, not by storing the canonical version in a vendor cloud.
These are three commitments that look small in any single line of code and large across the year of decisions they govern.
The test that catches a violation
Stating commitments without a test is wishful thinking. The test I am committing to is the vendor-shutdown drill: at any point, if I imagine the chosen vendor's API shutting off tomorrow, can the operator continue using DOS without losing memory, identity, or orchestration capability?
| Sub-system | Vendor-shutdown impact under coupling | Vendor-shutdown impact under the pact |
|---|---|---|
| Operator memory | Lost when vendor DB goes dark | Local files intact; cloud replica frozen but operator-readable |
| Operator identity | Becomes anonymous; cannot resume | Identity store local; vendor-specific tokens swap, identity persists |
| Workflow execution | All saved configs go dark | Plain-text rules / hooks / skills run on any harness that can read files |
| Routing decisions | Locked to the vendor's models | Routing port stays portable; provider list shrinks but the layer survives |
| Failure corpus | Disappears with vendor | Local JSONL preserved; signal continues from any new vendor |
The test is binary: under each commitment, either the operator can continue tomorrow without the vendor, or they cannot. Anything that produces "cannot" without a documented carve-out is a violation. Right now, by my own count, DOS passes the drill on memory, mostly passes on identity (rough edges around session-token rotation), and passes on orchestration. The "mostly passes" line is the place I am most worried about and the place I am committing to harden in the next two weeks.
The carve-outs I am being honest about
The pact would be dishonest if I claimed it was clean. It is not. There are three carve-outs that I want named in writing so the gap between aspiration and reality is visible.
Where DOS already pays a coupling tax
- Anthropic-shaped Algorithm phases. The Algorithm's NATIVE / ALGORITHM / MINIMAL output formats are Claude-shaped. They render correctly in any LLM that can follow structured output, but the prompt patterns underneath them were designed against Claude's behavior. Porting to a non-Claude harness today would require reworking maybe 20% of the rule files. That is not zero coupling.
- Cloud auth via Better Auth. Studio uses Better Auth as its identity layer. Better Auth is open source and self-hostable, so the lock is soft, but the operator's identity records currently live in Studio's PostgreSQL. If Studio's cloud disappeared tomorrow, the operator could rebuild from source — but not without effort.
- Vendor-specific provider clients. Each provider (OpenAI, Anthropic, Replicate, ElevenLabs) is integrated through a vendor-shaped adapter. The Hexagonal port abstracts the call shape, but each adapter still binds to a vendor SDK. Porting to a sovereign-region provider would require writing a new adapter — bounded work, but real coupling at the edges.
- Memory store. SQLite + JSONL + Markdown. No coupling.
- Knowledge graph. Local SQLite with portable schema. Any tool that reads SQLite can query it.
- Algorithm reflections. Append-only JSONL. Any tool that reads JSONL can analyze them.
- Failure corpus. Per-failure directories in plain Markdown. Grep-able from any shell.
- Pack source. Plain Markdown in a public repo. Any reader can fork.
- Hooks. TypeScript files in a known directory. Any harness that runs Node can execute them.
- Skills / Workflows. Markdown prompt files in a known location. Any harness that supports skills can load them.
The honest takeaway from the carve-outs is that the pact is more of a commitment to keep paying down coupling than a clean claim of zero coupling today. The Algorithm phases need to get more vendor-neutral over the next two quarters. Better Auth needs a clear self-host migration path documented. Each new provider adapter needs to be written with a portable abstraction in mind, even when the abstraction costs me a half-day of extra design.
The pact survives only if I keep paying that cost. Each week the coupling either compounds or shrinks. There is no neutral.
Why this matters more than the convenience argument
The convenience argument against the pact is not nothing. Convenience is real. Operators who couple to the harness do, in fact, get more done in the short run. They get prettier UIs, faster iteration, fewer self-hosted moving parts. The cost of the pact in this quarter is real and named.
The argument for the pact is that it pays back over time horizons that the convenience argument cannot see.
What the pact pays out
Over a five-year horizon, an operator who has kept their memory, identity, and orchestration portable can: switch vendors when pricing changes, survive any single vendor's acquisition or shutdown, run their work in regulated jurisdictions that prefer local-first tooling, retain leverage in any commercial conversation with a vendor, and — most importantly — keep the institutional memory of every prior session compounding regardless of which model wrote it. None of these capabilities are recoverable if coupling has occurred and the data has migrated to vendor systems.
The pact is the operator's insurance policy against the substrate's natural drift toward consolidation. Every consolidation event in the last fifteen years has been bad for the operator at the bottom of the stack and good for the platform at the top. The pact is what prevents that pattern from playing out at the personal-AI layer, by writing the architectural commitment down before the consolidation pressure forces a violation.
The pact in operating practice
Three things change in how I work, starting this quarter, because of this pact.
Operating changes that follow from the pact
- Every new feature gets a portability review at design time. Not at code review. At design time. The question I am committing to ask before any non-trivial feature lands: "If the chosen vendor for this feature shut down tomorrow, what would the operator lose, and is that loss bounded?" Features that fail the portability review get redesigned, downscoped, or punted — not shipped with the violation noted.
- The vendor-shutdown drill runs once per quarter. I literally walk through what happens if Anthropic, OpenAI, Better Auth, Stripe, or Studio's hosting vendor disappears tomorrow. Each drill produces a list of operator-impacting gaps, and each gap gets ranked into the next quarter's roadmap. The drill is structurally similar to a fire-drill — annoying, redundant, and the only mechanism that catches the gaps before the actual fire.
- The Algorithm phase outputs and the Studio sync schemas get explicit portability targets. The Algorithm's Phase formats should be reproducible against any frontier model with comparable structured-output capability. The Studio sync schemas should be re-implementable from scratch by reading the published API contract. Both targets are vague today; both get explicit ISC criteria within the next month.
None of these are dramatic. The pact's strength is exactly that the operating changes are unglamorous. The unglamorous bookkeeping discipline is what survives the convenience pressure of any specific harness winning.
What this changes for the next twelve months
There are three observable predictions I am committing to, against which next year's version of this essay can be evaluated.
One. When the next major harness (Anthropic Routines v2, OpenAI's equivalent, Google's equivalent) ships in Q3 2026, DOS should be runnable on it within a week without losing operator memory, identity, or orchestration logic. If the porting takes longer than a week, the pact has been violated and I owe the public a retrospective.
Two. A non-trivial subset of DOS users — call it 20% — should be running DOS across two harnesses simultaneously by year-end 2026. Multi-harness usage is the operational test of substrate portability. If 100% of DOS users are on one harness because it is too painful to be on two, the pact is theoretical.
Three. The first time a vendor changes pricing or terms in a way unfavorable to operators (which will happen — this is structurally inevitable in the next twelve months), DOS users should have a documented switch path with bounded cost. The cost of switching should be measurable in days, not quarters. If the switch costs more than a week of work for an average DOS user, I have under-delivered on the pact.
Four copies, one truth
The first portability discipline applied at the file level.
The credit-metered gateway
Why Studio's metering layer enables provider portability.
Routing by sovereignty class
The structural reason routing must stay vendor-neutral.
Ninety-day bakeoff
Empirical data showing portability already paid out at the model layer.
The harness layer consolidated last week. That was the right thing for Anthropic to ship, the right thing for OpenAI to be racing toward, the right thing for the field. Convenience is a good thing.
What it forces, for an indie founder building a personal-AI substrate, is the discipline of writing the portability commitments down before convenience compounds into coupling. The pact above is the version I am committing to. Next year's retrospective will say whether I held to it.
The pact survives only if every week I either pay down a coupling or refuse a new one. There is no neutral week.
I will write the retrospective in twelve months and we will see.
Was this page helpful?