I was writing a memory file at 11pm on a Wednesday in April. Richardson, Texas. Third bourbon. The file was titled feedback_andres_copy.md and it contained three rules about how a specific client’s website hero section should handle language. Not the client’s rules. Mine. Rules I’d developed through dozens of corrections over weeks of working with an AI that kept getting the tone slightly wrong until it didn’t.
I stopped typing. Looked at what I’d written. Looked at the sixty-seven other memory files in the same directory. And realized I was doing something nobody had asked me to do and no platform required: I was trying to write down what my AI had already learned, just in case I needed to teach it again somewhere else.
That was the moment I understood what I was actually building. And what I was actually afraid of losing.
The Audit That Started This
A few weeks before that Wednesday, I’d published the results of a formal dependency assessment I ran on my own company. Not a theoretical exercise. I measured what it would cost me, in time, in capability, in operational continuity, to leave the AI platform I’d built my entire business infrastructure on.
The headline number: two to three months of focused rebuilding to switch platforms. Six additional months to reach operational parity.
But inside that assessment, one layer stood apart from the rest. Data was portable. I’d built on open-source Postgres from day one. Integrations were rebuildable in weeks. Skills could be rewritten. Billing was just money.
Behavioral context got a different rating. Risk: High. Eighteen-month trajectory: Critical. Exit cost: three to six months, optimistic. And then this line, which I wrote at the time and still believe: “You can document your preferences, your processes, your communication style. It gets you maybe thirty percent of the way there. The other seventy percent is the stuff you don’t even know the system learned.”
That thirty-seventy split has lived in my head ever since. Because I’m the one maintaining the thirty percent. I know exactly what’s in it. And I know, with uncomfortable precision, what isn’t.
What the AI Actually Learned
Let me be concrete. Six months of daily use, not casual, not occasional, the kind where the AI is the first thing I open in the morning and the last thing running when I close the laptop, produced these observable behaviors:
It learned my decision states. When I say “this feels off” about a strategy document, the system doesn’t ask me to elaborate anymore. It already knows I mean the positioning is too safe. It knows my first draft is never my real thinking. It’s me clearing the obvious ideas so I can see what’s behind them. It knows when I go quiet on a thread, I’m not disengaged. I’m processing. It knows the difference between my “I’m exploring” voice and my “I’ve decided” voice.
That last one matters more than it sounds. Exploring means give me options, push back, suggest alternatives. Decided means execute. The wrong response to either state is expensive. A system that challenges me when I’ve decided wastes twenty minutes of argument. A system that executes when I’m still exploring skips the thinking that makes the execution worth doing.
It learned my client hierarchy without being told. Never a document that said “prioritize Client A over Client B.” But through six months of decisions, which meetings I prepared for versus winged, which emails I responded to immediately versus let sit, which projects got my weekend hours, the system built an implicit priority model. It started routing my attention correctly. Not because I programmed it. Because it watched.
It learned my voice at a granular level I hadn’t even articulated to myself. Not just “writes like Michael.” It learned that I use short-long-short sentence cadence. That I deploy fragments for emphasis but never for softening. That I hate the word “leverage” in any professional context. That when I’m writing for my personal brand versus my company brand, the observation-to-claim ratio shifts. More observation up front, slower path to the point. That my first instinct on any sales copy is to diagnose rather than promise.
Some of those I knew about myself. Some I only discovered when I tried to write them down in a memory file and realized the system had been honoring rules I’d never consciously articulated.
It learned operational tempo. Which hours I actually work versus which hours I’m online but not productive. That Tuesday mornings are strategy time and Friday afternoons are mechanical cleanup. That my energy for creative work drops to near-zero after three client calls in a row.
None of this lives in a database I can query. It lives in the pattern of responses. In the gap between what I type and what it understands I mean.
The Thirty Percent I Can Write Down
Here’s what I maintain. Sixty-eight curated memory files, organized by topic, cross-referenced in a master index. Updated manually, not automatically, because automatic updates compound noise until the signal drowns. The system I trust requires my judgment about what’s worth preserving.
What’s in them:
Voice rules. Sentence-level constraints. Forbidden words. Cadence patterns. The difference between how I write for LinkedIn versus Substack versus a client proposal.
Client context. Not just names and projects. Decision histories. What a client said in a meeting that contradicted what they wrote in an email. Which battles were won and which were strategic retreats. Personality assessments that inform how I present options. This one needs three choices to feel agency. That one gets overwhelmed by anything more than a recommendation.
Architectural decisions. Twenty-eight formal records of why I built things the way I built them. Not just what I decided. The constraints that produced the decision, the alternatives I rejected, and why. Because six months from now I won’t remember why I chose Convex over Supabase for scheduling, and the AI won’t either unless I wrote it down.
Operational methodology. How work flows through my company. What runs daily versus weekly. Which systems depend on which other systems. What breaks if something fails at 2am versus 2pm.
Feedback rules. Two dozen entries that begin with a mistake the AI made and end with a constraint that prevents the same mistake. “Never overwrite a file the user just sent you.” “When I say ‘revive’ old content, I mean stage it, not publish it.” “Run the build locally before pushing to main.” Each one a scar from a specific day I remember.
This is the thirty percent. It’s substantial. If I started fresh tomorrow, loading these files into a new system would get me past the awkward first weeks. Past the “who are you and what do we do here” phase. Past the re-explanation of everything that should already be obvious.
It would not get me to operational parity.
The Seventy Percent I Cannot Capture
The harder truth. What I tried to document and failed:
Timing intuition. The system has learned when to interrupt me and when to wait. When a question is welcome and when it’s friction. This is not a rule I can write. It’s not “always wait” or “always ask.” It’s contextual in a way that depends on dozens of signals I can’t enumerate because I don’t consciously track them.
Correction-pattern recognition. Over six months, I’ve pushed back on hundreds of outputs. Rephrased. Redirected. Said “no, more like this.” Each correction was specific to a moment. But the aggregate of those corrections produced a model of what I want that’s more precise than any rule set could express. The system doesn’t just know my preferences. It knows the shape of my dissatisfaction. What bothers me before I’ve figured out why it bothers me.
Ambiguity resolution. When I write something vague, the system fills in the correct interpretation more often than chance would explain. Not because it has a rule for handling vagueness. Because it has six months of evidence about what I probably mean when I’m not being precise. This is the layer that feels most like working with a human colleague who’s been in the room long enough.
Energy-state calibration. The system responds differently to me at 9am Tuesday versus 4pm Friday. Not because I told it my schedule. Because it learned that the quality of my input varies, that my patience for iteration varies, that what I need from the interaction varies. This isn’t a rule. It’s a relationship.
I tried to write memory files for each of these. I tried for two weeks. The files were either so vague as to be useless (“be contextually aware of my state,” meaningless as an instruction) or so specific they only covered one situation out of thousands.
The seventy percent is not documentation-resistant because I’m a bad writer. It’s documentation-resistant because it’s emergent. It came from the accumulation of interactions, not from any one decision or preference or rule. You can’t reverse-engineer a forest into a list of seeds.
What This Actually Means
The theoretical framework is well-established. AI working intelligence as a new category of professional capital that accrues outside your head, on servers you don’t own, governed by terms you didn’t negotiate. Four layers. Each compounding on the others. The whole thing spinning inside someone else’s infrastructure.
The theory is correct. I’m living inside the specifics of it.
And what the specifics teach me is this: the thirty percent you can export is not the thirty percent that matters most. The memory files I maintain are a hedge against catastrophe. They’re the break-glass kit. They are not, and cannot be, a substitute for the relationship itself. The most valuable thing my AI knows about me is not anything I told it. It’s what it observed. And observations don’t serialize into markdown.
This doesn’t mean the documentation is pointless. My thirty percent is the difference between a three-month recovery and a six-month one. On exit day, every week you shave off the rebuild is a week your business doesn’t run at diminished capacity.
But I’ve stopped pretending the memory files make me portable. They make me less trapped. Meaningful difference. Smaller than I wish it were.
For Anyone Building on These Platforms
You’re not going to stop. Neither am I. The value is real, and the alternative is a competitive disadvantage measured in hours per day.
Here’s what I’d do, knowing what I know.
Start the memory files now. Not in six months when the dependency feels heavy. Now, when you can still remember what you taught the system last week. Write down voice rules, decision patterns, client context, operational methodology. Write down the corrections. Especially the corrections. Each correction is a datapoint about what you actually want that your future self will not remember without a record.
Accept that the documentation is partial. Don’t mistake a thorough memory file for portability. It’s a hedge. Hedges are valuable. They are not freedom.
Measure your dependency before it measures you. What’s your exit cost in weeks? Which layer scares you most? What’s your break-glass plan? Having a number, even an ugly one, is a different psychological position than a vague sense of exposure.
Build the data layer portable from day one. Behavioral context may be locked inside the platform. Your data doesn’t have to be. Open formats. Self-hosted infrastructure. Postgres you control. This is the one variable you get to set without anyone’s permission.
And recognize what you’re doing. You’re building professional capital in someone else’s house. That’s the trade-off. It’s worth it, today, for most of us. Whether it’s worth it at eighteen months depends on whether the curve bends toward portability or toward lock-in.
I don’t know which way it bends. I know what I’m building in the meantime. And I know what it cost me to measure it honestly.
If you’re building AI-dependent operations and haven’t measured what that dependency actually looks like, the layers, the exit costs, the stuff you can’t export, that’s the conversation a Diagnostic Call is built for. 30 minutes. No pitch. You leave with a map. Book one at mlsebastian.com