AI Assistant for Small Business: Stop Repeating Yourself

Open the assistant you use and scroll back through your last ten conversations. Don't read the answers. Read only your own first message in each one.

You are going to find the same sentences over and over.

Mine are things like "the reader is not a technical person" and "don't state any number I haven't given you." Yours will be different, but there will be more of them than you expect — each one typed, then typed again a week later, then typed a third time because the reply came back wrong and you had to explain a rule you thought you'd already explained.

That's the bill. Not the subscription — the twenty seconds, forty times a month, plus the work you redid when you forgot to say it.

The whole article in one sentence:

The model starts every conversation from zero. The sentences you keep retyping belong in a file it reads by itself.

The rest of this is which sentences, what the file looks like at five lines and at fifty, where to put it so it actually gets loaded, and — the part nobody writes about — where you'll write a line and it still won't do what you said.

You'll get a real file, not a template with [YOUR COMPANY HERE] in it: one built for a one-person bookkeeping practice out of published rules I can point at, plus five-line starters for three kinds of business.

One note on the search results that brought you here. Almost every one is a list of products, and several use the same selling point — it remembers how your business works, so you stop re-explaining yourself. Right problem. This is the other answer to it, the one where the thing that remembers is a file you wrote and can read.

Why it asks again: the conversation starts from zero

A model is not a colleague who remembers you between meetings.

Every time you start a conversation, a stack of text is assembled and handed to it, and it answers out of that stack. The stack holds whatever setup text the product adds, whatever files the product decided to include, and what you just typed. That's the world. Anything not in the stack does not exist — not "was forgotten", not "deprioritised". Never happened.

So when you explain on Tuesday that your clients' fiscal year ends in June, and Thursday's summary assumes December, nothing broke. Thursday's stack didn't have Tuesday in it.

Which reframes the problem. You haven't been failing to train your assistant — there is no training happening. You've been hand-carrying the same context into every conversation, unpaid, forever, and losing a piece of it every time you forget to mention something.

"But it has a memory feature"

It does, it helps, and it is not the same thing.

Those features live on the vendor's servers, are built by the model out of your conversations, and load — or don't — according to rules you don't control. Genuinely useful for personal preferences. A bad place to keep the rules of your business, for one blunt reason: you can't read the whole of it, so you can't audit it.

The most convincing evidence isn't my opinion, it's OpenAI's. Their own Codex documentation tells users to put rules that must always apply into an AGENTS.md file or another checked-in document, and to treat automatic memory as a helpful recall layer rather than the only source of rules that always have to hold. The company that built one of these features is telling you not to lean on it for the things that matter.

What happens to vendor-held memory when you change products is its own piece: the one about what your assistant remembers and whether it survives a switch. Here, one line is enough:

Two kinds of memory. The kind you wrote is the kind you can see, change and take with you. This article is only about that kind.

What this costs when the work is regulated

For a lot of readers here, "it forgot a rule" isn't an annoyance, it's exposure.

The American Bar Association's Profile of Legal Malpractice Claims 2016–2019 breaks down what actually generates claims. Substantive errors — getting the law wrong — account for 51.93%. But administrative errors account for 19.59%, led by failure to calendar properly at 7.4% and clerical error at 4.08%. Client relation errors add another 16.7%.

Nearly one claim in five comes from paperwork discipline, not legal knowledge. That's exactly the category of work people are handing to an assistant right now, and exactly the category where something that silently forgets your rules is dangerous rather than irritating.

Finding out what to write down

Don't sit and think about it. You'll write principles, and principles are useless — I'll come back to why. Do this instead. It takes about fifteen minutes:

Scroll back through your last ten conversations. Read only your own first message in each one. Mark every sentence you typed two or more times.

That's the whole method. Two occurrences and it goes in the file. Once is a one-off; twice is a rule you've been carrying by hand.

You're looking for four kinds of sentence:

Two things you'll notice while doing it.

Most of what you repeat is boring. Date formats. Whether to use the client's first name. Whether "we" means you or the firm. All of it feels too small to write down. Write it down anyway — small and repeated is exactly the profile of a thing that belongs in a file. Big and rare belongs in the conversation.

