From Magic Words to Second Brains: How We Stopped Prompting and Started Building

Remember prompt engineering? Three years ago it was going to be the job title of the future. Courses, certifications, six-figure listings, endless threads of “magic words”: act as a world-class analyst, think step by step, and (my personal favorite) don’t make mistakes. The skill of the era lived inside the sentence you typed.

Then the era ended. Not because prompting stopped mattering, but because we discovered it was the smallest part of the problem.

Era two: it’s not how you ask, it’s what you bring

In June 2025, Shopify CEO Tobi Lütke posted what became the canonical definition of the next era: context engineering is “the art of providing all the context for the task to be plausibly solvable by the LLM”. A week later, Andrej Karpathy, the researcher who coined “vibe coding,” endorsed it: “+1 for ‘context engineering’ over ‘prompt engineering’”, calling it “the delicate art and science of filling the context window with just the right information for the next step.” By September 2025, Anthropic had formalized the concept in its own engineering guidance.

The insight is almost embarrassingly simple once you see it. A model answering your question can only be as good as what it knows when you ask. Wording is maybe 10% of the problem. The other 90% is whether the model has the right documents, the right examples, the right history, and none of the junk. The skill moved from phrasing to curation: what to include, what to leave out, what the model should read first.

But context engineering has a daily-life problem: assembling context by hand, every session, is exhausting. Paste the brand guide. Paste the project brief. Re-explain the client. Tomorrow, do it all again. Which raises the obvious question.

Era three: The Knowledge Architecture Era

That question is why the hottest corner of the AI world right now isn’t a model. It’s folder structure. Markdown vaults, Obsidian setups, “second brains” and “open brains”: personal knowledge systems designed so an AI agent can navigate them. The skill has moved again, from curating context per-conversation to architecting a knowledge system the AI uses on its own. Two builders are worth studying closely.

Jake Van Clief comes at the problem from a completely different angle, and he has published the most rigorous statement of it: Interpretable Context Methodology: Folder Structure as Agentic Architecture, co-authored with David McDermott. His claim is that for any workflow that runs in sequence and has a human checking the output at each step, you don’t need orchestration frameworks like CrewAI, LangChain, or AutoGen. You need numbered folders.

His system, the Model Workspace Protocol, turns a pipeline into a directory: 01_research, 02_script, 03_production. The numbering is the execution order. Each stage carries a plain CONTEXT.md file spelling out three things: what it reads, what it does, and what it writes. The output of stage one lands in a folder, a human reviews and edits it, and stage two reads whatever the human left there. There’s no orchestration layer because the filesystem is the orchestration: stage sequencing is the folder numbering, context scoping is the folder hierarchy, state lives in the files on disk.

The piece worth stealing is his five-layer view of context, because it answers the “what do I load?” question precisely. Layers 0 through 2 handle routing and instructions: which workspace, which stage, what’s the contract. Layer 3 is reference material, the stable rules that persist across every run (voice guides, design systems, conventions). Layer 4 is working artifacts, the stuff unique to this run (the research doc, the draft). His framing for the difference is “configure the factory, not the product”: you set up the reference layer once, then every run reuses it with fresh inputs. The payoff is concrete. Each stage sees only the few thousand tokens it needs, instead of one bloated prompt stuffed with material that belongs to other steps. And handing the whole thing to someone else is just copying a folder.

Nate B. Jones went the opposite direction from a vault of files: he put the knowledge in a database. His Open Brain (OB1) project starts from a grievance he states bluntly, that every AI tool forgets you the moment you close the tab. His fix is to take memory out of any single tool and stand it up as infrastructure you own. The architecture is deliberately boring: one SQL database (he ships it on Postgres via Supabase) with vector embeddings for meaning-based search, exposed through a single MCP server so that Claude, ChatGPT, Cursor, or whatever launches next month all read and write to the same store. You type a thought into a capture channel; seconds later it’s embedded, classified, and searchable by every AI you connect.

The design decision he’s proudest of is separating the raw text from the embeddings in storage, so that when a better embedding model ships (and they keep shipping), you re-index without touching your source data. It’s the difference between a knowledge base that ages and one that compounds. His framing of the larger stakes is the line worth keeping: in the cloud-first model the AI service owns your memory and you visit it; in the model he’s advocating, you own the memory and the models come to you.

Different architectures, same convictions: open, portable formats and standards (markdown, SQL, MCP, not proprietary apps you can be locked out of); a structure explicit enough that the agent knows where to look before it acts; and the shared assumption that the primary reader isn’t you in a browser, it’s an AI agent working on your behalf. As Jones puts it, agent accessibility is the requirement and human readability is the bonus, not the other way around.

From Prompt Engineering to Knowledge Architecture: A Timeline of What the AI Labs Shipped

It’s worth pulling back to see the whole arc at once, because none of this happened by accident. As the vocabulary moved from prompting to context to architecture, the major AI labs were shipping the exact capabilities that made each shift possible. Here’s the same history told through the product releases, receipts included.

My version: PARA plus markdown

I’ll add my own approach to the comparison, because it answers the question I get most from non-developers: do I need to be technical to do this? No. You need to be organized.

My workspace is built on the PARA framework, Tiago Forte’s method of dividing everything into Projects (active, with deadlines), Areas (ongoing responsibilities), Resources (reference material), and Archives (done). PARA predates the AI wave; it was designed for humans. It turns out to be nearly perfect for agents, for the same reason it works for people: everything has exactly one logical home.

On top of PARA, everything is plain .md files: no proprietary formats, no lock-in, readable by any model and any editor, today and in ten years. And borrowing the same instinct behind agents.md and CLAUDE.md files, each area carries its own context file: a short note at the top of the folder that tells any AI (or any human) what this area is, what good looks like, what to read first, and what the boundaries are, including which material is private and off-limits. A canonical positioning file holds the durable facts about my business, so no AI session ever starts from zero.

I know this system works because I built my file structure once and used it in Claude Cowork and Claude Code. When all the hype around Hermes came out, I bought a ChatGPT Pro license, pointed Hermes running Codex at the same folder structure, and it knew everything about me. Organizing your folder structure makes the model and the vendor you choose less important.

The payoff compounds. When I start an AI session, I don’t paste context, I point to it. Conservative estimate: it saves me 5 to 15 minutes of setup per context-heavy task. But the real value is fewer wrong turns, fewer hallucinated assumptions, and an asset that gets richer with every project instead of evaporating when the chat window closes.

What this means if you lead a team

Pull back from the personal-productivity angle and there’s an organizational lesson hiding in this history. Each era moved the leverage further from the individual keystroke and closer to infrastructure: prompts are personal, context is curated, but knowledge architecture is an organizational asset. The companies that get the most out of AI in the next few years won’t be the ones with the best prompters. They’ll be the ones whose knowledge, the processes, decisions, standards, and institutional memory, is structured so that AI can actually use it.

This is the transition happening right in front of our own eyes. Which is, as always, the hard part, and the part we help with. The hardest part of AI isn’t the technology. It’s the transition, and this time the transition is structural. Our Adoption by Design™ workshops include exactly this kind of workflow and knowledge redesign, because handing people a chatbot without restructuring what it can know is how you end up in the 95% of pilots that go nowhere.