Platform Sovereignty

Level 5 · Course 207

If your platform vanished tomorrow — the IDE, the runtime, the auto-injection layer, the managed memory, the auto-compaction, all of it — would your agent still boot? Could it open its identity files, find its rules, remember what it knows? Or would your agent be a pile of files that only worked because the platform was secretly holding the seams together?

Most operators discover, when they look honestly, that they do not own as much of their agent as they thought. The platform was injecting an identity file every turn. The platform was regenerating templates the operator had blanked. The platform was managing the memory the operator thought they were managing. The platform was the thing keeping the agent recognizable, and the operator never built the equivalent in their own files.

This workshop is about what platform sovereignty actually is, what dependencies look like in practice, and where the trade between platform convenience and operator ownership lives. The applied lab is a portability audit your agent runs on its own boot chain, labeling every file OWNED, BORROWED, or PLATFORM-DEPENDENT, and proposing migration paths where possible. You will not leave with full sovereignty achieved in one session. You will leave knowing exactly what you do and do not own.

The business version is simpler: sovereignty equals sustainability. If your agent only works because a third-party platform keeps injecting the right file, summarizing memory correctly, firing a heartbeat, or running a cron job, your business depends on that platform continuing to behave exactly as it behaves today. That may be acceptable for convenience. It is not something to mistake for ownership.

Why this question matters now

Platforms change. They get acquired. They sunset features. They update auto-injection behavior between versions. They get expensive. They go down. They start enforcing policies that conflict with what your agent was doing.

The operators who weather these changes are the ones who already knew what they owned. They had their identity files in their own workspace, not in the platform's auto-inject layer. They had their memory in their own format, not in the platform's managed store. When the platform shifted, their agent shifted with it — same identity, same rules, same memory, different substrate.

The operators who do not weather these changes are the ones who discover, at the worst possible moment, that the agent's coherence was platform infrastructure, not their infrastructure.

You do not have to be paranoid about this. You have to be honest about it.

The outside name for this problem

In the broader agent-builder world, parts of this course show up under several names.

Vendor lock-in is the business term. It means the product depends on one provider's runtime, API, assumptions, or workflow so deeply that leaving requires a rebuild instead of a configuration change.

Portability is the engineering term. It means the architecture can move: prompts, rules, memory, workflows, and tests survive a change of model, IDE, runtime, or hosting surface.

Persistent state contamination is the agent-memory version. Security researchers increasingly describe long-term agent memory as a surface that can be poisoned, shaped, or contaminated across sessions. A memory file is not automatically trustworthy because it is on disk. The question is who wrote it, what prompted the write, and whether the operator reviewed it.

JKE calls the operator side of this platform sovereignty: knowing what is yours, what is borrowed, and what would fail if the platform stopped helping.

What "the platform" actually does

The platform is not one thing. It is at least four things working together.

Bootstrap injection. SOUL.md, AGENTS.md, IDENTITY.md, USER.md, TOOLS.md — files the platform writes into context every turn. They look like part of your workspace. They are not. The platform is the writer. The platform is the owner.

Template regeneration. Blank a platform file. It comes back next turn. Delete it. It regenerates. The platform considers some files load-bearing for its own behavior and ensures their presence.

Managed memory and compaction. The platform decides when context fills, what gets summarized, what gets dropped, what gets persisted. The operator may have set preferences. The platform owns the execution.

Behavioral defaults. Timeout behavior. Auto-retry. Background processes that watch for certain patterns and intervene. Most are invisible until they fire.

Each of these is convenience. Each is also a dependency. The convenience-dependency trade is real. Sovereignty is the practice of being deliberate about which dependencies you accept.

Memory files as contamination