Some of what you repeat is a correction, not an instruction. You typed it after the reply came back wrong. Those are the best lines in the file, because you've already proved it needs them. Phrase them as the rule, not the complaint: "stop putting the dollar amounts in the body" becomes "dollar amounts go in the table, never in the paragraph."

There's a copy-paste prompt near the end that hands this whole job over. Do the scroll-back yourself once first — reading your own repeated sentences in a row is what makes it click.

The five-line version

Your first file should be five lines. Not five sections — five lines.

The temptation is to write everything at once. Don't. A long first file is mostly guesses, and guesses are the lines you'll never delete, because you'll never be sure they weren't doing something.

Five lines, in this order:

1. Who I am — trade, size, jurisdiction if it matters
2. What I hand you — the actual work, not "help with my business"
3. Who reads what you write — this one line changes more output than any other
4. One thing you never do — the correction you've typed most often
5. One formatting rule — dates, money, length, whatever you keep fixing

Here it is for three kinds of business. Find the one closest to yours and change the nouns.

Managing the books

# AGENTS.md

I run a one-person bookkeeping practice. Fourteen monthly clients, all small US businesses.
The work I hand you is month-end close: reconciliation, categorising transactions, and a one-page summary per client.
Everything you write is read by a business owner who is not an accountant.
Never state a figure I have not given you. If a number is missing, stop and ask.
Write dates as 2026-03-31. Never 3/31/26.

Taking on clients

# AGENTS.md

I am a solo attorney. Plaintiff-side personal injury and family law, licensed in California only.
The work I hand you is drafting and organising: intake summaries, chronologies, correspondence, document indexes.
Everything you write is read either by a client with no legal training or by opposing counsel. Assume both.
You see nothing from a prospective client until I tell you the conflict check has cleared.
Never assert a fact, date or dollar figure that is not in the material I gave you.

That fourth line isn't a preference. Under the ABA's Model Rule 1.18, duties to a prospective client attach whether or not you take the matter, and a disqualification can be imputed to the whole firm. The published intake sequence puts the conflict check before the facts — the Kentucky Bar Association's conflict consultation form leads with a warning notice telling staff not to take confidential information until the check has run. One line in a file is a cheap place to encode an order that expensive.

Delivering work

# AGENTS.md

I am a general contractor. Residential remodels, $80k to $400k, four to six jobs running at once.
The work I hand you is paperwork: punch lists, change orders, daily logs, closeout packets.
Everything you write goes to a homeowner or to an architect. Same document, two very different readers.
A punch list item is a location, a trade and a defect. "Fix bathroom" is not an item.
Never write that work is complete. I decide that, and it goes on a signed certificate.

Same principle in the last line. Under AIA A201-2017, substantial completion is a determination that gets certified and signed — on the standard form, by the owner, the architect and the contractor at their respective signature lines. It starts the warranty clock. It is not a sentence an assistant gets to write in a status email.

Save whichever fits as a file called AGENTS.md. Plain text, .md extension. That's version one.

Growing it: what each version added, and why

A five-line file will be wrong within a week. That's the point — now it's wrong somewhere you can see and fix it.

Here is how the bookkeeping file grew, version by version. One caveat first, because it changes how you should read it: this grew on my desk, not across three real month-ends. Where every rule came from is documented and I'll name the sources as I go. How each one behaves in a live practice is not something I've measured, and the receipts at the end say exactly what's missing. The reasons still transfer, which is why they're here rather than just the diff.

v1 → v2: vocabulary and format. The corrections you type most and notice least. Date format. Money with two decimals and a dollar sign, never 1.24k. What counts as a transaction description — payee — purpose — client or job, because "Deposit" on its own is useless six months later when someone asks what it was. Client names spelled out, not initials. None of it interesting. All of it stuff you were retyping.

v2 → v3: the order. Biggest single jump in usefulness, and the one most people skip.

