Build the Moat. The AI Models Will Keep Changing. You Will Not Have To

The next step after Asymmetric Decisions: turning your own judgment into leverage that AI can actually use.

If you read the book, you already have the move. This is where it meets AI. Most people learn the hammer and forget to ask if they even need the nail.

There is an ocean of content about how to do things with AI. How to use this tool, how to wire that automation, how to prompt your way to a finished thing. Most of it answers the wrong question.

People start with “how.” How do I use it. Which tool. Which model. Almost nobody starts with “why.” Why am I using this at all. What for. What am I actually trying to move.

So they do what the hype and the FOMO tell them to do. They pile up tools. They subscribe to twelve things. A few months later it is expensive, half of it makes no sense, and they quit and decide AI was overhyped. It was not. The tool was never the problem. The approach was. They spent their energy learning to swing the hammer instead of asking whether the nail needed to go in at all.

Asking “why” before “how” is the asymmetry. It is the highest-leverage move you can make, and it costs you nothing but the discipline to stop and ask it. That is the whole argument of Asymmetric Decisions. This piece is where that argument meets AI.

The part nobody wants to hear

AI changes every week. New models, new tools, new updates. You cannot keep up, and you are exhausting yourself trying.

So stop. The tools and the models will keep changing. The architecture will not. The architecture stays the same for the next twenty years. Only the engine swaps out.

Here is the simple, almost boring truth underneath all of it:

Your leverage is your unique knowledge, your IP, your way of thinking, multiplied by AI.

The data is yours. That is the part that stays rare. Everyone has the same models. Almost nobody has documented their own judgment.

Someone always says, “but AI already knows everything.” Sure. It can answer almost anything. Two problems. You still have to know what to ask. And it cannot filter the way you filter. You are the filter. That is the whole point. Your perspective, your taste, your read on a situation, that is the thing the model does not have and cannot fake.

I did not build an AGI. I built signal.

People ask which AI I use, expecting a secret. I can use almost any of them, because the edge is not the model. The edge is what I feed it.

I do not feed my system information. I feed it essence.

Every day, what passes through my work gets filtered. Notes, conversations, decisions, the lot. Raw input comes in, and what comes out the other side is only what actually mattered. A day that filled ten pages gets distilled to three sentences. I do not keep the noise. I do not store the fact that I was stressed or thinking in circles. I keep the essence. The professional name for this is context distillation, or semantic compression, and it is not a productivity hack. It is the difference between a model that helps and a model that wastes your time.

Here is why, with the receipts.

More context is not better context. Researchers call the failure mode “context rot”: the more you stuff into the window, the worse the model performs, even when you are nowhere near the limit. Chroma tested eighteen frontier models in 2025, including Claude Opus 4 and Gemini 2.5, and every single one degraded as the input grew (Chroma / Redis). A separate Stanford study, “Lost in the Middle,” found accuracy drops by more than thirty percent when the relevant fact is buried in the middle of a long context, replicated across six model families (Liu et al.).

So when people brag about pasting their entire drive into a giant context window, they are quietly making the model dumber. Distillation does the opposite. In retrieval systems, compressing a thousand-token passage down to roughly two hundred tokens of pure signal is standard practice, and it cuts cost while raising accuracy (RECON, arXiv). The token savings are the small prize. The real prize is precision. Essence is a signal-to-noise play, not a cost play.

The other half is the prompt. The discipline of loading exactly the right context for the next step now has a name, endorsed by Andrej Karpathy in 2025: context engineering, “the delicate art and science of filling the context window with just the right information for the next step” (Karpathy). My filters live in that prompt. That is not folklore. It is the dominant frame in production AI right now.

What I actually built, and what it is called

People assume it is one clever app. It is not. It is a layered memory system, what engineers call polyglot persistence. Three layers, each doing what it is good at: plain markdown as the source of truth, a vectorized layer on top for semantic retrieval, and a normal SQL database underneath for the things vectors are bad at, the exact dates and amounts and tasks. I will show you exactly how they connect, with the schema and the flow, in the build below.

One warning before you go and download an app. People hear markdown and immediately think Obsidian, and then think installing Obsidian makes them a context hero. It does not. It is the hammer again. The magic is not Obsidian. The magic is plain text. My notes are markdown files, pure text, no formatting, no lock-in. They open in anything, on any machine, twenty years from now, online or off. Obsidian is just a clean window onto those files. The format is the asset. The app is the glass you look through.

And the asset lives with you, not in someone else’s app. This is the line most people miss. Your system is not a Notion workspace or whatever CRM is in fashion this year. Those tools can be fine for personal use, a place to dump and tidy. But the moment you think strategically, architecturally, the question changes: where does your IP actually live? If it sits inside someone else’s product, it is shaped to their schema, their roadmap, their idea of the average user, and you are renting access to your own knowledge. Your data belongs on your disk, in your own base, on your own server, in a format you control. Not outside. Not bent to fit a tool built for someone who is not you. That is the difference between owning an asset and borrowing a workspace. The asset stays home.

