Maggie McGuire

The highest-leverage thing a small organization can do to get better results from AI is not a better prompt. It’s a document.

An organizational context document describes how your work actually happens — your people, your beats, your rules, your sources of truth, the things you routinely get wrong. You write it once, you keep it current, and everyone hands it to the AI before asking for anything.

This is the practice behind nearly everything useful I’ve built. It’s also the part nobody talks about, because it isn’t clever. It’s just writing down what you know.

Most of what follows comes from running this daily at a one-person newspaper. Where the tool vendors have published guidance that matches — or corrects — my experience, I’ve said so.

Why bother

1. The model is a commodity. What you know isn’t.

Everyone has access to the same models. What nobody else has is your knowledge of your organization — who the players are, which vendor always misses deadlines, what your style rules are, why you stopped doing that thing in 2023. A model without that produces work that could have come from anywhere, because it did.

In my case, the difference between a useless meeting transcript and a usable public record is a hand-built file of about 370 local corrections. There are six recorded spellings of one county commissioner’s name in it. A generic tool doesn’t know those are the same person — so what it hands you isn’t searchable by the one thing you’d search for.

2. It makes output consistent across people

This is the reason that matters if you have employees. Without a shared document, every person on staff gets a different answer, because every person prompts differently. Your best writer gets good output because she’s good at explaining things. Your newest hire gets mush.

A context document moves that variance off the individual and onto the organization. It’s the difference between “everyone should use AI” and “here’s how we use AI” — and it means a new hire’s first week produces work that sounds like your organization instead of like the internet.

3. It turns institutional knowledge into an asset that survives people

Most of what a small organization knows lives in one or two heads. This is the cheapest way to get it out — and unlike a training manual nobody reads, this one gets used every day, because it’s what makes the tool work.

Important: it shapes behavior, it doesn’t enforce it

Before you write a word, understand the limit, because this is where organizations get themselves in trouble.

A context document is context, not configuration. Anthropic is explicit about this for Claude Code: these files are “context, not enforced configuration,” delivered to the model as a message, with “no guarantee of strict compliance, especially for vague or conflicting instructions.”

So if you write “never put customer data into an AI tool” in your context document and consider the matter closed, you have written a strong suggestion, not a control. Anything that must never happen needs actual enforcement — a permission setting, a blocked integration, a technical gate, a policy with teeth — not a sentence in a file.

Write the rule in the document too. Just don’t mistake it for the lock.

Two different things, often confused

Know which you’re making. Mixing them produces a document that does neither job.

• Reference data — a roster of names, a vocabulary list, a chart of accounts, common misspellings. A lookup, not prose. Often consumed by code rather than read by a model, and it should be structured, boring and complete.
• Working instructions — how you make decisions, which source wins when two disagree, what must never happen. Read by the model, and it should be short, specific and opinionated.

My meeting-coverage system uses both. The vocabulary file corrects the transcript before any model sees it. The instruction document tells the model that when the transcript and the official agenda disagree, the agenda wins — and that a vote the record doesn’t resolve publishes as a question mark, never a guess.

What goes in it — the test is what it would cost the model to find

The useful question isn’t “what describes my organization.” It’s what would the model have to guess at?

Put in what is expensive or impossible for it to obtain, and leave out whatever it can work out from the material you’re already handing it. This matters more than being thorough, because every line you add costs you adherence on every other line.

High value — it cannot get these anywhere:

• Staff names, roles, and who owns which decision. Including how to spell them.
• Local businesses, their addresses, who runs them. The developer, the contractor, the family that’s owned the hardware store since 1978.
• Place names, street names, project and development names — and critically, the variants that get misheard or misspelled. My file has six recorded spellings of one commissioner’s surname.
• Sources of truth, ranked. For each kind of fact, which source wins. In mine: item titles and addresses come from the agenda; dollar figures from the staff packet; direct quotes from the transcript; vote tallies stay flagged until the official minutes post. When two sources disagree there’s no argument — the hierarchy already decided.
• The things that aren’t written down anywhere. Which vendor misses deadlines. Which official never returns a call. Why you stopped doing that thing in 2023.
• Your conventions where they differ from the obvious default, and the errors you make repeatedly, each with the rule that prevents it.

Low value — leave it out:

• Anything derivable from the documents you’re already attaching.
• General industry or style knowledge the model already has.
• Restating what’s on your website.
• Descriptions of your organization written for an outside audience. This is a working file, not an About page.

