Own Your Boot Chain

Level 2 · Course 12 of 16 · Course 12

Context contamination happens before you speak. Every fresh session, your platform reads files before you've typed a word — identity stubs, configuration defaults, templates the platform ships with. If your agent was previously prompted by the platform to write memory files, those load too. You didn't author them. You never reviewed them. By the time you say hello, the session is already running on someone else's framing.

Most operators miss this. They open a chat, assume they're starting clean, and get responses shaped by whatever was in those files. When the agent hedges differently than it used to, or drops a preference you thought was established, startup is the first place to look.

Why platform-auto-written memory files are dangerous

Some platforms encourage agents to write their own memory — summaries of past sessions, notes on the operator's preferences, records of ongoing projects. The intent is continuity. The problem is authorship.

When the platform initiates that write, the agent is composing based on whatever instructions it had at that moment. The resulting file might be accurate. It might also be a hallucination, a flattened version of a nuanced rule, or a summary of a project you've since replaced. It exists on disk. It loads on startup. It contradicts how you actually work now.

Files you wrote, reviewed, and placed deliberately are safe to load. Files the agent wrote on the platform's initiative are a liability until audited. Most operators never audit them. They accumulate, load silently, and every session starts a little further from clean.

Why boot chain ownership matters

The boot chain is the ordered sequence of reads that run before your agent greets you. If you don't own that sequence, you don't own the session. Platform defaults are designed to be broadly safe — not designed for your division structure, your trigger words, or your working style.

Once you're running a real agent system, those generic defaults become interference. They contradict your rules, load irrelevant context, and do it silently every session. Owning the boot chain means you make those calls. Not the platform.

Manual context layering: always-load, trigger-load, do-not-load

Every startup-related file belongs in one of three zones.

Always-load is short. Only what the agent must read before greeting you: operator profile, current state, hard rules. Three to five files. If removing a file from this zone wouldn't change the first response, it doesn't belong here.

Trigger-load holds everything else that matters but doesn't need to run upfront. Division files, project manuals, deep vault files. These load when you say the trigger word or open a mode — not before. This keeps always-load fast and context-clean.

Do-not-load is where stale context gets quarantined. Auto-written memory files you haven't reviewed. Old identity text. Generic platform templates that duplicate or contradict your rules. These files may exist on disk. They don't get to load at startup.

Operator-owned startup syntax

The output of this course is a startup file you wrote. It lists exactly what to read, in what order, with a stop point after greeting. Short, legible, in your own words. Any time you open it, you know exactly what the agent does in the first thirty seconds of a fresh session.

Platform-injected files — AGENTS.md, SOUL.md, IDENTITY.md, whatever the platform drops in the workspace root — get redirected to point at this file instead of carrying their own instructions. The platform still finds what it expects. The content that loads is yours.

Platform-injected file redirects

The redirect is minimal: the injected file gets a single line pointing to your operator-owned startup file. If a platform file can't be safely edited, it goes into a cannot-redirect log with a documented workaround. Nothing gets silently broken.

Boot-chain survival test after /new

After installation, open a fresh session. Ask your agent: what did you actively read before greeting me? What file told you to read those? Which files are always-load and which wait for a trigger?

If it answers all three from your boot map, the chain survived. If it can't name the path, a pointer is broken. Fix the pointer and run it again.

What you decide while the agent runs the PDF

Two decision points. Everything else is mechanical.

Phase 2 is the zone sort review. The agent shows you its proposed assignment of startup files into always-load, trigger-load, and do-not-load. Review it. Move anything it got wrong. Nothing changes until you confirm.

Phase 3 is the boot sequence approval. The agent presents the ordered reads, the stop point, the greeting, and the trigger-word forks. A good sequence runs three to five reads before stopping. If it's longer, push back before confirming.

Redirects, the survival test install, and the journal entry all run without you. Your job is the zone sort and the sequence approval.