Context engineering with plain files

Context engineering is the practice of deliberately shaping what an AI model sees before it answers: the instructions, the memory, the relevant knowledge, and the tools it can call. It is not prompt wording tricks. It is deciding, on purpose, which pieces of text land in the context window so the model has what it needs and nothing that distracts it. The cleanest way to do that is with plain files you own, version, and can read with your own eyes.

That is the whole argument of this post. If you can see and edit the exact text the model receives, you can debug it, improve it, and trust it. Plain Markdown and text files give you that. A pile of hidden settings and opaque memory does not.

What is context engineering, exactly?

Large language models do not "know" your situation. They respond to whatever text is in front of them at that moment. That text is the context window, and everything useful you want from a model has to enter through it: your request, the rules you want followed, the facts it should use, and the record of what happened earlier.

Context engineering is managing that flow. A prompt is one message. Context is the full set of material the model reads on a given turn. Prompt wording matters at the margins, but the bigger gains come from controlling context: putting the right instructions and the right facts in while leaving the junk out.

There are roughly four kinds of context to manage:

• Instructions: how the model should behave, including its rules, tone, and constraints.
• Memory: what happened before and what was decided, so work carries across sessions.
• Knowledge: the domain facts, documents, and references the task depends on.
• Tools: what actions the model can take and what those actions return.

Good context engineering decides what goes into each bucket, how much, and when. Too little and the model guesses. Too much and it drowns in noise, costs more, and loses the thread. The context window is finite, so every token is a budget decision.

What is an AI harness, and why does it matter?

A harness is the reliable scaffold around the model. The model itself is stateless and forgetful between calls. The harness is everything that wraps it: the system that loads your instructions, pulls in the right knowledge, keeps memory across turns, and routes tool calls. When people say an AI agent "remembers" your preferences or "knows" your project, they usually mean the harness fed that text back in.

The harness is where reliability lives. A clever model with a sloppy harness gives inconsistent results because the inputs change unpredictably from one run to the next. A solid harness gives the model the same footing every time. That is why teams building AI coding agents and assistants now spend more effort on context plumbing than on prompt phrasing.

The question this post answers is what that scaffold should be made of. Hidden databases and proprietary memory stores work, but they are hard to inspect. Plain files are the alternative, and they are easier to reason about.

Why are plain files the cleanest harness?

A file is exactly what the model sees. There is no translation layer between your intent and the input. When an instruction file says "always use metric units," you can open the file and read that line. When the model ignores it, you know precisely what text was in play. Debugging context is mostly reading what the model actually got, and plain files make that trivial.

Files also give you four properties that matter for any serious workflow:

Property	What it gives you
Ownership	The files are yours, on your disk, not locked in a vendor's memory store.
Versioning	Track every change with Git; see when a rule was added and revert a bad one.
Portability	The same instruction and knowledge files work across different tools and models.
Inspectability	You read the exact bytes the model reads, so behavior is explainable.

Compare that with memory you cannot see. If an assistant silently stores "facts" about your project, you cannot audit them, fix a wrong one, or move them elsewhere. Plain text means you can always check the harness yourself. This is the same durability argument behind plain Markdown files for notes: text outlives the app that created it.

What file-based context patterns actually work?

These are concrete, and you can start with one file today.

An instructions file. A single Markdown file that states how the model should behave on your project: conventions, tone, things to never do, preferred formats. Many AI coding agents already look for a project instructions file by convention. Keep it short and specific. Vague rules ("be helpful") waste tokens. Sharp rules ("dates in ISO 8601, no emojis in commit messages") change the output.

A memory file. A running log of decisions and state. At the end of a work session, the important conclusions get written to a Markdown file. At the start of the next session, that file is loaded back into context. This keeps agent memory visible and editable: you can read it, prune it, and correct it. A memory file that grows forever becomes noise, so trim it regularly.

Knowledge files. The reference material the task needs: a style guide, an API description, product facts, a glossary. Keep each as its own file and pull in only the ones a given task requires. Loading your entire knowledge base into every request is the most common context mistake, and a smaller set of relevant files almost always works better than a large dump.

An index file. One small file that points to the others, in the spirit of the llms.txt proposal introduced by Jeremy Howard and Answer.AI in 2024. It gives a model a clean map of what is available and where. Think of it as a table of contents the model reads first, so it does not have to scan everything to find the right file.

A practical loadout looks like this:

• One instructions file, always loaded, kept under a page.
• One memory file per project, loaded at the start of each session.
• A folder of knowledge files, loaded selectively by task.
• One index file that names what exists.

How do you keep file-based context from rotting?

The same way you keep any documentation healthy. Context drifts: a rule goes out of date, a decision gets reversed, a fact changes. Because the files are versioned, you can review diffs and see what changed and when. A short instruction file that is current beats a long one full of stale rules.

Three habits keep it clean:

• Prune memory. Delete decisions that no longer apply. Old context is worse than no context because it actively misleads.
• Split knowledge by topic. Small, single-purpose files are easier to include selectively than one giant document.
• Review with diffs. Treat your context files like code. When the model's behavior changes, check what changed in the files.

It also helps to clean up messy AI output before it lands in your knowledge base. Whatever you save into a knowledge file is text the model will read back later and treat as fact, errors included, so it is worth fixing before you keep it.

The honest trade-offs

Files are not magic. There are real costs.

You have to maintain them. A memory file does not prune itself, and a knowledge folder grows stale if nobody tends it. Hidden, automatic memory asks less of you up front. The trade is control for convenience, and for anything you care about getting right, the control is worth it.

Plain files also do not solve retrieval on their own. When your knowledge grows past what fits in a context window, you still need a way to pick the right files for a given task. Files make that selection inspectable, but you have to do it. And not every tool reads the same conventions yet; the ecosystem around instruction and index files is still settling.

Even with those caveats, the direction is clear. The substrate that survives model changes, tool changes, and vendor changes is plain text you own. Markdown is becoming the language AI tools read and write, which makes a folder of Markdown files the most portable harness you can build.

Where Noteline fits

You can do all of this in any editor that writes plain .md files. Noteline is one option: a local-first Markdown app where every note is a plain text file in a folder you choose, with live preview and offline Word and PDF export. Because the files are yours, they double as instruction, memory, and knowledge files for whatever AI workflow you run, and they version cleanly with Git. The point is not the app. The point is that context engineering works best when the context is just files you can see.