Write for the Model That Doesn't Exist Yet

Here is a line from the billing guide of a hypothetical software company that sells subscriptions to small businesses:

Do not email customers about overdue invoices on weekends.

Everyone in billing knows where it came from. Two years ago, automated reminders went out on Saturdays. Most customers are owners of small shops whose bookkeeper works weekdays. The reminders reached owners at home, couldn't be acted on until Monday, and produced a wave of complaints and a few cancellations. The point of the rule is to avoid pressuring people at a moment when they can't do anything about it.

Nobody wrote that down, because everyone in the room already knew it.

Now an AI agent handles billing messages, with the guide in front of it. A growing share of what every organization writes down is read this way, by support agents, coding assistants and reply drafters, and the model doing that reading next year will be better than this year's.

So the old chore of documentation has become a new question. What should you write, and how carefully, when your main reader is a model that keeps improving? My answer has three parts. Write down why things are the way they are, now, clearly and imperfectly. Keep the facts that expire apart from the facts that last. And don't spend months polishing formats for today's model, because the next one will read your rough draft better than this one reads your polish.

Two Saturdays

On the first Saturday, a customer whose card was declined wrote late on Friday. Their account is suspended, they have an event that evening, and they asked to be told the moment the new card goes through. On Saturday morning it does. Should the agent send the confirmation?

On the second Saturday, the company has just connected a text-message tool to the agent. A batch of invoices reaches 30 days overdue, and the agent's standing task is to send a reminder at 30 days.

With only the rule to go on, a reader that takes the text at its word can fail both days, in opposite directions. On the first, the rule applies too widely: the confirmation concerns an overdue invoice, it would go by email, and it's Saturday, so a careful literal reader holds it until Monday, and the customer spends the day of their event not knowing whether their account works. On the second, the rule applies too narrowly: it names email, a text message is not an email, and nothing else forbids it. The reminders go out by text on Saturday and land on owners' phones at home, which is worse than the emails the rule was written to stop.

A strong model may well guess right on either day. The trouble is that nothing in the text tells it which way to guess, and both wrong outcomes come from reading the text faithfully. Vendors now describe this plainly. Anthropic's prompting guidance for one of its recent models says the model reads prompts literally, particularly at lower effort settings, doesn't carry an instruction from one item over to another, and doesn't infer requests nobody made. That suits predictable systems, and leaves a rule's unwritten scope unwritten.

Now add one sentence:

Do not email customers about overdue invoices on weekends. Why: most customers are small businesses whose bookkeeper works weekdays; weekend reminders reach owners at home when they can't act, and in 2024 they caused complaints and cancellations. The aim is to avoid pressuring people when they can't do anything about it.

Both Saturdays now have an answer the letter couldn't give. The customer asked for the confirmation and can act on it, so holding it serves no one: send it. A text to an owner's phone on a weekend is exactly the pressure the rule exists to prevent: queue it for Monday.

Scroll sideways to see the whole figure

A rule tells the model what to do in the cases its authors pictured. The reason tells it what to do in the others.

The reason makes the right call available without making it certain, and it invites interpretation, which is sometimes the last thing you want. Anthropic's constitution for its models, published in January 2026, puts the trade-off well: clear rules are predictable, judgment adapts to situations nobody anticipated, and rules earn their place where errors are costly. Even for the rules it keeps, the document explains its reasoning. Its prompting guide shows the same thing at small scale. A bare "never use ellipses" works less well than explaining that a text-to-speech engine will read the output aloud and can't pronounce them, because the model generalizes from the explanation.

Why people cope and models don't

Organizations have always run on rules without written reasons, and people survive them because the reason travels some other way. A new hire in billing hears the weekend story at lunch in their first week. When the text-message tool arrives, someone at the next desk says the rule obviously covers it.

A model has no lunch.

Everything it knows about your organization arrives at the moment of the task. It brings broad general knowledge from training: how invoices work, what a refund is. It knows nothing specific about you unless someone puts it in front of it. The instructions, retrieved documents, tool results and conversation it can see are called its context, and the software around the model, the harness, decides what goes in. If a fact, a reason or an exception is missing from the context, then for that run it doesn't exist.

A model can ask a clarifying question, but only when it notices a gap, and a terse rule looks complete. Scale makes it worse. A person misreads a rule once and gets corrected; an agent applies the same misreading across thousands of runs until someone spots the pattern.

The authors of a rule are the worst judges of whether it needs a reason, because they know the reason and can't see its absence. The simplest test is to picture a capable newcomer who wasn't in the room. Could they make the exception the authors would have made? If not, the reason is missing, whether the newcomer is a person or a model.

Don't polish for today's reader

This is where careful teams go wrong, and they deserve a fair hearing. Today's models do stumble on long, disorganized files. Tokens cost money. Vendors publish detailed advice on headers, tags and examples because those help current models. A quarter spent retuning the wiki for this year's model may well pay off this year.

The problem is what that tuning encodes. Much of it compensates for the weaknesses of one model generation, and those weaknesses change. Anthropic's prompting documentation now carries separate notes per model, listing instructions to add for one and scaffolding to remove for another (What Training Actually Changes explains why such patches expire).

Underneath is an asymmetry, and it decides where to spend effort. A future model can take a clear but messy body of documents and reorganize it into whatever form it reads best, quickly and without your help. No model can recover a reason that nobody wrote down.

A future model can reformat what you wrote. It cannot recover what you never wrote.

So the expensive care belongs in the part that can't be regenerated: the intent, the exceptions, the conditions. Rough effort is fine for the rest. Rough in form, that is. Clarity about why is the one part that shouldn't be rough.

The opposite mistake is writing nothing, on the theory that future systems will infer the reasons from chat logs and email. Many reasons were said aloud and never typed anywhere, though, and an inferred reason is a guess with no authority behind it.