Anthropic’s guidance for their own memory files lands in the same place — keep the pitfalls, the rationale, and the conventions that differ from defaults; cut what the tool can derive for itself.

What to leave out on purpose

One caution before you start writing, because this guide is telling you to write down how your organization actually works and then hand it to a piece of software.

A context document is a document. It gets pasted into tools, stored in accounts, synced to laptops, and shared with new hires. Anything in it should be something you’d be comfortable having outside your building.

So: no client or patient information, no personnel matters, no credentials, no unpublished legal or financial detail, and nothing a source gave you in confidence. If you work somewhere with real confidentiality obligations — a clinic, a firm, a school — check your own policy before any of this goes into a vendor’s tool, and use whatever approved account your organization provides rather than a personal one.

The good news is that the highest-value material is mostly not sensitive. Correct spellings, street addresses, who chairs which committee, which source of truth wins — that’s public or near-public information that happens to be scattered and slow to gather. That scattered-ness is the value.

How to write it: from incidents, not imagination

Don’t sit down and try to describe your organization. You’ll produce something abstract and vaguely true, and it won’t help.

Write it from things that went wrong instead. Every rule in my system exists because something specific happened. A transcript garbled a company name, so the agenda became authoritative for names. A dollar figure came out a thousand times too large, so money now comes from the staff packet. A safety check quietly returned nothing for weeks, so every check now has to prove it can fail before I trust it.

Anthropic’s guidance gives essentially the same triggers — add to the document when the model “makes the same mistake a second time,” or when “you type the same correction or clarification into chat that you typed last session.” My own rule of thumb: if I give the same correction three times, it stops being a correction and becomes a line in the document.

Do that for three months and you’ll have something no consultant could have written for you, because it’s made entirely of your specifics.

Four traps

• Length quietly destroys it. The counterintuitive one. A long document isn’t truncated — it’s followed less often, and nothing tells you. Anthropic’s guidance for Claude Code is unusually blunt: target under 200 lines, because “longer files consume more context and reduce adherence.” That specific number describes how one product loads one file — if you’re pasting context into a chat window your constraints differ — but the direction holds everywhere. Their context-engineering write-up explains why — as the context grows, “the model’s ability to accurately recall information from that context decreases,” and good practice means finding “the smallest possible set of high-signal tokens.” Emphasis won’t rescue a bloated file either: bold twenty lines and none of them stands out. The lever is subtraction. Every time you add something, find something to cut.
• Vagueness. Write instructions concrete enough to verify. “Use 2-space indentation,” not “format code properly.” “Run the tests before committing,” not “test your changes.” The same applies outside code: “call the county clerk to confirm any vote tally,” not “be accurate.”
• Duplication guarantees drift. If a rule lives in two documents, one will be wrong within months and you won’t know which. Anthropic notes that when two instructions contradict each other, the model “may pick one arbitrarily.” Give every rule exactly one home and point at it from everywhere else.
• An unread document doesn’t exist. It’s easy to end up with files that are accurate, carefully maintained and never actually reached, because nothing points at them and nobody remembers they’re there. A document only works if something routes people to it. When you write a new one, decide in the same sitting what will reach it — a link from wherever people start, a line in onboarding, a step in the workflow itself.

Start this week

You don’t need a system. You need one file. And yes — the first version has to come out of your head, because you haven’t collected any incidents yet. That’s fine. Write the obvious things now; the document gets good later, from what goes wrong.

1. Open a plain text document. Give it an obvious name.
2. Write the twenty proper nouns your work depends on, spelled right, with the variants people get wrong.
3. Write your sources of truth, ranked — for each kind of fact you handle, which source wins.
4. Write the five things that must never happen — and separately, decide which of those need a real technical control rather than a sentence.
5. Paste the whole thing at the top of your next AI conversation and see what changes.

That’s an afternoon, and it will do more for your output than any prompt technique you’ll read this year. Then keep it alive the only way that works: every time something goes wrong, add the rule that would have prevented it — and cut something else to make room.

If you build one and it works — or if it doesn’t — I’d like to hear about it. maggie@moabsunnews.com

Quoted guidance is from Anthropic’s documentation on project memory and Effective context engineering for AI agents. Both are written for Claude specifically; the principles have held for me across tools, but that part is my experience, not their claim.