TL;DR
I ran an audit over my repos going back to March: pull the first commit that introduced each agentic pattern, then go find out when that pattern actually became common practice in the wider ecosystem. The results were humbling in a useful way. Four things I quietly considered myself early on were catch-up, in one case by two years. Four other things turned out to be genuinely ahead of documented practice. The interesting part is what those four have in common, and it is not what I expected.
Why bother
I have been running Claude hard across about forty repos since February, and somewhere in there I picked up an assumption that I was operating ahead of the curve. That assumption was never tested. It was vibes, assembled from reading release notes and noticing that things I had built showed up in somebody’s blog post later.
That is a bad way to know anything, and it has a real cost. If you think you are ahead, you stop reading. You reinvent solved problems badly instead of adopting the version that already has documentation and a test suite. I have absolutely done this.
So: actual dates, actual evidence, both sides.
The method was two passes. First, subagents over git history in each repo pulling first-appearance dates with git log --diff-filter=A, which gives you the commit that introduced a file rather than the last one to touch it. Second, a separate research pass on when each pattern went mainstream, looking for spec releases, product launches, and widely-read guidance rather than my own impressions.
Then compare the columns. It goes badly at first.
Where I was late
These four all felt like invention at the time. They were not.
Deterministic guardrails before model judgment. I added a pre-tool hook in mid-May that blocks destructive commands with a regex list: rm -rf, terraform destroy, DROP TABLE, kubectl delete namespace, force pushes. The idea is that you never rely on a prompt instruction for something you can enforce mechanically, because prompt compliance is probabilistic and a regex is not.
I was pleased with myself. This has been standard guidance since roughly 2023. Llama Guard, NeMo Guardrails, and a pile of enterprise best-practice writeups all landed well before I got there. “Deterministic rules first, model judgment second” was settled advice while I was still hand-approving kubectl commands. Late by about two years.
MCP servers with writes gated off by default. I built an MCP server over a live production database in May and put writes behind an explicit environment flag, defaulting to read-only. Sensible. Also already in the spec: MCP shipped in November 2024, tool annotations including a read-only hint landed in the March 2025 spec revision, and the authorization framework followed in June 2025. I arrived roughly a year after the pattern was formalized by the people who designed the protocol. I wrote about building these servers as though the gating were my idea. It was in the docs.
Specialist subagent roles. Architect, builder, auditor, tester, debugger, each with restricted tools and a pinned model. I set these up in late April. The vocabulary for role-specialized agents had been stabilizing through 2024 and 2025 across several vendor architecture guides. I was on time at best, and the honest read is slightly behind.
Session observability and goal drift. I wired Langfuse tracing into my sessions at the end of May, including a weekly job that compares stated objective against actual commits. Agent observability was identified as the critical production bottleneck across 2024 and 2025, and Langfuse itself went from a few hundred enterprise customers in early 2025 to thousands by early 2026. I joined a crowd and thought I was scouting.
Four for four on things I felt clever about. That is the part worth publishing, because retrospectives that only list wins are marketing.
Where I was actually ahead
Same method, other direction. These four turned up little or no documented mainstream practice, even now.
Routing finished code to a rival vendor’s model as a merge gate. Adversarial testing of models is mature, but it happens inside vendors. Google attacks Gemini, Anthropic attacks Claude. What I could not find documented anywhere is the practice of handing your working, already-reviewed code to a competitor’s model and asking it to attack the reasoning before you merge. I have been doing this since April, and over four days it killed a performance optimization, found two engine bugs that inflated every number in my results table, and identified five ways my evaluator was reading the future. Full writeup here. This is the one I would actually recommend to somebody else.
A self-editing context file with a scope fence. I have a night job that updates my repo’s CLAUDE.md based on what the agents learned that day, so the instructions improve without me maintaining them. Self-modifying agent context is still research-stage in the literature, and the reason it has not shipped widely is auditability: nobody wants a process that can rewrite its own instructions unsupervised.
The fence is the answer to that objection, and it is four lines of CI. The evolve job fails hard if its diff touches any file other than CLAUDE.md. The agent can rewrite its own rules and cannot touch anything else, so the blast radius of a bad self-edit is one file I can git revert. I shipped the feature in early May and the fence about a month later, which is the correct order only in the sense that I got away with it.
A deterministic clamp on an agent’s spending. I run an agent that evaluates surplus auction lots and places bids with real money. The model produces a recommendation. The model does not produce the final number. A deterministic layer clamps it, the whole recommender is off by default, and there is a hard floor requiring at least three realized comparable sales before it can bid above a threshold.
Agentic commerce got real in late 2025, with checkout and payment protocols landing from several directions in a few months. Those specs cover consent gates and per-user spending limits, which are about authorizing the agent. What I could not find is a standard for constraining the number the model itself produces. Everyone rolls their own. Mine is stricter than most, because the failure I am defending against is not a compromised agent, it is a confident one.
Splitting memory into always-loaded rules and a retrievable index. My persistent memory is 145 files. Loading all of it every session would be absurd, so there is an index file that carries one line per memory with a short hook, and the detail lives in the topic file that the index points at. The index is always in context. The topic files are fetched only when something in the hook looks relevant.
Agent memory architecture is an active research area with no consensus. Half a dozen competing systems, no RFC, no vendor guidance on where to draw the always-loaded line. I arrived at the split empirically, by watching my context budget get eaten, which is a less impressive origin story than a paper but it does work. I have written before about the memory system without ever noticing that the boring index-versus-detail decision was the load-bearing part.
The thing they have in common
I did not see this until I had both lists side by side.
Everything I was late on is a capability. Guardrails, MCP servers, specialist agents, tracing. Things that let the system do more. And capabilities are exactly what the ecosystem is good at producing quickly, because they are what vendors ship, what gets a launch post, and what everyone reads about. Trying to be early on a capability means racing several thousand well-funded people who are also racing. You will lose, and losing is fine, because the version they ship will be better than yours and will come with docs.
Everything I was ahead on is a constraint. A gate that blocks a merge. A fence that fails a job. A clamp on a number. A rule about what does not get loaded. None of those make the system more capable. All of them make it narrower in a specific, deliberate place.
That asymmetry makes sense once you see it. Constraints are unglamorous and intensely situational. Nobody launches a scope fence. The reason I got there first is not that I am clever, it is that I hit the specific failure that made the constraint necessary, and I hit it while the ecosystem was still busy shipping the capability. The fence exists because I could imagine the self-editing job going wrong in my repo. The bid clamp exists because it is my money.
The generalizable version: you will be behind on what the agent can do and ahead on what you have decided it may not do. The second one is where your actual context lives, and it does not transfer, which is exactly why nobody has written it down for you.
Caveats on the method
Two, and they matter.
My Claude configuration directory is not a git repo, so dates for the hooks and agent definitions come from file modification times. That is a weaker signal than a commit, and it only tells you the file was created at or before that date. Repository dates are solid; configuration dates are approximate.
And “when did this go mainstream” is a fuzzy question. I have high confidence where there is a dated spec revision or a product launch to point at, and much lower confidence on diffuse questions like when a practice became common advice. Absence of documentation is also not proof of absence. Somebody may well have been routing diffs to a rival model in 2024 and simply never blogged it.
Still. I went in assuming I was ahead, and on the four things I would have named first, I was behind by one to two years. Worth checking your own assumption. The audit took an afternoon and the useful half was the half that made me wince.