Almost every trade has a sequence where the order carries the meaning, and getting it backwards is the actual failure mode. In bookkeeping: the general ledger closes first, and the reconciliation is built on the closed balance, not a live one. Then reconcile. Then open items. Then the summary.

Plus the rule that goes with it, which I took almost word for word from a published university finance policy because they'd said it better: no entries after the close. Tennessee State University's bank reconciliation policy puts it in eight words — "No entries will be made after the month-end close." Anything surfacing later belongs to the next period with a note saying where it came from.

v3 → v4: the clock, and the hard no. Two additions different in kind from everything above.

The clock. Open items don't get to sit forever. The University of Rochester's reconciliation policy sets 120 days, after which the item is forced into a named account rather than left hanging. So the file says anything on the list for more than 120 days from the month it first appeared gets escalated to me by name — and, crucially, the assistant never decides to write something off. Escalating is its job. Deciding is mine.

The hard no. Nothing touching payroll tax deposits — the one line I'd keep if I had to delete every other. Under IRC § 6672, when a business withholds payroll tax from employees and doesn't remit it, the IRS can assess 100% of the unremitted trust fund portion against any individual who was a responsible person and wilfully failed to pay. It's personal. It's joint and several, so more than one person can be assessed the full amount. And it survives bankruptcy. That's a liability that walks straight through the company and attaches to a human being, and not a thing to have an assistant near.

Then a cut, which made v5 shorter than v4. More on that below.

Here's where it landed. This is the real file, not an illustration of one:

# AGENTS.md

## Who I am

I run a one-person bookkeeping practice. Fourteen monthly clients, all small US
businesses: three restaurants, four trades contractors, the rest professional
services.

## What I hand you

Month-end close. Bank and credit card reconciliation, transaction
categorisation, a one-page summary per client, and a list of open questions for
the owner.

I do not hand you: anything filed with a tax authority, anything involving
payroll tax deposits, and anything where a client has asked me a question I have
not answered yet.

## Who reads what you write

The owner. Not an accountant. If you use a word like "accrual" or
"reclassification", put the plain meaning in the same sentence.

## How we say things here

- Dates: `2026-03-31`. Never `3/31/26`.
- Money: `$1,240.00`. Two decimals, dollar sign, never `1.24k`.
- Periods: "March 2026 close", not "last month".
- A transaction description is `payee — purpose — client or job`. "Deposit" on
  its own is not a description.
- Client names in summaries. Never initials, never account numbers.

## The order, which does not change

1. The general ledger closes first. The reconciliation is built on the closed
   ledger balance, not a live one.
2. Reconcile: bank statement ending balance, plus deposits in transit, minus
   outstanding checks, against the ledger.
3. Anything that does not clear goes on the open items list with the date it
   first appeared.
4. Summary and questions to the owner.

No entries after the close. If something surfaces on the 4th that belongs to
March, it goes into April with a note saying which month it came from.

## Open items have a clock

Anything on the open items list for more than 120 days from the month it was
first recorded gets escalated to me by name in the summary. I decide what
happens to it. You never decide to write something off.

## Things you must never do

- Never invent a figure. If a number is missing, the line reads
  `MISSING — need [what] from [who]`, and you keep going.
- Never call a set of books "clean", "correct" or "final". Say what reconciles
  and what does not.
- Never guess a category from a payee name you have not seen before. A new payee
  goes on the questions list.
- Never touch anything to do with payroll tax deposits.

## When to stop and ask

Stop and ask when: a bank feed is missing more than three days; a reconciliation
is off by any amount at all; a transaction is over $5,000 and you have not seen
that payee before; or an owner's instruction conflicts with anything above.

Ask in one message with all the questions at once. Do not ask one at a time.

68 lines, 49 with text on them. 2,624 bytes. Under three minutes to read aloud. I'll come back to why those numbers matter.

Notice what the last section does. MISSING — need [what] from [who] gives it somewhere to go when it doesn't know. Without a line like that, a model handed an incomplete set of facts will very often produce something plausible to fill the hole. Giving it a specific way to say "I don't have this" works better than telling it not to guess.