A fair worry is that writing reasons makes documents longer, and models use long inputs less well than their size limits suggest (What Fits Versus What Gets Used). Public conventions such as Agent Skills answer with layering: each document carries a short description of what it is and when it matters, the model reads the descriptions first, and it opens the full text only when the task calls for it. That makes the description the most-read sentence in the system, so write it in the words someone would use when they need the document.

Facts that last and facts that expire

Facts in a document expire at different rates, and a document stays trustworthy only as long as its most perishable sentence.

Perishable facts change on a schedule someone else controls: prices, names of people, vendors and tools, thresholds tuned this quarter, links, the model currently in use. Durable facts change only when the organization changes its mind: what a process is for, whom it serves, what must never happen, and the reasons behind its decisions.

Mixing them is how good documents die. Suppose the billing guide says the Pro plan costs €49 a month, and in March the price changes. The guide is now wrong, and a model can't tell which sentence went stale, because everything in its context carries the same apparent authority unless it's dated. So the agent quotes €49 to a customer. The second-order effect is worse. Once readers learn that one line is out of date, they stop trusting the whole document, and the durable parts, the purpose and the weekend rule with its reason, get abandoned along with the stale price.

Writing a perishable fact into a durable section gives it an expiry date.

The fix is to give each perishable fact one home and one owner, and to have durable text point to it. The pricing table owned by finance holds the price; the billing guide says the Pro plan is the entry plan for teams and that its current price lives in the pricing table. The harness fetches the live value when a task needs it. When a perishable fact must appear in running text, date it.

The model you use is the clearest case. "Triage uses Model X because it is cheapest" mixes a requirement with a choice. Split them: triage needs an answer in under two seconds at a low cost per ticket, and the current model that meets this lives in the configuration. When the next model arrives, the requirement stays put and the choice gets revisited against it.

Scroll sideways to see the whole figure

A reason with a condition for revisiting it

Software teams already have a format built for carrying reasons: the decision record, proposed by Michael Nygard in 2011. A page or two gives the context, the decision, its status and its consequences; a reversed decision is marked superseded, not deleted.

Two additions earn their place when the reader may be a model. The first is the alternatives that were rejected and why, because a capable reader will propose the obvious alternative again. The second is a revisit condition: the observation that would make the decision wrong. It turns a reason into something a reader can check.

Decision 14: No overdue-invoice messages on weekends

Status: accepted, 2024-05
Context: Most customers are small businesses; their bookkeepers work
  weekdays. Saturday reminders in Q1 2024 reached owners at home,
  could not be acted on until Monday, and preceded complaints and
  cancellations.
Decision: We will hold overdue-invoice reminders sent on Saturday or
  Sunday until Monday morning, in any channel.
Alternatives: Weekend reminders with softer wording (rejected: the
  problem is timing, not tone).
Exceptions: Messages the customer asked for, such as payment
  confirmations, go out immediately.
Revisit if: most new customers are consumers rather than businesses,
  or weekend payments start settling the same day.

A future model reading this can check whether either condition now holds, then keep the rule or argue for removing it, with evidence. It's G. K. Chesterton's old advice, don't take down a fence until you know why it was put up, applied to documents. The record is the note nailed to the fence, and the revisit condition says when it's safe to take it down.

What not to write

Some things don't belong in a document for a model, because a document can't guarantee them. A sentence in a prompt is a wish unless something enforces it.

"Never charge a card twice for the same invoice" matters too much to live as a sentence. It belongs in the payment code, where a check makes the second charge impossible whatever the model reads. "Never delete production data" in an instruction file is weaker than an agent whose credentials don't include delete rights. Other text in an agent's context, including text written by attackers, can argue with any instruction, so authority shouldn't depend on what the agent reads (Same Model, Different Results calls these enforced limits walls).

What does belong in the document is the reason the wall exists and where it lives. A model that knows why refunds require a human, and that the permission system enforces it, won't try to route around it and will understand the error when it hits it.

Start this week

None of this needs a documentation project. Pick one document that agents and new hires actually read.

Give it a two-line header: what it is, when to read it, what it doesn't cover. Find the rules people most often ask about or get wrong, and add a "Why" line to each, plus a "Revisit if" line when you can name one. Replace every price, name and vendor with a pointer to the place that owns it, or date it. Mark the sentences that are really walls, and check whether anything enforces them. If nothing does, that's a ticket for engineering rather than a sentence for the document.

Then test it the way the two Saturdays tested the billing guide. Give the document to a model with two edge cases, one where the rule shouldn't apply and one where it should apply beyond its letter, and see what it does. Ask the person who wrote the rule what they would have done. Where the answers differ, the document is missing a reason.

The habit that keeps it going is capture. When someone explains a reason in a meeting or a chat thread, paste it next to the rule the same day. That's the smallest version of the step that lets work compound instead of being relearned (When Work Starts to Compound).

There's a bonus most teams notice only later: the same material onboards people and models. The reasons that let an agent handle the second Saturday are the ones a new hire asks about in their first month. And if the formats change again, the next model can convert the text. The format is perishable. The reasons are the durable asset.

The reader that will matter most in a few years can't sit in your meetings. Everything it will know about why your organization works the way it does is what you managed to write down.

Check yourself

Why can a model fail on a bare rule even when it is a strong model?

It reads the text literally and has no other way to learn the rule's unwritten scope. Nothing in the text tells it which way to guess, so it can apply the rule too widely or too narrowly.

Why should a price not sit inside a durable section of a guide?

A perishable fact gives the whole document an expiry date. Once readers find one stale line, they stop trusting the durable parts too.

Why spend care on reasons but not on polishing format?

A future model can reorganize a clear but messy document into whatever form it reads best. No model can recover a reason that nobody wrote down.