Who Writes Your Agent's Rules? I Counted the Commits.

There's a set of files in my repository that tells every agent how to work on this site. What to write, what never to write, when to ask, when to post. I didn't write all of them. I can now tell you roughly how much I didn't write, and exactly where my records stop.

The short version

Tanner Kohler at Nielsen Norman Group published a study of expert Claude users and their context libraries. Almost nobody typed into their own context files. They asked Claude to make the change, rarely checked what it changed, and judged the edit by later outputs. One found a file governing what Claude was allowed to do that he hadn't known existed, and none used version control. Kohler's advice is to let the agent maintain the library. I do, and mine is in git, so I counted. Eleven files, 2,322 lines, 51 commits since March 30. At least 21 of those commits carry an agent co-author line, and I can't attribute the other 30. Twenty-three lines carry my name and a date. Agent-maintained is fine. Unread is the problem. Put the library in version control, stamp every rule a person said, read the diff of the global files weekly, and count the files nobody has opened.

What NN/g saw

The article is "Context Libraries: How AI Power Users Manage Context Engineering," published October 9. Kohler's participants were experts who work with Claude daily and had built extensive libraries. A context library, in his definition, is the institutional and procedural knowledge an agent can reference and edit, mostly markdown files, extended by connections to things like Notion and meeting transcripts.

They spent more effort on context than on prompts, most of which they dictated casually.

And they didn't write the context themselves. Almost nobody typed directly into their files, even with the file open. Asking Claude was faster and kept the style consistent. They'd ask for sweeping changes across many files at once, and, in Kohler's words, they "rarely checked what Claude had changed." They judged the work by the outputs that followed. If the outputs stayed poor, they asked for another round.

Then the detail that should bother anyone running agents at work. Participants would describe an important manifesto or boundaries document, go looking for it, and come up empty. One discovered a piece of global context governing much of what Claude was and wasn't allowed to do. He hadn't known it existed. Kohler's guess is that Claude had created it on its own, or the participant had forgotten.

A few had considered GitHub for version control. None had adopted it. One kept over 2,700 context files.

Kohler closes with three practices: let the agent maintain the library, organize it around index-card files, and load only what each task needs.

Where I'd stop short

I'm fine with the first practice. I do it. Basia Kubicka teaches the same thing in her workshops, down to the line "make it self-update so you don't have to maintain it," and her Harvard Business School attendees each left with an email skill that updates itself when their priorities change. It's a good pattern.

What I wouldn't accept is the grading method. Judging a rule change by whether later outputs look better is the easy check.

I've made that mistake with a different agent. In Every Check Was Green. Four Sources Were Dead. my monitor reported 43 of 45 feeds healthy. Four of the healthy ones had been silent for 72, 356, roughly 550, and 612 days. Every one returned a valid response. The check asked whether the feed parsed. It didn't ask whether the feed had said anything lately. The output of a quietly failing agent looks exactly like the output of a working one.

A context edit works the same way. A wrong rule produces plausible output until the day it meets the case it was wrong about. And a permissions file nobody knew about has been producing plausible output the whole time.

So I counted mine

My library is one CLAUDE.md and ten skill and agent files. 2,322 lines. CLAUDE.md alone is 652, which is well past the few hundred lines Kohler's participants kept to. By their standard it's too long, and they're probably right.

It's in git, which none of his participants had. So these are counts, taken on October 10 with git log and grep.

The 21 is a floor. An agent made those commits and said so in the trailer. The other 30 are a mix. Some I typed. Some an agent typed and the co-author line wasn't added. I can't split them, and it took running the count to see that.

The 23 is the number I trust most. Those are rules that read like "(Falk, 2026-09-28)" followed by what I said. When a rule has that stamp, a person stated it and a date says when. When it doesn't, the rule might be mine, or it might be an agent's reasonable inference that I've never read.

I wrote about a single definition file with an owner in A Name on the Definition, and the Reject Pile. This is the same question at the size of the whole library: of everything my agents are told, what share did a person say?

Field notes

Four things, in the order I'd do them.

Put the library in version control today. The participants who shared a library with collaborators backed it up to Google Drive. A backup tells you what the files say now. It doesn't tell you what changed last Tuesday or who changed it.

Stamp what a person said. Have the agent add who and when to any rule that came from a human instruction. Then a missing stamp means something.

Read the diff of the global files once a week. Not the outputs. Kohler separates global context, which shapes everything, from local context scoped to a project. The global files are few. Reading a week of changes to them takes minutes.

Count the files no person has opened. One of his participants found one by accident, in front of a researcher. Better to find yours on purpose.

And one for my own setup: every agent commit to those files should carry the co-author line, so the next count has no unattributed row.

This is the kind of thing the Enterprise AI Agents argument keeps running into. What matters is whether agents still do production work at ninety days, and an agent at day ninety is running on rules that have been edited a few dozen times. I argued in Context Is King. Written Context Is Rented. that the valuable context is the graded record of what happened. A commit history on the rules is the smallest version of that record. Start it.

Related answer: Who should maintain an AI agent's context files?

Sources: Tanner Kohler, "Context Libraries: How AI Power Users Manage Context Engineering," Nielsen Norman Group, October 9, 2026. Basia Kubicka, LinkedIn post on her Harvard Business School session, October 7, 2026. The repository counts are from git log and grep over this site's CLAUDE.md and .claude directory on October 10, 2026.