This is not a second brain. It is an architecture of judgment.

Here is where it stops being a notes app and starts being leverage. My system does four things a folder of notes never will.

It checks coherence. When I ask it what I should do, it tells me whether the move is consistent with decisions I have already made, with my architecture, with my business model. That is the Decision Filter from the book, running in software.

It argues with me. A brain built on your own data will happily agree with you forever. That failure mode has a name too: sycophancy, the well-documented tendency of models to tell you what you want to hear. So I built critic agents whose only job is to break the echo chamber. Most people build a machine that confirms them. I built one that contradicts me on purpose.

It catches my patterns. Because the decisions are recorded, the system sees the loop. The same pattern I run in business shows up later in private life, in a different costume, and without the record I would never have noticed. That is the Shadow Pattern Filter from the book. Seeing the pattern is what lets you choose to break it.

And it never decides for me. The AI processes and synthesizes. The decision is always mine. In the trade this is called human in the loop, and in my system the loop is the whole point, not a safety bolt-on.

How this is different from what everyone else is doing

Most “AI second brain” setups are collectors. They hoard raw notes and hope semantic search saves them later. That is collection. Mine is distillation. I throw away ninety percent on purpose and keep the essence.

Most people use AI as a better search box. I use it as a coherence engine and an adversary. Search retrieves. Judgment decides, and checks itself.

The components are all standard: RAG, second brain, polyglot persistence, human in the loop, context engineering. None of it is exotic. What is rare is wiring all of it together over your own IP, with your own filters. The parts are off the shelf. The inputs are you. That is why it cannot be copied.

What you do with it next is the easy part

Here is the part that flips most people’s priorities. Once the base exists, the output is almost trivial. On top of your own documented IP you can build whatever you want: a custom GPT that reasons in your frame, an app, a website, agents that answer in your voice, internal tools for your company, a product for your clients. An entire market already runs on exactly this, assistants and services wrapped around proprietary knowledge.

But notice the order. **The apps, the agents, the tools, the custom GPTs, all of it is downstream. It is output. **It is the fun, visible, easy part, and it is secondary. The asset is the IP underneath. Build the base and you can spin up a hundred different outputs from it, in any direction the market turns. Skip the base and every output is just a clever wrapper around nothing.

That is the real reason this is worth building. Not a faster chatbot. A foundation you own, that survives every model change, and that you can point at any opportunity that comes.

Before you go, two honest questions

Do you have your own IP documented anywhere? Or is it all still in your head and scattered across old chats, half-remembered, impossible to query?

And have you actually thought about how to turn what you know into something only you have? Not more notes. An asset. A filter. A version of your own judgment you can hand to a model and trust.

If the answer is no, that is not a failure. It is the opening. It is exactly where I stood before I built any of this.

Everything above is the why. Below is the how.

I have spent this whole piece making the case and naming the parts. I have not shown you the build. That is deliberate.

Below the line is the actual system. The distillation protocol I run every day, the exact four tests a note has to pass before it is allowed to exist, the note schema, the folder architecture, how the three layers connect, the master-prompt skeleton with the filters wired in, how the critic agents are set up, the daily workflow, and worked examples you can copy and adapt to your own work tonight.

This is not a newsletter. A newsletter rents you attention once a week. This builds you an asset you keep. The price is set on purpose, as a filter. Annual is the move: it is how you commit to actually building this rather than dabbling. There is also a founding tier for the few who want me directly inside their build. You will see the packages the moment you click upgrade.

The price is also a filter, and I mean that as the compliment it is. The people on the other side of this wall are focused on the same problem you are: building a real Moat out of their own expertise. Not tourists collecting another subscription. The cost keeps the room small, serious, and worth your time when you ask a question in it.

Here is exactly what a paid subscription gets you:

The full architecture, documented and copyable. The four-test distillation protocol, the note schema, the folder structure, the master-prompt skeleton, the agent setup. Take it and build your own.

Every premium piece goes past the principle into the build, with worked examples you can implement the same day, not just described but shown.

The Decision Room. Bring a decision you are stuck on, or a part of your build that will not click, and I answer directly. This is the closest access to me short of one on one work.

A vote on what comes next. Paid members shape the topics, the tools I build, and the direction this whole thing takes.

A small room of people solving the same problem. Everyone here has read the book and chosen to build a Moat. That is who you are in the room with.

A founding tier, for the few who want me hands-on. Direct work with me inside your own build, with the membership included. The deepest access there is short of private advisory.