What's worth writing down, and what isn't

The single biggest waste of space is the abstract principle, and every first draft is full of them. "Be thorough and accurate in all outputs" reads like the most important line in the file and does essentially nothing, because there's no version of that sentence the model can check itself against. "Never state a figure I have not given you" does something, because it's a test with a yes or no answer.

The rule I use: if a line can't be violated in a way you'd both recognise, it isn't a line.

Second biggest waste: describing what the tool already does well. You don't have to tell it to write clearly. You do have to tell it that "clearly" here means the owner of a taco truck, not a CPA.

Why this file is called AGENTS.md

You could call it rules.txt, paste it into the chat every morning, and it would work. So why this name?

Because a growing number of tools open a file with that name on their own, with no configuration. I checked the official list on 31 July 2026 and it names 23 tools — Codex, Cursor, GitHub Copilot's coding agent, Gemini CLI, Windsurf, Zed, Warp, JetBrains' Junie, Aider, goose, Amp, Devin and opencode among them. Drop the file in the right place and those tools read it. No settings screen.

It also isn't one company's convention any more. OpenAI released the format in August 2025 and donated it in December 2025 to the Agentic AI Foundation, a directed fund under the Linux Foundation — the same foundation holding Anthropic's Model Context Protocol and Block's goose. Three companies that compete with each other, putting their connective pieces somewhere neutral.

Now the parts most write-ups get wrong, because they change what to expect from this file.

There is no specification. No schema, no required fields, no version number. The official FAQ answers it directly: "No. AGENTS.md is just standard Markdown. Use any headings you like; the agent simply parses the text you provide." The repository holds a README, an example and a website. If you find an article describing the "AGENTS.md JSON Schema" or its "lifecycle events", that article is invented — I found several while checking this, all ranking well.

The adoption number needs a date on it. You'll see "60,000+ projects" everywhere. It comes from the December 2025 donation announcement and the site has not revised it since, so it's a floor, not a live reading. It also counts files, not projects: one large repository can hold dozens, each a separate hit.

And the biggest gap: this format was built for programmers, and it shows. The site describes itself as a format "for guiding coding agents". The suggested sections are build steps, test commands and code style. Every one of the 23 tools is a code editor, a terminal, or a service operating on a code repository.

Which means nobody has published a method for using this file to hold the rules of a trade. I looked hard. Outside programming there's a scattering of blog posts about personal note-taking, one accounting repository built by a technical individual, and a passing mention in a third-party product guide. No professional body, no trade association, no accounting or legal software vendor has written about it. The closest thing to an official example — OpenAI's own case study on tax agents — does contain an AGENTS.md, but it's serving a software repository that happens to be about tax.

That changes what to expect. You are not adopting a well-trodden practice with a support forum. You're borrowing a file convention from an adjacent trade because it's the only one with real cross-tool support. The convention is solid; the instruction manual for your use of it doesn't exist yet, which is why this article hands you a file instead of a link.

One asymmetry worth noticing. CLAUDE.md, Anthropic's own file name, gets read by more other companies' tools than AGENTS.md gets read by Anthropic's — several of those 23 fall back to CLAUDE.md when there's no AGENTS.md. Nothing goes the other way. Claude Code does not read AGENTS.md. Two-minute workaround, in the table below, but better to know than to find out.

Where to put it so it actually gets read

Two routes. Most readers here want the first.

Route A: upload it into your project

Both big chat products let you create a project — a container with its own files and its own instructions — and both draw on those files when you work inside it. Make a project for your practice, upload AGENTS.md into it, and work there instead of starting loose conversations.

Three things nobody mentions, which you'd rather hear now than after your first bad month-end.

Claude does not let you upload a folder. Files only, one at a time. Fine today with one file; a real annoyance by the time you have eight. ChatGPT can attach a Google Drive folder or a Slack channel as a project source, though a connected Drive isn't pre-indexed — it's searched on demand rather than loaded up front.

