← All posts

Context that holds: what to give AI about your work, and what to leave out

Most people paste context into a chat and watch it stop working three turns later. Here is how to build a context store that survives a long conversation, and what must never go in it.

Context that holds: what to give AI about your work, and what to leave out

A context store is the organised set of material you give a model about your work, kept in one place and reused rather than retyped. The reason most attempts fail is not the writing. It is that people put the wrong things in, put too much in, and never notice when it goes stale. Here is what belongs in one, what never does, and how to tell when yours has stopped working.

Why does pasting context into the chat stop working?#

Because a conversation is a queue, not a filing cabinet.

Everything you type sits in one window alongside everything the model has said back. As the conversation grows, the earliest material has less influence over the next answer. Your carefully written brief from turn one is still technically present at turn thirty and is competing with twenty-nine turns of subsequent text.

This is why the failure feels like forgetting. Nothing was deleted. It was outvoted.

The fix is not to write the brief better. It is to stop keeping the brief in the conversation.

What actually goes in a context store#

Five things, and most people only think of the first.

1. What the work is. What your team does, what you are responsible for, who the output goes to. Two paragraphs. The model does not need your company's mission statement, it needs to know that "the deck" means a board deck and not a sales deck.

2. How you write and decide. The rules that would otherwise be corrected every time. Which words you never use. How long things should be. Whether you want the recommendation first or the reasoning first. This is the section that saves the most time and the one people write last.

3. Finished examples. Two or three pieces of real work you were happy with. This does more than any amount of describing. A model matching a pattern you supplied beats a model interpreting an adjective.

4. Decisions already made. The things you do not want reopened. What you chose, and one line on why. Without this, every session relitigates settled questions, which is the most expensive kind of helpfulness.

5. What is currently true. The live facts that change: current pricing, this quarter's priorities, who holds which role. This is the section that rots, and the next section is about that.

What must never go in one#

Anything secret. Credentials, keys, tokens, customer data you are not entitled to move. A context store is a file that gets copied, pasted, shared and synced. Treat everything in it as eventually visible.

Anything you have not decided. A context store is the settled record. Options and open questions belong in whatever you use for thinking. Put an unresolved debate in and the model will confidently pick a side.

Long documents you have not cut down. The instinct is to attach everything. The result is that the useful two paragraphs compete with forty pages, and the model weights them equally. Compressed and current beats complete and stale, every time.

Anything you cannot see changing. If you would not notice this being wrong for a month, it should not be shaping every answer for a month.

How do I actually structure it?#

One folder, four files, plain text or markdown. Not a database, not an app.

FileWhat it holdsHow often it changes
work.mdWhat the work is, who it is forRarely
voice.mdHow you write and decide, what to avoidEvery few months
decisions.mdSettled calls, one line of reasoning eachAdd only, never rewrite
current.mdLive facts with a date at the topWeekly

The split matters more than the naming. Things that change at different speeds should not live in the same file, because you will either update the stable parts unnecessarily or leave the volatile parts stale.

Then attach the folder, or paste the two files that matter for the task at hand. Most tasks need two, not four.

How do I know when it has gone stale?#

Put a date at the top of current.md and check it against the calendar. That is the whole mechanism, and it works because staleness announces itself nowhere else.

Three symptoms worth recognising:

  • The model confidently states something that was true last quarter.
  • You find yourself correcting the same thing in three different sessions.
  • A new person reads the store and asks a question it should have answered.

The third is the most useful test and almost nobody runs it.

Here is a starting point you can run today.

Help me build a context store for my work. Ask me questions one at a time, and do not move on until my answer is specific enough to be useful to someone who has never met me.
Cover, in this order:
1. What the work is and who the output goes to
2. How I write and what I never want to see
3. What decisions are already settled and should not be reopened
4. What is currently true that will change within three months
At the end, give me four separate files, and mark which one I will need to update most often.

What this does not fix#

A context store makes a model consistent about your work. It does not make it right. If the setup around it has no check on the output, a well-briefed model will produce confidently wrong work in your own voice, which is worse than the alternative.

That is a separate piece of work, and it is the one people skip.

Ahead pairs you with an expert operator who builds this with you, on your own work, in your own tools. If you have pasted the same background into a chat more than twice this week, that is a good first hour.