If you have done the reading and you are ready to build, this is the door.

The system, end to end

Strip away the names and the architecture is one loop: input, distillation, storage, retrieval, output.

Most people obsess over output: the agent, the automation, the clever tool. Output is the easy part and the cheap part. The value is upstream, in what you let into the system and what you refuse. Get the input and the distillation right and the output takes care of itself with almost any model. Get them wrong and the best model on earth just produces confident noise faster.

So we build from the front.

The distillation protocol: the four tests

This is the heart of it, and it is simpler than you expect. Nothing enters my permanent store unless it passes four tests. If it fails any one, it is dropped. Not archived. Dropped.

The Essence Test. Is this a conclusion, or just a description? “Had a long call with the client and we talked about pricing” is a description. “Client will not move on price until they see the delivery plan, so lead with the plan next time” is a conclusion. Only conclusions survive.

The Duplication Test. Do I already have this? If the insight already lives in the store in some form, I do not create a second copy. Duplication is how a knowledge base rots into a junk drawer.

The Stability Test. Is this durable, or is it weather? My mood today, a passing detail, a temporary number, none of it is stable. If it will be irrelevant in a month, it does not belong in the permanent layer.

The RAG Test. Is the note self-contained? Will it still make sense when a model pulls it in six months with no surrounding context? If it needs the conversation around it to be understood, it is not finished.

Run honestly, these four tests kill the vast majority of what crosses your desk. That is the point. A day that generated pages of conversation often leaves behind one or two notes, sometimes none. The discipline of throwing things away is the entire skill. Most people cannot do it, which is exactly why your store becomes a Moat and theirs becomes a landfill.

I do not run these tests by hand anymore. A distillation agent does the first pass: it takes the raw material, applies the four tests, and either writes a clean note or returns nothing. I review, I do not transcribe.

The schema: how a note is shaped

Every note that survives gets the same frontmatter. This is what makes the store queryable instead of just searchable.

yaml

"[[Linked_Note]]"

The description field is not decoration. It is the distilled essence in one line, and it is often the only thing a model needs to read to decide whether to pull the full note. The related links are what turn a pile of notes into a graph, so an insight in one domain can surface when you are working in another. That cross-domain link is literally how the Shadow Pattern Filter sees a business pattern resurface in a private decision.

The folder architecture

Structure is not bureaucracy. It is what lets both you and the model know where a thing lives and what it is for. Mine, which you can adapt:

00_Inbox/ temporary, processed within seven days 01_Decisions/ strategic decisions actually made 02_Principles/ operating principles, working philosophy 03_Projects/ one subfolder per project 04_Clients/ client and partner profiles 05_People/ key people who are not clients 06_Architecture/ systems, processes, structures 07_Philosophy/ beliefs, worldview, meta-thinking 08_Insights/ discoveries, conclusions, realizations 09_Content/ material for publication 10_Reference/ external sources, links, quotes 11_Personal/ rhythm, routines, the personal layer

The one folder that does more work than any other is 01_Decisions. That is the substrate of the coherence engine. When I ask the system whether a new move fits, it reads against that folder first. A decision you made and recorded is a promise to your future self. The system’s job is to hold you to it, or make you consciously break it.

The three layers, connected

Now the layers, wired together:

Markdown is the source of truth and the human layer. I read and edit it in plain text. Nothing else is authoritative.

The vector layer (RAG) is a derivative built from the markdown. An indexer watches the notes, embeds them, and serves them to agents and tools through an MCP endpoint. This is the machine layer. I never edit it directly. If the markdown changes, the vectors rebuild.

SQL holds the structured truth: dates, amounts, tasks, anything that has to be exact. Vectors are for meaning, SQL is for facts. Asking a vector store for an exact figure is a category error.

The flow runs one direction: raw input, distilled by the agent into markdown, indexed into vectors, exposed through MCP, queried by tools under a master prompt. The human edits the front. The machines consume the back.

The master prompt: where the filters live

The store is half. The other half is the prompt that sits in front of every serious query. This is where your judgment gets encoded so the model reasons in your frame instead of the internet’s average.

You do not need my prompt. You need the shape of one. A working master prompt carries:

Identity. Who the model is reasoning as, in one tight paragraph.

The filters. The explicit decision criteria. My Decision Filter checks sovereignty, intent, architecture fit, and energy cost. My Shadow Pattern Filter checks whether this is a known loop wearing a new costume. These come straight from Asymmetric Decisions, turned from chapters into instructions.

Priorities. What matters and in what order, business and personal, so trade-offs resolve the way you would resolve them.

Retrieval instructions. When to pull from the store, when to ask SQL, when to say it does not have enough and stop.

