← All posts

What fixes generic AI content: context engineering, not better prompts

Pasting your company context into the prompt works, and you pay for it again on every piece. Context engineering moves that knowledge into files you own, and the first version takes an afternoon.

In the last article we watched a generic blog post about meetings get specific once you hand the model what the first prompt left out. Give it what the company believed about meetings, who it was writing for, what those readers had already tried, and the one message worth remembering, and the draft stops sounding like it could have come from anyone. It works, and you can use it this afternoon, but the catch shows up on the article after it.

The fix was context, and you pay for it every time

Say the meetings piece went well and now you're writing about how your team handles customer feedback. Some of what you assembled last time still applies word for word, like who you are, what you believe, and how you sound. Some of it has moved on, because the product has shipped twice since then and the pricing page doesn't say what it used to. And some of it doesn't exist yet, because this piece needs a customer insight and an angle you've never written down anywhere. You're not starting from nothing, but you have no reliable way to tell which of the three you're looking at, so you go and check all of it again.

That's roughly twenty minutes before you write a word, and another half hour afterwards taking out everything that doesn't sound like you. The typical setup behind one published article is a notes app, a knowledge base, an AI tool, and a separate editor, all kept in sync by hand. None of the information is missing, it's just scattered, and you're the only thing connecting the pieces.

When ChatGPT and Claude first went mainstream, the message box was the only door into the model, so that's where the context went. If the model can't see what you know, paste it in. That's prompt engineering, it was the right instinct at the time, and plenty of people made it more bearable by keeping a scratch document of the paragraphs they paste at the start of every session.

What none of that does is compound, because the scratch document doesn't know what's changed since you last edited it, and whatever you work out about your voice while editing a draft stays inside a conversation you'll never open again. So the cost doesn't go down as you publish more, it just comes back around, and you fix the same problems the same way.

The tools started remembering, which helps and doesn't

The AI companies noticed the same repetition, and their answer was memory. ChatGPT and Claude can both carry useful context from earlier conversations into later ones, alongside custom instructions and project files. You can manage what gets remembered, and that removes a lot of retyping.

What memory still doesn't give you is a portable company source of truth. It is a recall layer inside one vendor's product, not a set of durable files your team owns. It can remember a claim without knowing whether that claim is still current, canonical, or relevant to the draft in front of you. It's a decent answer to "the AI keeps forgetting my preferences" and no answer at all to "our company knowledge lives nowhere in particular."

The better answer came from people writing code

Coding agents like Claude Code read and write files on disk directly, and that turned out to matter well outside of code. Once people had an AI that could open and edit the files on their own machine, they started pointing it at notes they already had. Context stopped being a thing you paste into a chat window and became a folder the tool reads by itself.

The same pattern is spreading in public. Andrej Karpathy's LLM Wiki is an idea file he published in April for a markdown wiki that a model builds and maintains from raw sources, and its comment thread filled up with people who had already built their own. Several had landed on the same shape without talking to each other: markdown files, frontmatter, links between pages, and a periodic check for claims that have gone stale.

None of this requires you to write code; it started in developer tools only because developers had agents that could read folders first.

Context engineering

Context engineering is the work of organizing your company's knowledge, keeping it current, and choosing which parts of it belong in the task in front of you.

Prompt engineering asks how to word the request. Context engineering asks what the model should know before you make the request at all, and where that knowledge lives when you're not writing. It's a shift from getting one draft right to building something that makes every draft start further along.

A sharper prompt won't tell you that your pricing page has been wrong since March, and a newer model won't decide which four things this particular article needs. Both sit downstream of whether the context you handed over was current and correctly chosen. The conversation has been moving from which model to use toward how you feed the one you've got, and that's the more useful question now that the models are all pretty good.

What that looks like on your machine this afternoon

Start with a folder of plain markdown files that you own, one subject per file, and keep the subjects to things that don't change every week: what you sell and how it actually works, who you're writing for and what they've already tried and abandoned, what you believe about your corner of the market that your competitors don't, and how you sound down to the words you refuse to use.

Use ChatGPT Work in the ChatGPT desktop app or Claude Cowork in Claude Desktop; both can work against a folder on your machine. If you prefer a terminal or editor, Claude Code and Codex give you the same file-backed starting point. The difference from a chat window is that you're choosing which parts of your context this article needs, rather than hoping the right memory happens to surface.

That's the whole setup, and four practices keep it working. We learned all of them the slow way on our own content:

  • Keep the folder legible. Group files by subject and name them so you can tell what's inside without opening them, because the agent is working from those names too. If it can't tell what's where, it reads everything or it reads the wrong thing.

  • Write the instruction file. This is the step most people skip, and it's a CLAUDE.md or an AGENTS.md at the top of the folder depending on which tool you use. Say what's in here, which file to read for what, and which parts are durable context as opposed to raw notes and transcripts. Without it the agent guesses, and it tends to guess that a half-formed idea from a meeting carries the same weight as settled company policy.

  • Let the agent do the distilling, then read what it proposes. Point it at your notes and transcripts and have it suggest updates to the durable files rather than writing them yourself. Reviewing a proposed change is much faster than composing one, and the review is what keeps the folder worth trusting.

  • Treat a hallucination as a context problem first. When the agent says something confidently wrong about your product or your positioning, go and read the file it should have been working from. Usually that file is out of date, and the model was doing what you asked with what you gave it.

Four folders of markdown files, named Product, Company, Market, and Brand, holding files like Pricing.md, Team.md, Positioning.md, and Voice & Tone.md
Our own durable context, one subject per file and grouped so that we and the agent can both tell what's where. This article was written from it.

Where this stops being something you can do on the side

A folder and an instruction file will take you a long way, and for plenty of articles it's enough. It runs out in two places.

The structure is yours to figure out: what deserves its own file, what's durable enough to belong in the folder at all, where a thing goes when it fits nothing you've made, and how to teach the agent to navigate whatever you came up with. The upkeep is yours too, because nothing updates the folder when your pricing changes, nothing flags the positioning file as wrong since you rewrote the homepage, and nobody reviews any of it before it shapes what you publish. That's fine at four files and tiring at thirty, and right now it's nobody's job, so it lands on whoever happens to be writing.

That's the part we're building Inbind to cover for you. The next article in this series, "How we ground content in Inbind: the Binder as structured context," is the version of this we ended up building for ourselves, and it's what we used to produce the article you're reading. We'll link it here as soon as it's published.