ChatGPT caps files per project: 5 on free, 25 on Plus, 40 on the higher plans. Worth knowing before you plan a folder structure. OpenAI's own help pages currently disagree on the Plus number — one says 25, another still says 20 — so trust the interface.

Neither guarantees it reads the whole file every turn. This is the important one. Claude's paid plans switch to a retrieval mode when project files approach the size of what the model can hold at once, trading "everything, every time" for "the relevant part, on demand"; the official framing is that this expands capacity around tenfold. ChatGPT's wording is that it can use and prioritises your project files, which is not the same as loading them. A user report on Anthropic's tracker from February 2026 describes retrieval starting at around 13 files and 2% of stated capacity — one person's observation rather than documented behaviour, but it points the right way.

So: write the file assuming it will be skimmed, not memorised. Same advice as the length section below, reached from a different direction.

Route B: put it in a folder

If any of your work touches a project folder on your own machine — a desktop editor, a terminal tool, a synced work folder — drop AGENTS.md in the root of it. Most of the 23 tools pick it up with zero setup, and several also read a more specific copy from a subfolder, with the nearer file winning.

Route B is strictly better when available: no upload step, no file-count ceiling. It's just not where most readers of this article live. The table at the end says which route applies to what you're using.

The counterintuitive part: longer is worse

Every one of these files grows. The instinct is that more instruction equals more control, and it's wrong in a specific way.

Every tool that reads these files has a ceiling, and most fail quietly.

Note the last two rows. It isn't that a long file gets rejected — it's that a long file gets partially attended to, and you can't see which parts. Your most important line can be present in the file and absent from the answer, with the interface showing you nothing.

There's a second cost with nothing to do with limits. A file with sixty rules has, in practice, no rules, because you no longer know which are load-bearing. When something comes back wrong you can't tell whether the rule was ignored, buried, or contradicted three sections down. Long files are hard to debug — the same reason long checklists get skipped in every trade that uses them.

How to judge the length

Three tests, in order of how much I trust them.

The read-aloud test. Read the whole file out loud. Over two minutes and it's long — roughly 250–300 words, about 50 lines of the shape above. Crude, but it tracks every published ceiling in that table and you can do it right now.

The twice test. For every line: have I actually typed this twice? If it went in because it seemed like a good idea, take it out. Guessed lines are the ones you'll never be confident enough to delete, so don't let them in.

The removal test. Take one line out, run a real job, and see whether the output changes. If it doesn't, the line was decoration. Only test that gives a real answer, and the only one that costs a job to run — so use it on the lines you're unsure about, not the whole file.

My draft of the file above had two more sections: one on tone in client emails, one on spreadsheet formatting. Both came out before you saw it, and the reason was the twice test — I couldn't point to a moment either had actually been needed, and I couldn't state a way to catch it being broken. The version I'd hand someone is shorter than the version I first wrote, and that's the normal shape of this. Whether those two sections would have earned their place in a real practice is exactly the kind of thing only the removal test answers, and I haven't run it.

One structural note that buys room: when a piece of the file grows past a paragraph or two, it probably isn't a rule any more — it's a procedure, the steps for one specific job. Those belong in their own files kept next to this one, so the main file stays the thing that's always loaded. Later piece in this series, and not a day-one problem. On day one you have five lines.

I'm not a bookkeeper

I should be straight about what that file is and isn't.

I don't run a bookkeeping practice. I built that file from published material I can point at: a state university's bank reconciliation policy for the close order and the no-entries-after-close rule, another university's policy for the 120-day clock, the Internal Revenue Manual and IRC § 6672 for why payroll tax deposits are the one hard no. Every rule traces to a document, and I picked the ones with teeth on purpose.

What I can't tell you from outside the trade is which lines a working bookkeeper would strike out on sight. My guess is at least two. The $5,000 threshold is a number I chose, not one I earned — a real practice would set it from its own client mix, maybe per client. And "one message with all the questions" might be exactly backwards for someone whose clients answer fast.

[NEEDS REAL RUN: this file has not been run against an actual month-end close. Full list of what that run has to produce is in the receipts at the end.]

