What Your AI Is Allowed to Write Down

The short version: context engineering is a well-developed theory of what goes into a model's context window. What comes out of a session and becomes permanent is treated as a storage tactic rather than a decision with an owner. Serious work on the write side has started to appear in the last few months, and one platform vendor has shipped real machinery for it, but there is no discipline, no vocabulary, and no default. Meanwhile the regulatory forcing function everyone points at just moved sixteen months and would not cover a personal AI tool anyway. So the case for getting this right has to stand on engineering grounds, not compliance ones. This is my attempt at that case.

Context engineering treats writes as tactics, not decisions

The canonical definition comes from Anthropic's engineering blog, September 2025: context engineering is "the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference, including all the other information that may land there outside of the prompts." The governing principle they give is finding "the smallest possible set of high-signal tokens that maximize the likelihood of your desired outcome."

That is a good definition. Read it again and notice the frame: every word of it is about assembly. What to include. What to leave out. How to compact. What a sub-agent should hand back. Most of it describes decisions made before an inference that expire when it ends. Where it does reach past the session, it reaches as storage, not as authority.

Now ask the question the definition does not answer: when that session produces something worth keeping, who decides what gets kept, and what is the record of that decision?

The techniques the post names are instructive here. Compaction. Structured note-taking, with the example of an agent maintaining a NOTES.md. Sub-agent architectures returning compressed summaries. Every one of those is a write. An agent deciding what to preserve about its own work is the most consequential thing in the loop, and it appears in the literature as a context-management tactic rather than as a decision that needs an owner.

I don't think that's an oversight so much as an inheritance. Context engineering grew out of prompt engineering, and prompt engineering was about a single turn. The vocabulary never had to grow a concept of permanence.

A bad write is not like a bad answer

Here is why the asymmetry matters more than it sounds.

A wrong answer is bounded. You see it, you correct it, the conversation moves on. The cost is one exchange.

A wrong write is unbounded in time. It becomes a premise. Every future session inherits it, reasons from it, and produces output shaped by it, in conversations you aren't watching, until something eventually makes it visible. And the thing that makes it visible is usually an error that is expensive enough to trace.

I hit this myself in a small and clarifying way. A frontier assistant I use daily had confidently stored that my company had filed four provisional patent applications. The real number was seven. That memory had been stale for months. It never announced itself, it never expired, and there was nowhere I could have gone to catch it before it said the number out loud. It was written once and then treated as true forever.

That is a trivial example with a trivial cost. Now put the same mechanism inside an agent with tools, running unattended, in a workflow with money or customers on the other end of it. The failure mode does not change. Only the invoice does.

The read side has a name for its version of this problem — context rot, the degradation of recall as the window fills — and a body of measurement behind it. The write side has no settled name and no measurement anyone builds against. What it has is a growing pile of durable state that nobody agreed to.

The write side started moving in 2026, from three unrelated directions

I want to be careful here, because "nobody is thinking about this" is the kind of claim that is almost always wrong and always embarrassing. People are thinking about it. What hasn't happened is consolidation into a discipline, the way the read side settled around context engineering over two quarters of 2025.

Three things moved, independently, within four months.

Date	Who	What moved
23 Apr 2026	Anthropic	Memory for managed agents shipped file-based, exportable, and permission-scoped, with a per-write audit log recording which agent and session each memory came from
28 Jul 2026	MCP spec revision	Removed protocol-level sessions. Servers needing state across calls now mint explicit handles passed as ordinary tool arguments. The motivation was statelessness; the effect is that invisible state becomes a value the client holds
Jun–Jul 2026	Academic work	Memory-governance papers began appearing under their own names, including GovMem and GateMem

Three motivations, one direction: make the durable thing explicit, attributable, and refusable.

What's missing isn't the ideas. It's that if you're building this today, you have a mature vocabulary for assembling a context window and essentially none for governing a write, so you default to whatever the extraction library does.

The deadline everyone is citing already moved

There is a version of this argument that leans on regulation, and I'm not going to make it, because the regulation moved and most of the internet hasn't noticed.

Article 14 of the EU AI Act carries the human-oversight duties, and it is the clause every agent-governance post has been quoting. Those obligations were deferred to 2 December 2027 by the AI Omnibus amendment, Regulation (EU) 2026/1744, which entered into force on 27 July 2026. Systems integrated into regulated products move to 2 August 2028. What applied on 2 August 2026 was Article 50 transparency, and not all of it. Article 50(1), the duty to tell a person they are dealing with an AI system, took effect on the date. The same omnibus gave Article 50(2), the machine-readable marking of AI-generated content, until 2 December 2026 for systems already on the market. Either way it is a labeling duty, not a supervision duty.