Write that once, well, and you stop getting generic answers forever. The model is no longer guessing what a reasonable person would do. It is reasoning as you, against your recorded decisions.

The agents: confidence gates and critics

Two agent patterns do most of the work.

The confidence gate. When a tool or a service queries my system, the second brain answers directly only if it clears a high confidence bar, around ninety percent. Below that, it does not improvise. It routes to me. In practice the system handles the large majority on its own, and the few that reach me are the ones that genuinely need a human. That ratio is the whole promise: the machine takes the volume, you keep the judgment.

The critic. Separate agents, separate prompts, whose only job is to disagree. Before I commit to anything that matters, a critic runs the opposite case. This is the deliberate cure for sycophancy and for the slow drift of believing your own archive. If you build a system on your own data and skip this step, you are building a very sophisticated echo chamber.

Using it: the daily loop

In practice it comes down to a few moves.

The coherence check. Before a real decision, I ask the system whether it is consistent with 01_Decisions and my principles. If it is not, the system tells me, and I either consciously supersede the old decision, which becomes a new recorded decision, or I realize I was about to drift and stop. Either way the choice is conscious.

Narrow context, by hand. When I need a very specific, high-stakes answer, I do not rely only on retrieval. I copy the exact markdown notes straight into the project and let the model work on just those. Narrowest possible context, highest possible signal.

Pattern review. Periodically I let the system surface the loops: the same move repeating across different contexts. That review is where the real change happens, because you cannot break a pattern you cannot see.

The endgame: the filter moves before the thinking

Here is what this turns into if you run it long enough, and it is the part no tutorial mentions.

At first the filter runs after the fact. Something comes in, you analyze it, you decide if it fits. Eventually the filter moves in front of the analysis. The recognition of fit or no-fit arrives before you have even entered the topic. “This is mine” or “this is not,” instantly, because the architecture has been so thoroughly defined that selection becomes pre-cognitive.

That is the real return. A lower cost per decision, less energy bled on distractions that were never going to fit, and a self that is harder to knock off course. In a market where everyone is bombarded by the same noise and the same FOMO, the person with the architecture is not overwhelmed. They have filters. FOMO becomes a signal of noise, not a threat.

Common ways people get this wrong

Collecting instead of distilling. Saving everything is the failure. The four tests exist to make you throw things away.

Editing the vector layer. The markdown is the truth. Touch the front, let the back rebuild.

One giant prompt with no filters. Identity without explicit criteria just gives you a confident generalist.

Skipping the critic. Without an adversary, the system slowly becomes a mirror, and a mirror with good vocabulary is dangerous.

Putting facts in vectors. Dates and numbers go in SQL. Always.

My current stack: the engine, not the architecture

Before this list scares anyone off: you do not need to be an engineer to build this. What you need is the architecture above, and that does not change. The tools below are just my current engine. You can swap any of them, assemble most of it with no-code and AI, or bring the whole thing to the Decision Room and we build it together.

Here is exactly what I run today:

A VPS. A server I rent. Everything lives here, on my own machine, not inside someone else’s app.

Obsidian. The window onto my markdown. Source of truth, plain text, no lock-in.

Telegram. How I actually talk to my brain. I send it a thought, a note, a voice message, and the system takes it in and distills it on the way through. No app to open, no friction.

Claude Code. The agent that runs the distillation and operates the system day to day.

Qdrant. The vector database. The semantic layer my agents query.

Postgres (SQL). The hard facts: dates, amounts, tasks, anything that has to be exact.

My own MCP server. I built an MCP server that exposes this whole brain as context, and I plug it into other apps and tools. They all run on my IP instead of generic data. That is the part that turns a private notebook into infrastructure.

This is my current engine. In two years half of it will have better replacements, and I will swap them without a second thought. The architecture above will not have changed. That is the entire point.

If any of this is unclear, or you have a specific question about your own setup, drop it in the comments. I read them, and the sharpest questions shape what I build and write next.

The Decision Room

This is the part you cannot build alone, and it is the reason for the membership rather than a one-time guide.

The build gives you the architecture. The Decision Room gives you the second thing every serious builder needs: a place to ask, and someone on the same problem to answer. Bring me the decision you are stuck on, the part of your build that will not click, the pattern you suspect but cannot name. I answer directly. And the room itself is the filter working at the social layer: everyone in it has read the book and chosen to build a Moat, so the conversation stays high signal.

What we cover next is decided here, by the people building alongside me.

Your turn

So, honestly: what is the one decision you keep remaking? The choice you have quietly made five times and will probably make again, in business and then somewhere private. That is your pattern. Name it in the comments. Naming it is the first asymmetric move, and it is the whole reason I wrote Asymmetric Decisions in the first place.

Build the Moat. The models will keep changing. You will not have to.

Lucas