DeepSeek released its agent harness this week and the commentary went where commentary goes: everything is a plugin, registrations return their own undo, dependencies react when a provider disappears, the session log is the only thing the model ever sees. I read the repository and the Cordis paper behind it, and that runtime is interesting. It is also a developer preview that warns you in capital letters that it will break, so the honest verdict on the framework is “borrow the review questions, not the code.”
The half I think people are skipping is the other one. Roughly two and a half thousand pull requests in that repository were written by agents, and the maintainers had to answer a question most of us are still improvising: how do you keep a codebase honest when the thing writing it has no memory of yesterday and no shame about narrating? Their answer sits in a root instruction file, a tree of decision records, a documentation standard, and eleven small skills, and it is more transferable than the harness because none of it depends on the plugin system: it is about how agents write into a repository, whatever they run on.
Three of their rules are worth stealing outright.
The first is that absence has to be declared. Every package must publish an invariant companion, and a package with nothing checkable must export an empty one whose first comment starts with “No runtime invariant:” and explains, for that package specifically, why nothing is checkable. A gate rejects unexplained empties. Checks may assert only against authoritative event streams or mutable data, never against whether a method exists or a plugin loaded. I have written a whole post about checks that pass on the proxy instead of the object; this is that lesson turned from a thing you remember into a thing you cannot forget to write down. The silence of a missing check becomes a reviewed fact instead of a green light.
The second is that standing orders carry no history. Their documentation standard bans “previously”, “now” and “no longer” from any current-state surface, along with pull-request numbers and commit hashes, and routes change stories to decision records or postmortems. Their pre-release section opens with the instruction to delete it at the first tagged release, so a rule that will expire names its own trigger. There is a skill for trimming what they call chain-of-thought leakage from prose, and it reduces to a single test: could a reader at the current commit, with no session transcript, resolve every reference and verify every claim? If not, the passage is a diary entry wearing a rule’s clothes.
The third is that a decision records what it beat. Design notes live in folders named for their lifecycle, a gate cross-checks the status line against the folder, implemented notes may not contain the word “should”, and every note must carry an alternatives-considered section, on the stated ground that a decision recorded without what it beat invites re-litigation. Anyone who has watched an agent cheerfully re-open a settled question, or watched themselves do it, knows exactly which failure that section exists to prevent.
Here is why I am confident these transfer. On the afternoon I read the repository, I ran the second rule against my own setup. The instruction file my coding sessions load first contained a paragraph explaining that a particular constitution document was never injected into the session, so three of its rules were restated locally on purpose, and it even warned that a tidy-up which deleted the duplicates would delete the safety gates. It was a good paragraph. It was also six days out of date: the injection had been fixed upstream, and nothing in the paragraph named a live check that would have noticed. The rule it warned about had happened to the rule itself. I rewrote it to state the mechanism that now exists and the one condition under which the duplicates can go, and moved the story to a postmortem note where stories belong.
I do not think DeepSeek invented any of this. Architecture decision records are old, and every serious team has some version of “docs describe the present.” What is new is seeing the whole set applied to a repository where agents do most of the writing, and seeing it enforced by scripts rather than by asking nicely. An agent will not remember a convention. It will run a gate. If you maintain anything with agents, the useful thing to read this week is not the plugin system. It is the file that tells the agents how to behave, and the scripts that check whether they did.