I wrote up the full corrected timeline separately, because the errors circulating about it are worse than a single wrong date.

Two things follow. The smaller one is a sourcing warning: a very widely cited unofficial AI Act reference site still shows the old 2 August 2026 date, and its implementation timeline carries a last-updated stamp of 1 August 2024. If you are quoting dates from it, you are quoting law that has since been amended.

The larger one is the point of this section. Even in December 2027, Article 14 attaches to high-risk systems as defined in the Act. A personal AI memory layer is not one of them. Nothing in the current or amended regulation will require any of what I'm about to argue for.

So it has to be worth doing anyway. If your case for provenance rests on a compliance date, you built it on something a legislature moved by sixteen months with six days to spare.

What a write-side discipline would actually require

If the read-side question is which tokens earn their place in this inference, the write-side question is:

What is the smallest set of durable claims this session has actually earned, and what evidence stands behind each one?

Four properties fall out of taking that seriously.

Attribution. Every stored claim should know where it came from: which session, which agent, whether a human touched it. Anthropic's per-write audit log is the shape of this, and it is worth saying plainly that they shipped it before most of us were arguing for it. Most systems have no equivalent, which means every stored fact arrives with the same authority whether it came from a signed document or an offhand aside.

Standing. Not every observation deserves to be permanent. A pattern seen once is a coincidence. Seen fifteen times across independent contexts and confirmed by outcomes, it is something else. The distinction should be a property of the record, visible to the user, not a hidden confidence score. We treat these as separate states in our own system, and I would argue for that shape whether or not you ever use it: a candidate is not a belief, and a belief that has been contradicted should say so rather than quietly losing an argument with a newer record.

Revocability. A stored belief a person cannot see, argue with, or delete is a liability dressed as a feature. This is the reason the "just use a markdown file" argument keeps winning debates it should lose on capability. A text file is legible and greppable, and legibility beats sophistication when the thing being stored is a claim about you. Anything less inspectable than a text file has to earn the difference.

Supersession over accumulation. When a new fact contradicts an old one, the system needs a position. Most take the newest. Some take the highest-scoring. Both are wrong often enough to matter. The honest behavior is to mark the conflict, keep the history, and surface it, because a contradiction between two things you said is information about you, not noise to be resolved silently.

The objection I take seriously

The strongest counter is that all of this is scaffolding, and scaffolding loses.

The argument runs: context windows keep growing and getting cheaper, models keep getting better at using them, so elaborate curation machinery is a temporary workaround that will look silly in three years. It is a real argument with real evidence behind it, and anyone building in this space who has not sat with it is not paying attention.

But notice that it is a read-side argument. "Just put everything in the window" is a claim about assembly. It says nothing about who decided that a thing belonged in the durable set in the first place, or whether it was true, or whether the person it describes agreed with it. A larger window makes retrieval less clever. It does not make provenance less necessary. If anything it makes it more so, because the cost of a bad stored claim scales with how much of it the model is willing to read.

Cheap context is an argument against retrieval engineering. It is not an argument against knowing where your facts came from.

There's a second objection, and it's the one I get from people who have actually run data infrastructure: this is provenance and lineage with a new label. Databases have had authorship columns, versioning, soft deletes, and conflict resolution for thirty years.

That's fair as far as it goes, and it stops at the part that matters. In a database, a human wrote the row and a schema constrained what the row was allowed to say. Here the system decides on its own what to write, in prose, with no schema, about a person who was never asked, and then reads its own writes back as premises. The properties are old. What's new is that the writer and the reader are the same process, and nobody specified the write.

Where I actually land

I'm not arguing that every memory write needs a human clicking approve. That would be unusable, and the evidence on human oversight is not kind to the reflex that more supervision is always better.

I'm arguing something narrower. A system that writes durable claims about a person should be able to answer four questions about any one of them: where it came from, how much evidence it has, whether anything contradicts it, and how to kill it.

That is not a governance product. It is a design floor. Most systems holding durable beliefs about their users cannot answer any of the four. Not because the problem is hard, but because nobody has had to name it yet, so the default is whatever the extraction library happened to do.

Context engineering gave the industry a real discipline for the half of the problem that ends when the request does. The other half is still running.