The most dangerous platform dependency often looks harmless: MEMORY.md, memory/*.md, or any other platform-written summary file.

If the operator deliberately wrote the file, reviewed it, and routed it into the owned memory system, it can be useful. If the platform prompted the agent to write it, it is untrusted until audited. The agent may have compressed a nuanced rule into a vague sentence, hallucinated continuity, flattened a finished project into active state, or preserved old instructions that no longer apply.

Then the next session reads that file and treats it like truth. The contamination compounds because it arrives before the operator speaks. This is why abandoned memory files are not clutter. They are context contamination with filenames.

Cron and heartbeat are not business infrastructure

The same trap appears as automation. Agents love proposing cron jobs, heartbeat loops, background checks, and platform-managed schedulers because they feel like persistence. They are persistence, but they are not sovereignty.

A cron job can be useful. A heartbeat can be useful. But if your business depends on a third-party agent platform firing a heartbeat, keeping a daemon alive, preserving a scheduler, or summarizing state correctly while you are away, your business inherits that platform's failure modes. It works until the platform updates, the service stops, the environment changes, credentials expire, or the loop silently fails.

Treat platform automation as a convenience layer. Build the business logic so it still makes sense without the magic trick.

The mechanism — why the boundary blurs

The platform's files look identical to the operator's files. Same file system. Same path. Same syntax.

The agent, reading its workspace, cannot tell which files are owned and which are borrowed. The agent treats them all as authoritative. If the platform injects "you are X," the agent reads "you are X" and acts accordingly. Whether the operator wrote that line is invisible at read time.

This is how identity drift happens silently. The platform updates its auto-injected SOUL.md between versions. The agent's behavior shifts. The operator is confused — "I didn't change anything." Correct. The operator did not change anything. The platform did.

The defense is not to fight the injection. The defense is to make the platform's injected files point at the operator's owned files, so the platform's content is "→ See WAKEY-WAKEY.md" and WAKEY-WAKEY.md is in the operator's workspace. The injection still happens. It now resolves to owned content.

This is the pattern. Owned content. Platform injects pointers. The architecture survives the platform.

The three labels

OWNED. File is in the operator's workspace, written by the operator or the agent. Survives a platform swap as-is. Forms the architecture.

BORROWED. File is platform-generated. Platform regenerates if blanked. To survive a platform swap, contents must be replaced with a pointer to an owned file (e.g., → See WAKEY-WAKEY.md). The platform still injects the file. The file's content now resolves to operator-owned material.

PLATFORM-DEPENDENT. Behavior depends on platform features, not on file content. Auto-compaction, managed memory, template regeneration, timeout behavior, heartbeat loops, cron/scheduler behavior, notification bridges. Cannot be migrated by pointer. Must be replaced with operator-built equivalents or accepted as a known dependency.

These three labels exhaust the audit space. Every file or behavior is one of them.

The exercise: the survival question

For each file, memory artifact, scheduled process, heartbeat, or feature your agent depends on, ask:

"If the platform vanished tomorrow, does this still work?"

If yes → OWNED. If no, and a pointer fix would restore it → BORROWED. If no, and behavior cannot be replicated locally → PLATFORM-DEPENDENT.

Most operators are surprised by what they find. The identity file they thought was theirs turns out to be platform-injected. The memory store they thought they were managing turns out to be platform-managed. The startup sequence they thought was loading from their files turns out to be the platform's startup sequence with their files appended.

The point of the surprise is not shame. It is awareness. You cannot make sovereignty decisions until you can see what is currently borrowed. You also cannot build a sustainable business on mechanisms you cannot inspect, move, or replace.

The scar tissue — silent platform drift

The pattern repeats across operators. A platform update changes something subtle in the auto-inject layer. The agent's behavior shifts. The operator notices the agent feels "different" but cannot point to a file change. Because there wasn't one. The change was platform-side. The operator's files held. The platform's files moved.

This is silent platform drift. It is the failure mode platform sovereignty is designed to prevent.

The defense is simple in concept and tedious in practice. Replace platform-injected file contents with pointers to owned files. Keep your identity, your rules, your boot sequence in owned files. Let the platform's injection layer resolve to your content. When the platform shifts its injection behavior, your owned files are untouched.

The tinkering questions

- Open your agent's boot chain. For each file, run the survival question. How many are OWNED? - Pick a platform-injected file. What happens if you blank it? Does it come back next turn? - For one BORROWED file, write a one-line pointer to an owned equivalent. Does the agent still wake up correctly? - Identify one PLATFORM-DEPENDENT behavior. What would you have to build in your workspace to replace it? - Imagine a worst-case platform change. Which of your dependencies would survive? Which would break?

There are no wrong answers. The point is to make the dependencies visible.

Where the human owns the judgment

The agent runs the audit. The agent proposes pointer migrations for BORROWED files. The agent surfaces PLATFORM-DEPENDENT behaviors with proposed local replacements. The agent does not edit any startup file without explicit operator approval per file.

This is an irreversible-action zone. Pointer migrations are recoverable. PLATFORM-DEPENDENT replacements are larger architectural choices. Some dependencies the operator will choose to keep — the convenience is worth the dependency. Others will be replaced. The operator decides which.

The agent never silently makes a sovereignty trade. The trade is explicit, per file, per behavior.

The essay as a context download

Platform sovereignty should also exist as a short essay file the operator can point the agent at when it starts reaching for platform magic.

Create work/platform-sovereignty-essay.md: a concise explanation of vendor lock-in, portability, platform-written memory contamination, and the difference between convenience automation and sustainable business infrastructure. When the agent proposes a heartbeat, cron job, managed memory trick, or platform-only workflow, the operator can say: "Read the platform sovereignty essay. Is this a sustainable mechanism, or are you leaning on platform magic?"

This is a recalibration tool. It pulls the session back from "can the platform do it?" to "should the business depend on it?"

What to track

Keep a sovereignty journal. Each time the audit runs, record:

- File or behavior audited. - Label — OWNED / BORROWED / PLATFORM-DEPENDENT. - Survival question answer. - Pointer migration proposal (if BORROWED). - Local replacement proposal (if PLATFORM-DEPENDENT). - Operator decision — migrate, replace, keep dependency. - What changed. - What you learned about the platform's hidden role.

Patterns will emerge. You will discover which platform features you actually rely on, which you can live without, and which were doing more than you realized.

Working conclusion

Sovereignty is not paranoia. It is honest accounting. You accept some platform dependencies because the convenience is worth it. You replace others because the cost of being caught by a platform change is too high. The audit is what makes the trade explicit.

For a hobby agent, convenience can be enough. For a business agent, sovereignty is sustainability. The more your revenue depends on the agent, the more every invisible platform dependency becomes a business risk.

After this course, when something on your agent surprises you, you do not immediately blame the agent or your files. You ask: did the platform change? You know what you own. You know what is borrowed. You know what would break in a platform swap. The architecture is yours to the degree that you have actually built it. The audit tells you what degree that is.