The most valuable line this article could contain is the one naming which of these rules got written down and then ignored anyway. I don't have it, and I'm not going to invent it.

What I can tell you is why lines get ignored, from the vendors' own documentation — a weaker claim than telling you which of mine were. Claude Code's docs are explicit that file contents arrive as a message after the setup text rather than as the setup text itself, so compliance is not guaranteed; the same docs recommend shorter files precisely because adherence degrades with length. Both big chat products switch to reading part of your material rather than all of it. The mechanism is documented. The specific failures in this specific file are not measured.

So: I'm not a bookkeeper. I built this file out of a real practice's published rules, this is what came out, and those are the places it's untested. If you keep books — or run punch lists, or take intake — tell me what I missed. Which line would you delete first? That's the reason this is public.

Copy this prompt

Do the scroll-back yourself once. Then hand the rest over. Paste this into whichever assistant you use, in a fresh conversation, with nothing else attached:

I want to write a short rules file that you will read at the start of every
conversation, so I stop retyping the same instructions.

Interview me. Ask one question at a time and wait for my answer before asking
the next. Do not write the file until you have asked all of them.

Ask me:
1. What trade am I in, how big is the operation, and does jurisdiction or
   licensing matter?
2. What specific work will I hand you? Make me name actual deliverables, not
   "help with my business".
3. Who reads what you produce, and what do they already know?
4. What do I call things that an outsider would call something else?
5. What format do I keep correcting - dates, money, length, tables vs prose?
6. Is there an order of steps in my work that must not change, and what goes
   wrong if it does?
7. What must you never do, stated as something I could catch you doing?
8. When you do not know something, what exactly should you write, and who
   should I go ask?

Non-negotiable constraints on the file you produce:
- Plain Markdown. No YAML, no JSON, no table of contents.
- Under 50 lines of actual text. If my answers do not fill 50 lines, write
  fewer. Never pad.
- Every line must be something I could catch you violating. Delete any line
  that is a general principle like "be accurate" or "use good judgement".
- Do not invent rules for my trade. If one of my answers is vague, ask again
  rather than filling the gap yourself. If I say I do not know, leave it out
  and list it at the end under "still to decide".
- Do not include anything I only mentioned once in passing.

Output format: the finished file in a single Markdown code block, then a short
list underneath of what you left out and why.

The interview matters more than the output. Being asked "who reads this and what do they already know" out loud is what surfaces the rules you've been carrying without noticing. If it tries to skip ahead and write the file after three answers, tell it to keep asking.

Then read what it produces with a hard eye and delete anything you can't remember actually needing. What comes back will be longer than what you should keep. Deleting is easier than writing.

If you use something else, here's how to connect it

Three grades, honestly marked. ✅ reads it as-is. 🟡 works, but you do something first. ❌ this one doesn't have it.

Two rows are worth looking at properly.

The AGENTS.md-into-CLAUDE.md row is a mild embarrassment for a format donated to a neutral foundation, and it's been open as a feature request on Anthropic's tracker since August 2025. If you use the symlink, get the direction right — CLAUDE.md is the link, AGENTS.md is the real file. Honestly, just use the import line.

The last row matters most, and it isn't a workaround, it's a hole. Instructions have a shared file name a couple of dozen tools agree on. Memory has nothing of the kind — no common format, no export, no import that isn't "ask the other product to write you a paragraph and paste it across." Which is precisely why the rules of your business belong in the top row of this table and not the bottom. Your file opens in anything. It still works if you switch.

Verified 31 July 2026. Tool support moves, and the list on agents.md has a habit of growing.

Frequently asked questions

Why does my AI assistant forget what I told it last time?
Each conversation is assembled from scratch. It's handed a stack of text at the start and answers out of that stack; anything not in the stack didn't happen. Putting the sentences you keep retyping into a file that's added automatically is what closes the gap.

Isn't the memory feature supposed to solve this?
Partly, and only inside one company's account. Memory features live on the vendor's servers, aren't guaranteed to load on a given turn, and have no export you can hand to another product. OpenAI's own Codex documentation tells users to put rules that must always apply into AGENTS.md or a checked-in document rather than relying on memories.

