Operon

Every team has one person who's much better at AI than everyone else. They've worked out how to get a good PR review or a clean migration out of an agent, and that know-how sits on their laptop or gets sent around in DMs and lost. When they leave, it leaves with them.

Operon read the Claude Code, Codex and Cursor sessions on your laptop and found the work you kept repeating. Then it turned that work into a versioned agent a teammate could install with one command.

The hard part is that nobody repeats themselves word for word. One person types "check the diff on this branch before i merge it". Another types "can you look at my PR?". Operon had to work out that those were the same job.

Turning habits into agents

We thought the next unit of reuse in engineering would be an agent, the way it used to be a library. The name comes from biology, where an operon is a group of genes that a cell reads together as one unit. "Review this PR" is like that: read the diff, flag the risky changes, check the tests, post one comment.

The product was three verbs. Mine read your sessions on your own laptop and found the work that kept coming back. Polish had Claude turn one of those into a clean SKILL.md. Share published it to the team. It ran inside Claude Code and Codex, so there was no new tool to learn.

Spotting the same job

Here are five made-up PR reviews from one fake repo, acme-web, each worded differently and asked on a different day.¹ A search for repeated text sees five different requests.

So the miner mostly ignored the words and looked at what the agent did. All five ran git diff and git log, read the same three files, ran one search and ran the tests. Not one of them edited a file.

We called that shape the action signature. It's a hash of four things: the tool the agent used most, its top three tools, the first kind of file it edited, and the folder it ran in. Reading a file doesn't count as touching it, so a review's file slot is empty. All five reviews get the same hash, and the words never enter it.

The miner could still name a habit from the words, but only when the ask opened with a verb from a fixed list like migrate, deploy, fix or review. Without the list, "running into an error" became a habit called running-into. (That's in a comment in the source.)

Grouping in five passes

I ran the public CLI on twenty made-up sessions. A filter first dropped the noise, like a 40-second typo fix. The error triages all started with /triage-errors, the schema migrations all opened with "migrate the schema", and the five reviews fell to the action signature.

The fuzzy pass measured how far apart two sessions were, and almost all of that distance came from what the agent did. The words counted for very little.² Take two dependency upgrades: "bump the dependencies and fix whatever breaks" and "upgrade the deps to the latest minors". They used the same tools and edited the same package.json, but one read an extra file, so their signatures came out different.

Everything else matched, so they were still close enough, and the upgrades became one group, upgrade-deps. To stay out of a group, a session had to do something different.

Ranking what's worth sharing

Each group got a score from how often it came up, how many separate days it came back, and how many different tools it used. Tool use counted the most.³

So review-diff came back the most, on five separate days, and still ranked last. A review reads and never edits, so it uses fewer tools.

That was on purpose, and we raised the tool weight to get there. The comment on it says a high-frequency conversation, "dozens of Cursor chat turns with no real tools", "should not outrank a genuine multi-tool workflow that recurs less often." An ask that makes the agent read, search, edit and run tests is worth sharing. A question isn't an agent.

Keeping sessions private

Every message was redacted before any of this ran. Known key formats and email addresses went first, then any long run of mixed characters that looked like a secret. Raw sessions never left the laptop. Polish ran only when you asked, on your own Anthropic key, and each draft came with an eval that replayed three of its sessions.

Sharing agents like code

Once published, an operon had a version and a changelog, and a team could pin one or roll it back. Forks worked like forks of code. The platform team owned review-pr. Product forked it to add its web-app conventions, infra forked it to add Terraform checks, and both forks stayed in sync with the base.

Every run was logged, and the ledger added them up per agent, down to the one nobody had run in 90 days.

Agents could use Operon too. The hosted MCP server let an agent read the team's catalog, load a skill mid-task and log its own run into the same ledger.

The work people asked for most wasn't the work worth sharing. The work that made the agent change something was.