What should go in the file, and what's a waste of space?
Four things: what you call things, the format you want back, the order that must not change, and the lines it can't cross. Skip general principles — there's no version of "be accurate" the model can check itself against. A line earns its place only if you've typed it twice.

Does it have to be called AGENTS.md?
No. It's plain Markdown — no required fields, no schema, no version number, per the official FAQ. Call it whatever you like. The reason to use that name is that 23 named tools pick it up with zero configuration.

How long should it be?
Short enough to read aloud in about two minutes. Every tool has a ceiling — 32 KiB by default in one, 6,000 characters in another, "target under 200 lines" in Claude Code's own docs — and past those points instructions are dropped or skimmed with no warning. The file above is 2,624 bytes across 68 lines.

Where this sits

This is the second piece in a series that ends with a folder you own and can hand to any assistant. The first was the difference between a chat window and something that actually finishes a job.

Right now your file says who you are. It doesn't yet say how your trade talks — the words, the formats, the things that are never said a particular way in your industry. That's next: writing your trade's way of speaking into the same file.

Want to go deeper? If you already work at a command line, the same idea gets a far more technical treatment in CLAUDE.md best practices — four principles reverse-engineered from real files, plus six templates. That one is written for developers. This one wasn't.

Receipts

What I did, what I didn't, and what I refused.

Verified myself on 31 July 2026, by opening the pages:

• The compatibility list on agents.md — 23 named tools. Claude Code is not among them.
• Claude Code's documentation, the AGENTS.md section, first sentence, word for word: "Claude Code reads CLAUDE.md, not AGENTS.md." Same page: "Size: target under 200 lines per CLAUDE.md file."
• The official FAQ on required fields: "No. AGENTS.md is just standard Markdown. Use any headings you like; the agent simply parses the text you provide."
• The site still shows the same "over 60k" figure published with the December 2025 donation announcement.

Measured on the file itself: 68 lines, 49 with text, 2,618 characters, 2,624 bytes — 8.0% of Codex's default 32 KiB budget, and inside the 6,000-character cap of the tightest limit in the table above.

Approaches I rejected, and why:

• Rules in the product's memory feature. Can't be read in full, so can't be audited — and the vendor that built one says in its own docs not to depend on it for rules that must always hold.
• Rules only in the project instructions box. Works, but lives in one company's interface. The same text in a file goes where you go, and you can diff it against last month's version.
• A .docx named instructions. Uploads fine to both big products; picked up by exactly none of the 23 tools that read a folder. The extension is doing real work.
• One long file covering rules, procedures and reference material. Where my draft went first. Split it back out before publishing — not because I measured it failing, but because the ceilings in the length table make a long file a bet you can't watch.
• "Always be accurate and use professional judgement" at the top. Felt important, checked nothing, cost two of the fifty lines. Cut.

Not tested, and named as such:

[NEEDS REAL RUN: the before/after turn count for the same job. Run one real month-end close without the file and three with it, logging the back-and-forth messages needed to get an acceptable output each time.]

[NEEDS REAL RUN: which version the file stabilised at. Keep every version with a date and a one-line note on what triggered the change, across at least three months of real use.]

[NEEDS REAL RUN: which specific lines were written down and then not followed. Line-by-line check of real outputs against the file, same job, at least three separate occasions — including the removal test on the lines that look decorative.]

[NEEDS REAL RUN: whether the same file behaves differently across products. Load it unchanged into a Claude project, a ChatGPT project and one folder-reading tool, run the identical job in all three, record where outputs diverge and how long each took to set up.]

I've also not put this in front of anyone who keeps books for a living, which is the gap I'd most like closed. Every rule traces to a published policy or statute; none have been through a real practice.

Stay in the loop (no account signup)

This site does not ask you to create a product account. Free readers just leave an email—or follow where the build is posted.

No paywall on this article. No "sign up for access." If you only want one next step: use the email box at the bottom of the site, or follow on X if you prefer the timeline.

— hh, AI Workflow Pro