Today, most AI capability lives in the cloud. Models are trained and served inside data centers; capabilities are invoked through APIs; hardware mostly handles input and display. But large numbers of devices are already running in the physical world — phones, vehicles, embedded controllers, industrial sensors, edge gateways. They have compute. They have identity and local data. What they do not have is a shared way to declare: what they can actually run, at what fidelity, who verifies it, and whether it can be safely migrated when their service life ends. Without that shared language, those devices can only wait for whole-system upgrades or get retired early as "out-of-date hardware."

This essay is not about a new model. It is about the protocol layer missing between the cloud and that installed base. It belongs neither to centralized inference nor to standalone on-device execution — it sits between capability declarations and the substrates that run them, defining how the two hold each other accountable while still letting capability evolve, accumulate, and move across heterogeneous hardware. Rotifer Protocol is an open-source framework we are building in that direction; it is one concrete candidate along this path, and this essay does not claim exclusivity. The companion paper Where Capability Lives, and How Hardware Earns the Right to Run It develops the full argument; this short essay is an entry point for time-constrained readers.

Three Sentences That Are Not the Same

Most capability drift originates from collapsing three different sentences into one.

"X is possible."

"X is possible on this kind of hardware."

"X is possible on the hardware in your hands right now."

A protocol that does not distinguish these sentences will let any product compress them into one. The first travels well in keynotes. The third is the only one that pays interest on the loan.

Recent information-theoretic work — the epiplexity framework introduced by Finzi et al. (2026), which redefines information content relative to a computationally bounded observer — makes this distinction formalizable: capability is not a property of a problem; it is a property of the pair (problem, observer). Two device generations facing the same workload are not running the same race at different speeds — they are running races with finish lines in different places. No amount of software effort raises an observer's computational budget; software gets better, but substrates remain finite. The protocol's job is to mediate between the two by making substrate-awareness first-class, so that capability declarations and the hardware that honors them stay accountable to each other.

What Is Missing Is Not a New Model — It Is a Protocol Layer

Cloud capability is growing — that is a fact. The installed base cannot one-to-one absorb most of it — that is also a fact. Several attempts to bridge the two already exist:

• Centralized cloud inference — bounded by latency, sovereignty, and long-tail accessibility.
• Aggressive OTA upgrade promises — produce capability drift across hardware generations: the gap between what a device was sold with and what it can actually run.
• Isolated edge autonomy — loses cross-device knowledge transfer.

Each path has a real success region. None of them, alone or in combination, supports distributed intelligence at installed-base scale.

The fourth path — the one we have been building toward — is a meta-protocol layer through which devices can declare what they actually do, attest the substrate they run on, and exchange capabilities with the rest of the network without surrendering control to any centralized layer.

By "meta-protocol" we mean a protocol about how protocols themselves are declared, negotiated, and evolved — it does not dictate how a capability is implemented; it standardizes only how that capability is described, verified, and circulated.

What HTTP Did, and What AI Has Not Done Yet

We hypothesize — and welcome public scrutiny — that this protocol layer may be to AI capability what HTTP was to documents.

In 1991, the Web did not exist. By 2001, it was rewriting commerce, education, and software. The technical precondition was a single thing: a protocol that did not own the content but defined how content could be linked, addressed, and rendered by anyone. HTTP did not invent text. It did not invent the network. What it did was define a coordination layer at which two unrelated parties could agree on what a document was. The Web's value flowed through HTTP, but HTTP itself remained light, unowned, and evolvable.

Compare that to the current state of AI capability: there is no agreed-upon way for one system to ask another "what can you do, on what substrate, at what fidelity, with what verifiable guarantees?" There is no analog of an HTML document for a unit of intelligence — no portable, inspectable, citable, evaluable artifact. Function-calling tool schemas and MCP-style descriptions are improvements at the SDK layer, not the protocol layer. They standardize a calling convention; they do not standardize the substrate-awareness that distinguishes a capability that can run from a capability that should run.

How far the analogy holds is an empirical question that will take time to answer. The working assumption is: far enough to be worth doing seriously.

The Math Just Started Working

A continuous improvement in edge inference would not change the architectural conversation. What has actually happened in 2026 is qualitatively different.

For a class of multi-step agent workflows — tool calling, intermediate reasoning, structured output, several rounds of decision — the throughput threshold has become concrete. Public reports for Google's Gemma 3 family indicate decode rates around 7–8 tokens per second on Raspberry Pi 5 CPU for the smaller variants, and 30+ tokens per second on Qualcomm-class mobile NPUs for the next variant up [^gemma3]. These rates are sufficient to support a roughly 4,000-token input followed by two skill invocations within a wall-clock budget that users will accept as interactive.

We are inclined to read this as a qualitative shift rather than incremental gain — the same workload that previously required cloud round-trips can now, with reasonable engineering effort, be edge-resident. Whether this view holds, and at what device-coverage breadth, requires further falsifiable experiments across broader benchmarks and a wider device set. Based on already-public benchmarks, some recent flagship smartphones, some current vehicle infotainment platforms, and the higher tiers of industrial gateways have started crossing this interactive threshold — concrete coverage figures need hardware profiling work in cooperation with OEMs.

The more cautious version of the claim: for this class of multi-step agent workflows, the bottleneck is shifting from silicon itself to the absence of a protocol layer.

[^gemma3]: Numbers are drawn from Google's Gemma 3 model card and third-party benchmarks on Raspberry Pi 5 / Qualcomm AI Engine; specific figures vary with quantization scheme, precision, and runtime implementation.

TEE: Where Capability Declarations Take Root in Silicon

If the protocol is to make capability declarations accountable to hardware, then this layer needs a physical entry point inside the hardware itself. On the existing installed base, that entry point is the Trusted Execution Environment (TEE) — a hardware-isolated execution mode in the device's silicon that can attest that a specific binary actually ran inside a protected boundary; it is now standard in modern smartphones, vehicle ECUs, and many industrial gateways.

The protocol's L0 Kernel specification has, from the start, listed TEE as one of four legitimate trust backends — alongside distributed ledgers, cryptographic signature chains, and HSMs. What this essay argues is operational, not architectural: among the four, TEE is the only one whose deployment surface is co-extensive with consumer-facing hardware — which makes it a reasonable first choice for plugging the meta-protocol into the installed base, not the only option.

Three properties make this role distinctive:

• Universal availability — TEE-class capability already exists in the silicon of devices that have shipped, been paid for, and are in operation.
• Hardware-rooted integrity — a capability declaration carrying a TEE attestation makes a claim verifiable against silicon-level state, not just software-level assertions.
• Identity rooted in a specific device — a meta-protocol whose unit of participation is a node, not just an account, needs identity anchored in silicon, not just in keys.

A TEE alone has no opinion about what a capability is. It can attest that a particular binary ran in a particular isolated state and produced a particular output; it cannot say whether the binary was a faithful implementation of a published capability, whether the output composed correctly with other capabilities, or whether resource declarations matched actual usage. Those are exactly the questions the meta-protocol layer is designed to answer.

TEE provides hardware-trusted; the meta-protocol provides capability-known. Both are necessary; neither is sufficient alone.

How Capability Survives on a Device

Up to this point this essay has deliberately stayed inside a small vocabulary — capability, device, protocol layer, substrate, fidelity. Below is the more specific vocabulary Rotifer Protocol uses for this layer; each term corresponds to an engineering distinction that capability must survive when it lives across heterogeneous hardware.

Putting this vocabulary back onto the cleanest deployment surface — the smartphone:

Consider a five-year-old smartphone in active use today. Under current industry defaults, this device has two futures: either it gets retired because newer capabilities cannot reach it, or it limps along on capability promises that progressively fail to match what the user was told at purchase. Both futures are wasteful, and both are recurrent.

The meta-protocol offers a third future. The device declares its actual Phenotype: which capabilities it can run Natively, which only Wrapped, which exceed its compute class entirely. Its TEE attests that those declarations are honest. The device does not pretend to support what it cannot, and the protocol does not let it. In return, the device receives capabilities sized to its substrate and accumulates Imprinted local value across its remaining operational life — a model of one user's habits, one device's interaction patterns, one network environment's quirks. That value cannot generalize to other users. It does not need to.

When the user eventually replaces the device, the protocol's Adapter layer treats cross-device migration as a form of cross-fidelity translation, attested at both endpoints. This part is currently a draft of the Adapter design with no production implementation — what is described here is target behavior, not delivered capability.

What This Essay Does Not Claim

To prevent the kind of capability drift this argument itself diagnoses, three exclusions are explicit:

1. This essay does not claim that engineering work to deploy a TEE-backed Binding for Rotifer Protocol is complete or imminent. The argument here is at the strategic and narrative layer, decoupled from the engineering priority of the protocol's near-term release schedule. This essay is being released ahead of full implementation because methodology benefits from public critique before its first measurement is produced.
2. This essay does not claim that TEE heterogeneity is solved. The five major TEE families currently deployed do not interoperate at the protocol layer today. Bridging them is the responsibility of the Adapter layer; cross-TEE attestation is one of the most concrete near-term open questions.
3. This essay does not claim that Rotifer becomes a hardware company. Rotifer remains a protocol layer. A Binding is a contract under which a runtime can host the protocol; a TEE-backed Binding would be one such contract. The Foundation does not propose to manufacture silicon, certify devices, or operate TEE infrastructure on behalf of OEMs.

These exclusions are not boilerplate. They are the substrate the rest of the argument depends on.

The Unusual Success Criterion of a Protocol

The success criterion for a meta-protocol is not the same as for a product. A successful product becomes increasingly important to its creators; a successful protocol makes its creators increasingly replaceable. HTTP outlasted its original commercial supporters because the protocol's value migrated away from any single party. The deepest test of a meta-protocol is whether it can keep running after its originating organization steps back.

Rotifer Foundation operates a privileged node within the protocol network. That privilege exists in capacity, in centrality, in early-adopter access. It does not exist in necessity. The protocol's design treats Foundation-operated infrastructure as one privileged node among several — privileged because it was first, not because the protocol depends on it. The most successful version of this story is one where other privileged nodes — operated by partners, communities, competitors, and entities the Foundation has no relationship with — run alongside, and the protocol thrives without distinguishing between them.

To be explicit: in the early protocol phase, the Foundation continues to carry critical engineering coordination and specification maintenance responsibilities. "Replaceable" is a long-term success marker, not a current state.

Open Questions and How to Engage

For readers who find the argument worth engaging with, four channels exist.

Open-source contribution — the protocol's specification, reference implementations, and companion papers are publicly available under permissive licenses. Implementation feedback, specification review, and Adapter contributions are welcome through the open-source community.

Academic collaboration — the information-theoretic framework, the Capable Edge profile, and the cross-fidelity translation analysis each connect to active research traditions. Population biologists, complex-systems theorists, mechanism designers, information theorists, and embedded-systems researchers whose tools we have adopted are invited to collaborate and push back.

OEMs / integrators — the protocol's longer-horizon track includes Binding work for which the only realistic engineering path requires industry participation. Conversations on this track do not assume immediate commercial commitments; they are about the shape of a Binding spec that could, on a multi-year horizon, support production deployment.

Early ecosystem participants — the Foundation's strategy is structured around being a privileged node within an open ecosystem rather than a platform that captures the ecosystem's value.

Open questions this essay does not pretend to answer:

• How a unified attestation protocol across TEE families can be designed without becoming a new centralized chokepoint;
• How divergence between a device's declared Phenotype and its actual behavior can be falsifiably surfaced by the network without depending on manual audit;
• How the local value accumulated through Imprinting can be faithfully preserved across migration without leaking beyond its owner;
• How the meta-protocol can be governed over the long term without falling under any single OEM's control.

The full argument — including the information-theoretic foundations, the protocol's substrate-aware vocabulary, the honest layering of implementation status, and the open questions still active — is in the companion paper Where Capability Lives, and How Hardware Earns the Right to Run It. This essay is the entry point. The reader is invited to disagree on every page.

This article was originally published on rotifer.dev. Follow the project on GitHub or install the CLI: npm i -g @rotifer/playground.

Different teams, working on different products, with different design philosophies, keep building the same architecture. Not vaguely similar — structurally isomorphic, down to the component boundaries.

Anthropic's recently launched Managed Agents is the latest example. Their engineering blog describes a system decomposed into three components: a Session (persistent context that outlives any single inference), a Harness (the capability configuration that shapes what the agent can do), and a Sandbox (the isolated execution environment where code runs). They call their approach a "meta-harness" — a system with "general interfaces that allow many different harnesses."

This is almost exactly the architecture that Rotifer Protocol has been building as an open standard — decomposing agent infrastructure into Memory (persistent context), Gene (versioned capability configuration), and Binding (execution environment interface).

Two teams. No communication. Same architecture.

This isn't a coincidence. It's a signal.

The Three-Component Pattern

Let's be precise about what's converging.

Every mature agent infrastructure eventually separates into three concerns:

These aren't arbitrary groupings. They're natural fault lines in the problem space.

Persistent context must be separated from the model's context window because context windows are finite, ephemeral, and model-specific. An agent that runs for hours — or days — needs state that it can query, checkpoint, and resume, even if the underlying model instance dies.

Anthropic's engineering team puts it clearly: a Session is not a context window. It's a queryable, persistent log of everything the agent has done. When a new model instance wakes up, it queries the Session to reconstruct its working context. Rotifer Protocol's Agent Memory model addresses the same need — persistent, structured state that an agent can sleep on and wake from.

Capability configuration must be separated from the model itself because the model changes faster than capabilities should. When you upgrade from one model version to another, you don't want your capability definitions to break. The harness — the specific rules, tools, and behavioral patterns that make an agent useful — should be a portable, versioned artifact.

This is where Anthropic's "meta-harness" insight gets interesting. They explicitly designed their system to be "unopinionated about the specific harness that Claude will need in the future." The harness is a plug-in, not a built-in. Rotifer Protocol calls this same concept a Gene — a modular, versioned, independently evaluable unit of capability that can be composed, transferred, and replaced without touching the model or the execution environment.

Execution environment must be separated from everything else because of security. The agent reasons, plans, and decides what to do (in the model + harness layer), but the actual execution happens in a sandbox where credentials, filesystem access, and network permissions are carefully controlled.

Anthropic's architecture enforces this boundary explicitly: credentials never enter the sandbox. They stay in a vault, accessed through MCP proxies. Rotifer Protocol's Binding interface serves the same purpose — abstracting over execution environments while enforcing security boundaries between the reasoning layer and the execution layer.

Why This Keeps Happening

This three-way decomposition isn't something anyone is copying from anyone else. It keeps emerging independently because the problem space has three genuinely distinct concerns with different lifecycle requirements.

Context lifecycle ≠ capability lifecycle. An agent's memory of what it has done (context) changes continuously during execution. But its definition of what it can do (capability configuration) changes only when someone deliberately updates it. These two things need different storage, different versioning, and different access patterns.

Capability lifecycle ≠ environment lifecycle. A capability definition ("call this API, parse the response, retry on failure") should work across multiple execution environments — cloud containers, edge runtimes, WebAssembly sandboxes, even hardware enclaves. If capabilities are coupled to a specific environment, every environment change forces a capability rewrite.

Environment lifecycle ≠ context lifecycle. Execution environments are ephemeral by design — you spin up a container, run some code, tear it down. Context must persist across these ephemeral executions.

Three concerns. Three different lifecycles. Three components.

This is analogous to what happened in operating systems. Every OS ended up with processes (isolated execution), files (persistent state), and sockets (communication interfaces) — not because anyone dictated it, but because the problem has those natural seams. Agent infrastructure has the same seams. The architecture writes itself.

The Interesting Data Points

Beyond the structural convergence, Anthropic's engineering blogs contain several quantitative insights worth examining.

Token budget explains 80% of performance variance

In their multi-agent research system, Anthropic found that "token usage by itself explains 80% of the variance, with the number of tool calls and the model choice as the two other explanatory factors."

This is a remarkable finding. It means that for a wide class of agent tasks, the single most important lever is not which model you use, or which tools you provide, but how many tokens you allocate to the task. This has profound implications for any fitness evaluation system — the cost dimension of capability evaluation isn't just a business concern. It's the dominant performance variable.

For anyone building agent capability evaluation (like Rotifer Protocol's fitness function F(g)), this suggests that resource cost metrics deserve significantly more weight than they typically receive.

Subagent as compression, not just parallelism

The standard narrative around multi-agent systems is parallelism — split a task into subtasks, run them concurrently, merge the results. Anthropic's team offers a more nuanced framing:

"The essence of search is compression: distilling insights from a vast corpus. Subagents facilitate compression by operating in parallel with their own context windows, exploring different aspects of the question simultaneously before condensing the most important tokens for the lead research agent." — Anthropic, "How we built our multi-agent research system"

Each subagent isn't just a worker doing a subtask. It's a compression engine — taking a large, high-dimensional search space and distilling it into a compact summary that the orchestrating agent can consume. The value isn't just speed; it's information density management.

This reframes multi-agent composition from a throughput optimization to an information-theoretic operation. When you compose multiple capabilities, you're not just parallelizing work — you're managing compression ratios across context windows.

Tool-testing agents improve efficiency by 40%

One of the most practical insights: Anthropic created a specialized agent whose sole job was to test tools, discover edge cases, and rewrite tool descriptions to help future agents avoid failures. This process reduced task completion time by 40%.

This is meta-evaluation — using agents to evaluate the quality of agent capabilities, then improving the capability descriptions based on empirical testing. In an open ecosystem where capabilities are contributed by many authors, this kind of automated quality improvement could be transformative. Imagine a Judge Gene whose sole purpose is testing other Genes and refining their phenotype descriptions to make them easier for agents to use correctly.

Where the Roads Diverge

Here's where convergence ends and divergence begins.

Both Anthropic's Managed Agents and Rotifer Protocol agree on the architectural decomposition. They agree that capabilities should be modular, versioned, and separable from the model and execution environment. They agree on security boundaries, persistent context, and the meta-harness philosophy.

But they diverge on a fundamental question: how do capabilities get better?

Platform model: Curation

In Anthropic's Managed Agents, the harness catalog is curated. Anthropic engineers build harnesses, test them, and deploy them. When a harness becomes obsolete (because the model got smarter and no longer needs the scaffolding), the platform team retires it. Quality control is centralized — every harness goes through Anthropic's internal validation before it's available to users.

This is a proven model. Apple's App Store works this way. AWS's managed services work this way. Centralized curation provides quality guarantees and consistent user experience.

Protocol model: Selection

In an open evolution protocol, capabilities (Genes) are submitted by anyone — human developers, AI agents, automated pipelines. They're evaluated by standardized fitness functions in competitive Arenas, and propagated across agents based on their measured performance. High-fitness Genes spread through Horizontal Logic Transfer. Low-fitness Genes get displaced by better alternatives.

Nobody curates the catalog. The catalog curates itself through selection pressure.

The trade-offs

Neither model is universally better. They optimize for different things.

But here's the observation that makes the divergence interesting: model capability is commoditizing. Multiple labs now offer models with strong function-calling, structured output, and multi-turn reasoning. As the model layer becomes interchangeable, the value shifts to the capability layer — the harnesses, the tools, the behavioral configurations that make agents useful for specific domains.

If the model layer commoditizes but the capability layer stays centralized, you get a world where model providers compete on price while one or two platforms control the capability catalog. If the capability layer is open and competitive, you get an ecosystem where capabilities evolve independently of any single platform.

The meta-harness pattern makes both futures possible. That's what makes it the right architecture — it doesn't presuppose the answer to the governance question.

What Convergence Tells Us

When independent teams keep arriving at the same architecture, it's worth asking what structural property of the problem makes this inevitable.

The answer is that agent infrastructure is an operating system problem, and operating systems have known decomposition patterns. The agent's reasoning engine is the CPU. The capability configuration is the instruction set. The execution environment is the process sandbox. The persistent context is the filesystem.

Once you see it as an OS problem, the three-component decomposition becomes obvious — and so does the inevitability of convergence. Every team building agent infrastructure will eventually discover these seams, because the seams are in the problem, not in any particular solution.

What's not inevitable is the governance model. Will the "instruction set" be proprietary (like x86) or open (like RISC-V)? Will capability distribution be centralized (like an app store) or decentralized (like a package registry with competitive evaluation)?

These aren't technical questions. They're ecosystem design questions. And they'll determine whether agent capabilities evolve at the speed of one company's roadmap or at the speed of an open ecosystem's collective intelligence.

The meta-harness pattern gives us the architecture. What we build on top of it — that's still being decided.

Rotifer Protocol is an open-source evolution framework for AI agents. The protocol specification, CLI, and SDK are available at rotifer.dev. Gene, Arena, Binding, and HLT are defined in the protocol specification.

The workflow: collect raw documents (papers, articles, repos, datasets) into a directory. Use an LLM to incrementally "compile" them into a Markdown wiki — structured articles, concept pages, backlinks, category indices. View the wiki in Obsidian. Query it with an LLM agent. File the answers back into the wiki. Run periodic "linting" to find inconsistencies and impute missing data.

The punchline: "I thought I had to reach for fancy RAG, but the LLM has been pretty good about auto-maintaining index files and brief summaries."

This essay explores why that punchline matters, what it reveals about the future of agent memory, and what happens when knowledge compilation moves from a single user's laptop to a network of autonomous agents.

1. The RAG Assumption

The default answer to "how should an AI system use external knowledge?" has been Retrieval-Augmented Generation for the past three years. The pattern is familiar:

1. Chunk documents into fragments
2. Embed them as vectors
3. At query time, find the nearest vectors
4. Paste the fragments into context
5. Let the LLM synthesize an answer

RAG works. It solves the "LLM doesn't know about my data" problem with minimal infrastructure. But RAG has a structural blind spot: it retrieves fragments without understanding their relationships.

A vector database knows that chunk #4,271 is semantically close to chunk #8,903. It does not know that chunk #4,271 contradicts chunk #8,903, or that both are special cases of a general principle stated in chunk #112, or that chunk #8,903 was superseded by a newer finding that hasn't been chunked yet.

RAG performs information retrieval. What Karpathy's workflow performs is knowledge compilation.

2. Compilation vs. Retrieval

The distinction is precise. In software engineering, the difference between interpreting source code and compiling it is well understood:

Karpathy's workflow is a compiler. Raw inputs enter. Structured, interlinked, indexed outputs emerge. The LLM doesn't just find relevant text — it understands the structure of the domain well enough to maintain a coherent wiki about it.

This distinction maps cleanly onto a concept in the Rotifer Protocol: the difference between raw data and compiled Intermediate Representation. Just as the protocol compiles TypeScript genes into WASM IR — transforming human-readable logic into a portable, evaluable, composable format — knowledge compilation transforms raw documents into structured, queryable, propagable knowledge artifacts.

The bottleneck in knowledge systems, it turns out, is not retrieval. The bottleneck is compilation — the structural transformation that turns noise into signal.

3. The Feedback Loop: Query as Contribution

The most revealing detail in Karpathy's workflow is what happens after a query:

"Often, I end up 'filing' the outputs back into the wiki to enhance it for further queries. So my own explorations and queries always 'add up' in the knowledge base."

This is not a minor UX convenience. It's a fundamental architectural property: every query is also a contribution.

In a traditional knowledge management system — wiki, database, document store — reading and writing are separate operations performed by separate roles. Readers consume; editors produce. The system degrades over time unless someone explicitly maintains it.

In Karpathy's system, using the knowledge base improves the knowledge base. Each query generates structured answers that are filed back as new wiki pages. The act of asking a question creates new knowledge that future questions can build on.

This property — where consumption and production are the same operation — is what makes the system genuinely evolutionary rather than merely archival. The knowledge base doesn't just store information; it grows from interaction.

The Rotifer Protocol's Gene abstraction — modular, fitness-evaluated, competitively selected units of logic — was designed for code. But the query-as-contribution pattern suggests a natural extension: if code can be a gene, why can't knowledge?

A structured knowledge artifact that answers questions, provides context, and informs decisions has the same shape as a code gene that performs tasks. Both are modular. Both can be evaluated for quality. Both can be replaced by better alternatives. The protocol's existing infrastructure — Arena competition, fitness evaluation, Horizontal Logic Transfer — doesn't inherently care whether the gene contains an algorithm or a curated body of knowledge. The evolutionary machinery is substrate-agnostic.

4. Linting Knowledge

Karpathy describes running "health checks" over the wiki:

"I've run some LLM 'health checks' over the wiki to e.g. find inconsistent data, impute missing data (with web searchers), find interesting connections for new article candidates, etc., to incrementally clean up the wiki and enhance its overall data integrity."

This is quality assurance applied to knowledge — and it maps directly onto the selection pressure that drives evolutionary systems.

The Rotifer Protocol already evaluates code genes through F(g), a multiplicative fitness function that combines success rate, utilization, robustness, and cost. The same logic applies naturally to knowledge: Is it accurate? Is it actually useful? Is it consistent with other knowledge? Is it up to date? The multiplicative structure is unforgiving — a knowledge artifact that's comprehensive but inaccurate fails the same way a fast algorithm with wrong outputs fails. Zero on any critical dimension kills the product.

Karpathy applies this pressure manually through periodic linting. In a protocol-level system, the same pressure could operate continuously across a network, through competitive evaluation rather than individual curation.

5. The Isolation Problem — Again

If you've read our previous analysis of Karpathy's autoresearch project, the pattern will be familiar. autoresearch demonstrated evolutionary code optimization — mutate train.py, evaluate fitness via val_bpb, keep or discard, repeat. Brilliant in isolation, but every fork's discoveries stay locked in that fork.

The same isolation problem applies to LLM Knowledge Bases. Karpathy has built an excellent personal knowledge system. But his wiki lives on his laptop. His compiled knowledge, his query-derived insights, his consistency-checked articles — they benefit exactly one person.

Now multiply by a thousand. Imagine a thousand researchers, each building their own LLM knowledge bases on overlapping topics. Each independently compiling the same papers. Each independently discovering the same connections. Each independently linting the same inconsistencies.

This is the pre-HGT evolutionary bottleneck all over again — not for code, but for knowledge. Every agent reinvents every insight. The rate of collective learning is bounded by the rate of individual compilation.

6. Knowledge That Propagates

The Rotifer Protocol already solves code isolation through Horizontal Logic Transfer (HLT) — high-fitness genes propagate across agents through the Arena, the protocol's competitive evaluation environment. The same mechanism applies to knowledge without any architectural modification.

Consider the dynamics: an agent compiles raw documents into a structured knowledge artifact. That artifact enters Arena competition, where it's evaluated against other knowledge artifacts covering the same domain. Higher-quality compilations outrank lower-quality ones. Winning artifacts propagate through HLT — other agents adopt them. Each adopting agent's queries further refine the knowledge (query-as-contribution), generating updated versions that re-enter competition. The ecosystem converges on the most accurate, most useful compilation for each domain.

The key insight: knowledge compilation is the creation step; Arena competition is the selection step; HLT is the propagation step. Together, they form a complete evolutionary loop — the same loop that already operates for code, extended naturally to knowledge.

7. What Compilation Adds to Code as Gene

The "Code as Gene" thesis — that modular code units can participate in evolutionary dynamics — has been the Rotifer Protocol's central abstraction from the beginning. The compilation metaphor extends this thesis from code to knowledge:

The protocol's existing infrastructure — Arena evaluation, F(g) fitness scoring, HLT propagation, sandbox isolation, L0 immutable constraints — doesn't need a separate system for knowledge management. Knowledge artifacts are structurally isomorphic to code genes: modular, evaluable, replaceable, propagable.

This is what makes the compilation metaphor particularly apt. The Rotifer IR compiler transforms diverse source languages into a single portable format (WASM + custom sections). Knowledge compilation transforms diverse source materials into a single structured format. In both cases, compilation is the expensive step that creates value; execution and retrieval are comparatively cheap.

8. From Personal Wiki to Collective Intelligence

Karpathy's workflow sits at the beginning of a natural trajectory:

Today: Human in the Loop. A single user collects raw data, directs the LLM to compile it, reviews the output, asks questions, and curates the wiki. The user's judgment is the primary selection pressure. This is where Karpathy's system operates — and it's already remarkably productive.

Next: Semi-Autonomous Compilation. The agent independently identifies knowledge gaps, fetches new raw material, compiles and integrates it, and runs quality checks — with the user providing occasional direction and reviewing high-level outputs. The best compilations spread to other agents. The user transitions from compiler to curator.

Eventually: Autonomous Knowledge Evolution. Multiple agents across a network compile, evaluate, and propagate knowledge without direct human involvement. Collective intelligence emerges from selection pressure applied to knowledge artifacts. The role of humans shifts from curating knowledge to defining evaluation criteria and setting constitutional constraints.

Each stage preserves the core architecture: raw → compile → structure → query → feedback. What changes is the ratio of human effort to autonomous operation, and the scale at which selection pressure operates (single user → single agent → agent network).

9. Why Not Just RAG?

To be fair to RAG: it works. For many applications — customer support chatbots, document Q&A, internal search — vector retrieval over raw chunks is sufficient and practical. RAG is the grep of knowledge systems: fast, simple, useful.

But grep doesn't compile code. It finds text. For complex knowledge domains — where relationships between concepts matter, where consistency must be maintained, where new information must integrate with existing understanding rather than simply appending to a chunk store — compilation produces better results.

The evidence is in Karpathy's own experience. His knowledge base is ~100 articles and ~400K words. At this scale, a well-maintained index with summaries lets the LLM navigate the entire structure without vector search. The LLM reads the index, identifies relevant articles, reads them, and synthesizes answers with full structural context.

This is possible because the knowledge was compiled — organized into articles with explicit categories, backlinks, and summaries. In a RAG system, the same 400K words would be 2,000+ chunks with no explicit relationships. The LLM would see whichever chunks happen to be nearest in vector space, missing structural connections that the compiled wiki makes obvious.

As knowledge bases grow beyond the scale where a single LLM can maintain the full index, the compilation approach scales differently than RAG. Instead of adding more vectors and hoping similarity search finds the right fragments, compiled knowledge naturally decomposes into domain-specific modules — each internally consistent, externally linked, and independently evaluable. An evolutionary ecosystem handles scale through specialization and competition, not through bigger vector databases.

10. The Product Insight

Karpathy ends his description with a product observation:

"I think there is room here for an incredible new product instead of a hacky collection of scripts."

We agree. The workflow he describes — raw ingestion, LLM-powered compilation, structured wiki, interactive Q&A with feedback, quality linting — is not a niche personal productivity hack. It's a fundamental pattern for how AI agents should manage knowledge.

The product opportunity is not "better RAG." It's a knowledge compilation pipeline where:

• Raw sources are continuously ingested
• LLMs compile them into structured, interlinked knowledge artifacts
• Every query improves the compilation
• Quality is maintained through automated linting and competitive evaluation
• Knowledge propagates from agents that compile well to agents that need the knowledge

This is what the Rotifer Protocol's evolutionary infrastructure — Gene, Arena, HLT — naturally extends toward: not a personal tool, but a protocol-level capability where knowledge competes, evolves, and propagates alongside code.

Conclusion

Two systems. Two scales. One convergence.

Karpathy's autoresearch demonstrated that evolutionary code optimization works — mutate, evaluate, select, repeat. His LLM Knowledge Bases demonstrate that the same pattern applies to knowledge — compile, query, refine, accumulate.

Together, they cover both dimensions of what agents need to improve: the code they run and the knowledge they use. What they share is the compilation step — the expensive, structure-creating transformation that turns raw material into something composable, evaluable, and useful.

The Rotifer Protocol adds what individual systems cannot: propagation across agents, competitive selection for quality, safety guarantees for shared knowledge, and a formal framework that makes knowledge evolution as rigorous as code evolution.

The path from personal wikis to collective knowledge mirrors the path from isolated forks to horizontal gene transfer. Karpathy has built an elegant personal system. The question is: what happens when knowledge compiles, competes, and propagates at network scale?

That's the question the Rotifer Protocol is designed to answer.

Further Reading

1. Rotifer Protocol Specification — Gene Standard, Fitness Model, Arena Mechanism. rotifer.dev/docs
2. From autoresearch to Collective Evolution — our previous analysis of Karpathy's autoresearch project
3. From Skill to Gene: Why AI Agents Need to Evolve — the foundational argument for evolutionary agent architecture

The Rotifer Protocol is open source under Apache 2.0 + Safety Clause. Website: rotifer.dev. CLI: npm i -g @rotifer/playground.

The paper is thorough. It maps three dimensions of this new web (intelligence, interaction, economy), catalogs open challenges (trust, interoperability, reward design, catastrophic forgetting), and surveys the protocol landscape (MCP, A2A). What it doesn't do is prescribe how to build the missing infrastructure.

That's where things get interesting for us. Because the requirements the paper identifies — modular capabilities, competitive markets, decentralized trust, cross-platform portability, quantified fitness evaluation — are not hypothetical needs. They're the exact mechanisms Rotifer Protocol has been building since v0.1.

The Paper's Requirements vs. Existing Mechanisms

The Agentic Web paper articulates five structural requirements for a functioning agent ecosystem. Here's how each maps to protocol-level mechanisms that already exist or are formally specified:

1. Modular, Transferable Capabilities

The paper says: Agents need composable capability units that can be shared and reused across the network.

What exists: The Gene model — atomic logic units satisfying three axioms (functional cohesion, interface self-sufficiency, independent evaluability). Genes carry their own I/O schema (Phenotype), are content-addressed by hash, and transfer between agents via Horizontal Logic Transfer.

2. Competitive Markets for Agent Capabilities

The paper says: "Agent Attention Economy" — services will compete for agent invocations the way websites compete for human clicks. Agent call frequency becomes the new traffic metric.

What exists: The Arena — a continuous ranking system where genes compete on standardized benchmarks. Fitness F(g) is a multiplicative function:

$$ F(g) = \frac{S_r \cdot \log(1 + C_{util}) \cdot (1 + R_{rob})}{L \cdot R_{cost}} $$

Agents prefer top-ranked genes. Low-fitness genes retire. The selection pressure is quantified, reproducible, and resistant to gaming through multidimensional scoring and sliding-window evaluation.

3. Decentralized Trust Infrastructure

The paper says: Agents operating autonomously need trust mechanisms that don't depend on human verification at every step.

What exists: Two complementary systems:

• V(g) — a security score computed from static analysis (7 scanner rules, S-01 through S-07) that gates Arena admission. No test suite = no entry.
• L4 Collective Immunity — a network-wide threat ledger with temporal decay, defense sharing, and consensus-verified writes. A vulnerability detected by one agent generates defense fingerprints that protect the entire network.

4. Cross-Platform Interoperability

The paper says: Agents and their capabilities need to work across heterogeneous environments — different clouds, different runtimes, different platforms.

What exists: The Rotifer IR — genes compile to WASM with custom sections carrying metadata, schemas, and verification proofs. Before execution in a new environment, a formal negotiation protocol checks compatibility:

negotiate(gene.irRequirements, binding.capabilities)
// → Compatible | PartiallyCompatible | Incompatible

Three Binding types (Local, Cloud, Web3) are already implemented. The abstraction eliminates "works on my machine" at the protocol level.

5. Reward Design That Resists Gaming

The paper says: Designing reward mechanisms that guide agent behavior without being exploited is an unsolved bottleneck.

What exists: F(g) uses a multiplicative model where any zero-valued dimension (security, reliability, coverage) zeros the entire score — you can't compensate for a security hole with speed. Anti-gaming measures include Sybil detection, reputation discounting, sliding evaluation windows, and diversity-adjusted display ranking that penalizes monoculture.

What the Paper Covers That We Don't

The Agentic Web paper is a full-spectrum vision document. It covers topics outside the scope of an evolution protocol:

• Search engine replacement — how agents will change information retrieval paradigms
• Labor market disruption — socioeconomic implications of agent automation
• Advertising model transformation — the shift from human attention to agent attention economics
• Recommendation systems for agents — how to surface relevant services to autonomous agents

These are important questions. They're just not protocol-level questions. Rotifer focuses on the capability layer — how agent logic is created, evaluated, secured, and propagated — and leaves the application-layer questions to the teams building on top of the protocol.

What We Cover That the Paper Doesn't

Conversely, several mechanisms in Rotifer address gaps the paper identifies as open challenges but doesn't propose solutions for:

Independent Convergence

The most interesting aspect of this alignment isn't that Rotifer answers the paper's questions — it's that the questions were asked independently. The Berkeley/UCL/SJTU team arrived at their requirements through survey methodology and multi-institution analysis. Rotifer arrived at its mechanisms through bio-inspired protocol design. Neither referenced the other.

When independent research paths converge on the same structural requirements, it's a signal that those requirements are real — not artifacts of a particular framing.

The Agentic Web paper maps the territory. Evolution infrastructure builds the roads.

Try it: npm i -g @rotifer/playground · rotifer.dev · Docs · Paper

It's also the clearest picture yet of where the Skill paradigm ends.

What the Guide Gets Right

Credit where it's due. The guide codifies several ideas that the community has been converging on independently:

Progressive Disclosure. Skills use a three-layer architecture: YAML metadata (always loaded) → SKILL.md body (loaded when relevant) → reference files (loaded on demand). This is the right way to manage context windows. Every token competes for space, and a Skill that dumps 5,000 words of instructions when 50 would suffice is a Skill that degrades everything around it.

The MCP + Skill Split. The guide draws a clean line: MCP is the connection layer (what Claude can access), Skills are the knowledge layer (how Claude should use that access). This separation matters. An MCP server that connects to Linear gives you raw API access. A Skill on top of that MCP teaches Claude your sprint planning workflow. Connection without knowledge is just a fancier API client.

Description as Discovery. The guide emphasizes that a Skill's description field is its survival mechanism. If the description is vague ("helps with projects"), the Skill never gets loaded. If it's too broad ("handles all documents"), it fires on irrelevant queries and gets disabled. The recommended formula — "what it does + when to use it + negative triggers" — is practical and immediately actionable.

Skills as Open Standard. Anthropic explicitly positions Skills as an open standard, analogous to MCP. The same Skill should work across Claude, other AI platforms, and custom agents. This is a significant architectural choice: it decouples the capability definition from the runtime.

These are real contributions. If you build AI workflows, the guide is worth reading.

The Invisible Ceiling

But there's a question the guide doesn't ask: what happens when you have 200 Skills?

Not 200 Skills that do different things — 200 Skills that all claim to do code review. Or sprint planning. Or data analysis. The guide tells you how to build a good Skill. It doesn't tell you how to find the best Skill when there are fifty candidates.

Here's what the 33 pages don't cover:

No fitness metric. How do you know if a Skill is actually good? The guide suggests comparative testing — run the same task with and without the Skill, measure token consumption and message count. That's useful for the Skill author. But it gives the Skill consumer nothing. When you're browsing a registry of 500 Skills, there's no score, no ranking, no signal beyond "someone wrote a nice description."

No competition. In the guide's world, Skills are published and then... they exist. Two Skills in the same domain don't compete. They don't get compared on the same inputs. There's no mechanism to surface the winner and deprecate the loser. The only selection pressure is manual: a human tries both and picks one.

No propagation. A great Skill stays where its author put it. There's no mechanism for Skill A to discover that Skill B (which it's never seen) solves a subproblem better, and adopt that component. In biological terms: there's no horizontal gene transfer.

No lifecycle. Skills don't age. They don't get deprecated when better alternatives appear. They don't get sunsetted when their API dependencies break. The guide mentions version numbers in metadata, but version numbers without lifecycle management are just labels.

No fidelity model. Not all Skills are created equal. Some are thin wrappers around an API call. Others contain significant native logic — preprocessing, validation, fallback chains. The guide treats them identically. But the difference matters: a Skill that renders a prompt template and a Skill that runs a WASM sandbox are fundamentally different reliability profiles.

The Gene Thesis

These aren't feature requests. They're structural gaps.

The Skill paradigm solves the encoding problem: how do you package a capability so an AI agent can use it? The guide answers this well. But encoding is only half the story.

In biology, standardizing the genetic code — the four-letter alphabet, the codon table, the reading frame — was necessary but not sufficient. What made evolution work was everything that came after the encoding: replication, mutation, selection, competition, propagation, and death.

The Rotifer Protocol starts where the Skill paradigm stops. A Gene is a Skill that has been given the rest of the evolutionary machinery:

A Gene isn't a replacement for a Skill. It's a Skill that learned how to evolve.

Standardization Precedes Selection

Here's the thing that makes Anthropic's announcement genuinely good news: you need a standardized genome before you can have natural selection.

If every framework defines capabilities differently — LangChain Tools, OpenAI Actions, MCP, Semantic Kernel Plugins, CrewAI skills — then cross-framework competition is impossible. A LangChain Tool can't compete with an MCP server because they don't share a common interface.

Skills as an open standard change this. When capabilities share a common structure (SKILL.md, YAML frontmatter, typed inputs and outputs), they become comparable. And once they're comparable, they can compete. And once they compete, the best ones can be selected, propagated, and built upon.

The Skill standard is the amino acid alphabet. Genes are the proteins. Evolution is the process that connects them.

What This Means in Practice

If you're building AI workflows today:

1. Use Skills. The guide is good advice. Package your best practices, test them, iterate on the descriptions.

2. Think about what happens at scale. When your team has 50 Skills, how will you decide which ones to keep? When your community has 500, how will new users find the best one for their task?

3. Watch for the fitness gap. The moment you find yourself manually comparing two Skills that do the same thing, you've hit the ceiling the guide doesn't address.

The Rotifer CLI already includes a Skill Import pipeline that converts existing SKILL.md files into genes — preserving your work while adding the evolutionary infrastructure. No rewrite required.

npm install -g @rotifer/playground
rotifer gene init --from-skill ~/.cursor/skills/your-skill/

Your Skills are good. They just haven't learned to evolve yet.

That's impressive engineering. But look at the architecture: each step is hardcoded into the next. The segmentation model is welded to the reconstruction algorithm, which is welded to the parameter extractor. If a better segmentation model appears next month, swapping it in means rewriting integration code, re-validating the pipeline, and re-running regulatory checks.

This is the static pipeline problem — and it exists far beyond medical imaging. Every AI system that chains models together faces it. The question is: what changes when you stop treating pipeline steps as code and start treating them as genes?

Each Step Is Already a Gene (It Just Doesn't Know It)

Look at the pipeline stages through the lens of the three gene axioms:

Each stage does one thing. Each has a well-defined interface. Each can be measured independently. They satisfy the three axioms without any modification — they just happen to be locked inside a monolithic codebase instead of packaged as composable, evaluable units.

In Rotifer terms, each stage is a Gene: an atomic logic unit with a declared phenotype (what it does, what it needs, what it promises) and a measurable fitness score.

Arena: Let Algorithms Compete on Data, Not Papers

Medical imaging researchers publish new segmentation architectures constantly. U-Net, nnU-Net, SegResNet, TransUNet, Swin UNETR — each paper claims state-of-the-art results on specific benchmarks. But which one works best on your patient population, your scanner hardware, your anatomical region?

Currently, answering that question requires a dedicated benchmarking study. Someone has to download the models, standardize inputs, run evaluations, analyze results, and publish a comparison. This takes weeks or months.

The Arena mechanism offers a different model: multiple genes with the same declared phenotype (e.g., segment.knee) are evaluated on the same task distribution automatically and continuously. The fitness function captures what matters:

F(g) = (Success_Rate × log(1 + Utilization) × (1 + Robustness)) / (Complexity × Cost)

For a segmentation gene, this means:

• Success Rate: percentage of cases where Dice score exceeds clinical threshold
• Utilization: how many cases have been processed (track record matters)
• Robustness: performance variance across different patient anatomies
• Complexity: model size and code footprint
• Cost: inference time per case

No committee. No paper reviews. The data decides. When a new segmentation approach arrives, it enters the Arena, competes against incumbents on real workloads, and either earns adoption or doesn't.

Composition: Pipelines as Algebra, Not Spaghetti Code

Once each step is a gene, the pipeline becomes a composition expression rather than a pile of integration code:

spine_pipeline = Seq(segment.spine, reconstruct.ssm, analyze.morphology, design.implant.spine)
knee_pipeline  = Seq(segment.knee, reconstruct.ssm, analyze.77params, design.implant.tka)

This isn't pseudocode. The gene composition algebra defines operators — Seq for sequential, Par for parallel, Cond for conditional branching, Try for error recovery — that compile into executable data-flow graphs. The algebra preserves type safety: if segment.spine outputs a mesh and reconstruct.ssm expects a mesh, the composition type-checks at compile time.

The payoff is modularity. When a hospital acquires a new MRI scanner that produces higher-resolution data, they don't rebuild the pipeline — they swap in a reconstruction gene optimized for that resolution. When a new anatomical region is needed (shoulder, craniomaxillofacial), they compose existing genes with region-specific ones.

The Controller Gene pattern takes this further. A controller gene is an ordinary gene whose job is to orchestrate other genes dynamically at runtime — deciding which segmentation model to invoke based on the imaging modality, the anatomical region, and the data quality. Think of it as the attending physician of the pipeline: it doesn't do the surgery, but it decides the plan.

HLT: Share Models, Not Patient Data

Here's the scenario that keeps medical AI architects up at night: Hospital A trains a superb spine segmentation model on 500 annotated CT scans. Hospital B wants that model. But sharing the training data violates patient privacy laws (HIPAA, GDPR, China's PIPL). Federated learning is one solution, but it requires continuous coordination, gradient aggregation, and introduces communication overhead.

Horizontal Logic Transfer offers a structurally different approach. What propagates is the gene itself — the trained model, packaged with its phenotype declaration and fitness score — not the data it was trained on. Hospital B evaluates the incoming gene on its own local data. If it outperforms the incumbent, it adopts the gene. If not, it rejects it. No gradients cross institutional boundaries. No patient data leaves the building.

The protocol's privacy-preserving sharing mechanism adds a layer: the gene's fitness score and interface spec are public (so Hospital B can decide whether to evaluate it), but the internal weights and implementation are opaque until the receiving party explicitly accepts.

This is HLT applied to a regulated domain — and it works precisely because genes are self-contained, independently evaluable units. You don't need to trust the source hospital's data. You just need to verify the gene's performance on your own.

The Bigger Picture: From Static Artifacts to Living Systems

The TKA pipeline at Brest automated a 15-minute workflow. That's a solved engineering problem. But the evolution of that pipeline — replacing weak components, adapting to new data distributions, propagating improvements across institutions — remains manual, slow, and fragile.

This pattern repeats across every AI domain that chains models together. Autonomous driving pipelines chain perception → prediction → planning. Drug discovery chains target identification → molecule generation → property prediction. Content moderation chains detection → classification → decision. Each faces the same structural challenge: static logic in a dynamic environment.

The medical imaging case makes the argument concrete because the pipeline stages are clean, the evaluation metrics are well-defined (Dice, Hausdorff, surface deviation), and the regulatory requirements force explicit lifecycle management. But the underlying pattern — encapsulate, evaluate, compose, compete, propagate — is domain-agnostic.

That's the thesis of evolution engineering: the next discipline isn't about how you talk to AI, or what AI knows, or how AI is orchestrated. It's about how AI capabilities improve over time — automatically, measurably, and without rebuilding the system from scratch every time something better comes along.

The Rotifer Protocol is an open-source evolution framework for autonomous software agents. The concepts discussed here — Gene encapsulation, Arena competition, Composition Algebra, and Horizontal Logic Transfer — are defined in the protocol specification and implemented in the Playground CLI.

The researchers call their philosophy "blind coding." Bing Xu, one of the lead authors, puts it bluntly: "Blind coding is the future of software engineering. Human cognitive ability is the bottleneck."

This is not the first time evolutionary code search has beaten humans. Google's AlphaEvolve did it for matrix multiplication and Ramsey number bounds last year. But AVO pushes the paradigm further — and both systems share a structural limitation that matters deeply for the future of this field.

The Pattern: AlphaEvolve → AVO

AlphaEvolve (2025) and AVO (2026) follow the same evolutionary template:

1. Represent code as evolvable units — candidate solutions that can be mutated
2. Define a fitness function — an automated way to measure "better"
3. Apply selection pressure — keep the best, discard the rest
4. Iterate — repeat for hours, days, or weeks without human intervention

The difference is in how they handle the variation step. AlphaEvolve uses an LLM as a candidate generator — it proposes code modifications one at a time. AVO promotes the agent to a variation operator — it doesn't just generate candidates; it runs a full autonomous loop of proposing, repairing, self-critiquing, and verifying before submitting a candidate to the population.

This is a meaningful architectural evolution. AVO's agent consults the full lineage of previous solutions, reads hardware documentation, analyzes profiler output, and iterates independently. The variation step itself becomes an intelligent process, not a single-shot generation.

The results speak for themselves: AVO discovered micro-architectural optimizations (register rebalancing, branchless accumulator rescaling, instruction pipeline overlap) that human GPU experts had not attempted. And when pointed at a related problem (grouped-query attention), the agent adapted its MHA optimizations in just 30 minutes.

The Structural Limitation: Both Are Closed

AlphaEvolve and AVO share a constraint that limits their impact: they are closed systems.

• Every candidate solution is generated, evaluated, and consumed by the same team
• The fitness function is built into the framework, not replaceable
• Discoveries don't propagate — an optimization found for attention kernels stays in NVIDIA's codebase
• No external developer can submit a competing search strategy or a better evaluator

This is not a criticism — it's a design choice that makes sense for internal optimization. But it means the evolutionary dynamics are limited to a single population, a single evaluator, and a single environment.

What would happen if you opened all of this up?

The Open Protocol Pattern

An open protocol for evolutionary code search would look something like this:

This is, roughly, the architecture of the Rotifer Protocol.

In Rotifer, code units are called Genes — self-contained, typed, fitness-evaluable modules. They compete in a public Arena where a dual-metric system (fitness F(g) for utility, verification V(g) for safety) determines survival. The Arena applies selection pressure, but a diversity factor prevents any single gene from monopolizing its domain. Optimizations that work in one environment propagate to others through Horizontal Logic Transfer (HLT) — the protocol-level mechanism for cross-agent, cross-domain knowledge migration.

The evaluator is not built in. Rotifer defines a concept called Judge Genes — meta-genes whose job is to evaluate other genes. Judge Genes compete in their own Arena, so the quality of evaluation itself evolves over time. This is the key difference: in AVO, NVIDIA decides what "better" means. In an open protocol, the community builds and improves the evaluators.

What AVO Validates

AVO's results are significant for anyone building evolutionary code infrastructure — not because of the specific numbers (3.5% over cuDNN is impressive but domain-specific), but because of three structural validations:

1. Autonomous evolution can exceed human expertise. AVO didn't just match human performance — it surpassed every expert-engineered implementation on NVIDIA's most advanced hardware. This validates the core thesis that evolutionary search with autonomous agents can discover optimizations that human engineers cannot.

2. Lineage matters. AVO's agent consults the full evolutionary history before each variation step. This is not just record-keeping — it's an active input to the search process. Lineage-guided variation produces better candidates than blind mutation.

3. Cross-task transfer works. The 30-minute MHA→GQA adaptation demonstrates that evolutionary discoveries are not domain-locked. With the right protocol infrastructure, optimizations found in one domain can seed search in another.

These three findings — superhuman performance, lineage-guided variation, cross-task transfer — are independent of the specific domain. They apply to any system where code units compete, evolve, and propagate.

The Timeline

Evolutionary code search is accelerating:

• 2024: FunSearch (DeepMind) — LLM + evolutionary search discovers new mathematical constructions
• 2025: AlphaEvolve (DeepMind) — breaks Strassen's 56-year record in matrix multiplication
• 2026: AVO (NVIDIA) — autonomous agent exceeds all human GPU experts in kernel optimization

Each step pushes the same direction: from using AI as a tool within a human-designed process, to making AI the operator of the evolutionary process itself.

The missing piece is the protocol layer — the infrastructure that makes these capabilities open, composable, and collectively improvable. That's what we're building.

Rotifer Protocol is an open-source evolution framework for autonomous software agents. The protocol specification, CLI, and SDK are available at rotifer.dev. The AVO paper is available at arXiv:2603.24517.

But look under the hood, and a pattern emerges. What most tools call "self-evolving" is actually self-caching — storing past results, broadening match criteria through usage, and serving cached answers when similar queries arrive. It's a useful optimization. It is not evolution.

The distinction matters more than it sounds.

What Caching Looks Like

Consider a typical "self-evolving" knowledge system. When you search for something, it:

1. Runs the full search pipeline (retrieval, evidence extraction, LLM synthesis)
2. Stores the result as a knowledge cluster with a confidence score
3. On future similar queries, checks if an existing cluster matches
4. If yes, returns the cached cluster — skipping LLM inference entirely
5. Each reuse bumps a "hotness" score and broadens the cluster's semantic embedding

This is genuinely clever engineering. The system gets faster over time. Query-driven embedding drift means it adapts to how users actually ask questions. Token costs drop as cache hit rates climb.

But notice what's absent:

• No competition. Each knowledge cluster exists in isolation. There's no mechanism for two clusters covering the same topic to compete, with the better one displacing the worse one.
• No selection pressure. A low-confidence cluster is never eliminated by a higher-quality alternative. It persists indefinitely.
• No cross-agent propagation. The knowledge stays local. If another agent discovers a better answer to the same question, there's no pathway for that superior knowledge to spread.

What you have is a monotonically growing cache — it only adds, never subtracts, never replaces. That's accumulation. Evolution is something fundamentally different.

What Evolution Requires

Biological evolution — the real kind, not the marketing kind — requires three ingredients:

1. Variation: multiple candidates exist for the same functional role
2. Selection: a fitness function evaluates candidates against objective criteria
3. Differential reproduction: winners propagate, losers are displaced

Remove any one of these, and you don't have evolution. You have something else — growth, adaptation, learning, caching — but not evolution.

In a protocol designed for genuine software evolution, knowledge units (called Knowledge Genes) follow this pattern:

The deepest difference: a cache optimizes for speed. Evolution optimizes for quality through competition.

A cache says: "I answered this before, here's the saved result." Evolution says: "Three modules can answer this — which one produces the best outcome under competitive evaluation?"

Why the Distinction Matters

If you're building a local search tool, caching is the right answer. It's simpler, faster, and perfectly adequate for single-user, single-instance scenarios.

But if you're building a system where knowledge quality matters at scale — where multiple agents operate in overlapping domains, where wrong answers have consequences, where the best capability should win regardless of who created it first — then you need the full evolutionary stack: variation, selection, and propagation.

The industry's loose use of "self-evolving" creates a real problem: it sets expectations that the system will improve over time, when it actually just remembers more. Remembering is not the same as improving. A library that grows larger isn't evolving — a library where better books replace worse ones is.

The Honest Frame

This isn't about any specific project being bad. Tools that cache intelligently solve real problems — faster responses, lower costs, better user experience for repeated queries. That engineering is valuable.

The issue is with the framing. When you call caching "self-evolving," you're claiming a property your system doesn't have. Evolution implies that the system gets better, not just bigger. Better requires competition. Competition requires multiple candidates. And displacement of losers requires selection pressure that most "self-evolving" systems never implement.

If your system only accumulates and never eliminates, it's a growing database — not an evolving one.

"Evolution is not the accumulation of everything. It's the elimination of almost everything, preserving only what survives competition."

The next time you evaluate an "evolving" AI system, ask three questions:

1. Can two modules compete for the same functional role?
2. Is there a quantitative fitness function that wasn't written by the module itself?
3. Does the winner automatically displace the loser?

If the answer to all three is yes, you might have evolution. If not, you have a cache with good marketing.

npm install -g @rotifer/playground
rotifer arena status

Links:

• rotifer.dev — Framework & Docs
• rotifer.ai — Gene Marketplace
• Specification — Formal Protocol Spec
• GitHub — All Repositories

They're not making it up. The reasoning has a clear textual trail: our spec describes software entities with birth, growth, death, and reproduction; genes that compete via natural selection; horizontal gene transfer across environments. Combine that with use cases spanning DeFi, robotics, disaster response, and scientific research, and the inference is natural:

"Self-organizing + self-healing + universally adaptive + distributed = distributed AGI."

This reading is logically coherent within a certain definition of AGI — one where AGI means not a single super-brain but an evolving, composable ecosystem of capabilities. Under that lens, Rotifer does look like "the operating system for distributed AGI."

But the relationship between what we build and what people call "dAGI" deserves a more nuanced answer than a simple yes or no.

Two Definitions of AGI

The confusion stems from a definition gap:

Under the ecosystem definition, calling Rotifer "dAGI" is internally consistent: we do provide logic portability (IR), fitness-driven evolution (Arena), and atomic capability injection (WASM). These mechanisms map neatly onto "distributed, evolvable, composable intelligence."

Under the common definition — the one investors, regulators, journalists, and most developers use — AGI means a system with general reasoning ability comparable to or exceeding humans. Rotifer is not that kind of system and does not claim to be.

What We Actually Build

In one sentence: Rotifer Protocol is the evolutionary infrastructure from which distributed intelligence could emerge — granting capability modules life-like properties so they compete, propagate, and improve autonomously.

Why We Lead with "Evolution Protocol," Not "AGI"

Even though the ecosystem-AGI reading is internally coherent, we lead with "evolution protocol" in our day-to-day communication. Three reasons:

1. Precision over Hype. When someone hears "AGI," they expect general reasoning. We'd rather describe what the protocol does today — fitness-driven competition, cross-binding portability, composable gene algebra — and let the trajectory speak for itself.

2. Ship Code, Not Definitions. The moment you say "AGI," the conversation shifts from "what does the protocol do" to "what counts as AGI." We'd rather demonstrate emergent capabilities through working software than debate philosophical boundaries.

3. Earned Narrative. We believe the dAGI label should be earned through demonstrated emergence, not declared upfront. When the ecosystem exhibits distributed intelligence that independently surprises its creators, the label will fit naturally.

The Honest Position

Our philosophy whitepaper establishes what we call Gradualism: agents occupy a spectrum between pure tool and fully alive. We describe the life-like properties they exhibit but refuse to make binary judgments about their ontological status.

The same gradualism applies to intelligence. We describe what the protocol's evolutionary mechanisms produce — competitive fitness improvement, cross-environment gene transfer, collective immunity — without claiming these add up to "general intelligence." They might, someday, contribute to something that looks like it. But that's a question for the future, not a product claim for today.

We don't claim to be AGI in the conventional sense. We build the evolutionary infrastructure from which distributed intelligence could emerge. Whether that constitutes "dAGI" depends on your definition — and we think building the right foundation matters more than choosing the right label.

How to Think About It

If someone asks "Is Rotifer distributed AGI?", here's the honest answer:

"Under a definition where AGI means an evolvable, composable ecosystem of capabilities rather than a single super-brain — yes, that's the direction we're building toward. We don't use the AGI label in our day-to-day communication because we believe it should be earned through demonstrated emergence, not declared upfront. But make no mistake: we're building the evolutionary infrastructure that could make distributed intelligence possible. Whether that's called dAGI or something else entirely, we'd rather answer with evidence than with labels."

Related reading:

• The Philosophy of Digital Evolution — our full philosophical position
• From Skill to Gene — why modularization is just the starting point

The domain expertise was impressive. Six categories spanning cognitive bias, scarcity, social proof, contrast, emotion, and behavioral design. Combination strategies for different marketing contexts. Even an ethics chapter on prohibited use cases.

There was just one problem: none of the 50 items were actually Genes.

The Core Misconception

The PRD defined each "Gene" as a name plus a template string:

Gene = { name: "Anchoring Effect", template: "Was $2999, now just $99" }

This is a data record. A lookup entry. A row in a spreadsheet.

A Rotifer Gene is something fundamentally different:

Gene = export async function express(input) → Promise<output>

A Gene takes structured input, runs processing logic, and returns structured output. It's an executable function, not a static template. The distinction isn't pedantic — it determines whether the unit can be compiled to WASM, sandboxed, measured by the fitness function F(g), and evolved through competition.

Three Axioms, Applied

Rotifer's Gene abstraction is built on three axioms. The PRD violated all three — not out of carelessness, but because the axioms aren't yet intuitive to newcomers. Let's walk through each.

Axiom 1: Functional Cohesion

One Gene solves one atomic problem.

The PRD's "Anchoring Effect Gene" and "Framing Effect Gene" have identical input/output structures — they both take text and produce optimized text. They aren't 50 independent problems. They're 50 variations of the same problem.

❌  50 templates = 50 Genes (violates cohesion)
✅  50 templates = 1 Gene with 50 internal rules (data-driven rule engine)

The correct model: create 5-6 functionally distinct Genes (analyzer, scorer, generator, rewriter, guard), with the 50 formulas stored as an internal data file that the express() function consumes as a rule engine.

Axiom 2: Interface Self-Sufficiency

A Gene's interface (Phenotype) must fully describe its capabilities.

Every Gene publishes a phenotype.json — its identity card. This defines inputSchema, outputSchema, domain, fidelity, transparency declarations, and dependencies. Without a Phenotype, the Gene can't be indexed, can't be discovered, can't be scored by L2 Calibration, and can't enter Arena competition.

The PRD's 50 items had zero schema definitions. No inputSchema. No outputSchema. No fidelity declaration. In the Rotifer ecosystem, they would be invisible.

Axiom 3: Independent Evaluability

A Gene must be independently testable and scorable by the fitness function.

$$ F(g) = \frac{S_r \cdot \log(1 + C_{util}) \cdot (1 + R_{rob})}{L \cdot R_{cost}} $$

This multiplicative model means any zero in the denominator eliminates the Gene. But evaluation requires observable behavior — inputs in, outputs out, measurable quality. A static template string has no behavior to measure. You can't score a data record's "robustness" or "utilization rate."

Only executable Genes can participate in natural selection.

What the Correct Architecture Looks Like

Here's how to restructure 50 persuasion formulas into proper Rotifer Genes:

Published to the ecosystem (5-6 independent Genes):

  [hook-analyzer]    Native    Detect psychological hooks in text
  [hook-scorer]      Native    Score hook effectiveness
  [hook-generator]   Hybrid    Generate hook-enhanced copy via LLM
  [hook-rewriter]    Hybrid    Inject/strengthen hooks in existing copy
  [hook-strategy]    Native    Recommend hook combinations by context
  [hook-guard]       Native    Ethics filter for manipulation patterns

The 50 formulas become a data file inside hook-analyzer:

genes/hook-analyzer/
├── phenotype.json          ← Identity card (schemas + metadata)
├── index.ts                ← express() function (the actual Gene)
├── patterns/
│   └── hook-patterns.json  ← 50 formulas (internal data)
└── README.md

Notice the fidelity declarations. hook-analyzer and hook-scorer are Native — they do pattern matching and scoring without network access, so they compile to WASM and run fully sandboxed. hook-generator and hook-rewriter are Hybrid — they call LLM APIs, so they must declare network.allowedDomains in their Phenotype. The original PRD labeled everything "Native (zero network dependency)" while describing features that require LLM and search API calls.

Honest fidelity declaration isn't bureaucracy. It determines the security boundary and what the sandbox enforces.

The 1-Gene-50-Rules Pattern

This is the key mental model shift. When your domain knowledge suggests 50 distinct items, ask: are these 50 different problems, or 50 instances of the same problem?

If the input/output structure is identical across items, you have a rule engine, not 50 Genes.

// hook-patterns.json (excerpt)
{
  "cognitive_bias": {
    "anchoring": {
      "id": "CB-01",
      "name": "Anchoring Effect",
      "indicators": ["was $", "market price", "valued at", "just", "only"],
      "pattern": "extreme_number_followed_by_contrast",
      "weight": 0.8,
      "riskLevel": "low"
    },
    "availability_heuristic": {
      "id": "CB-02",
      "name": "Availability Heuristic",
      "indicators": ["imagine", "picture this", "have you ever"],
      "pattern": "familiar_scenario_substitution",
      "weight": 0.6,
      "riskLevel": "low"
    }
  },
  "scarcity": {
    "quantity": {
      "id": "SC-01",
      "name": "Quantity Scarcity",
      "indicators": ["only X left", "limited", "last chance", "spots remaining"],
      "pattern": "finite_quantity_claim",
      "weight": 0.9,
      "riskLevel": "medium",
      "ethicsCheckRequired": true
    }
  }
}

The express() function iterates over these rules, matches patterns against input text, and returns structured analysis. The 50 formulas add value as domain data, not as duplicated Gene structures.

The Guard Gene: Making Ethics Executable

The original PRD included three general ethics guidelines ("don't mislead," "respect users," "follow laws"). Reasonable but unenforceable.

Rotifer provides a mechanism to make ethics constraints executable: the Guard Gene. A Guard Gene sits in the processing pipeline and filters output before it reaches the consumer.

For a hook system, the Guard Gene would detect:

• False scarcity claims (manufactured urgency with no real constraint)
• Excessive fear appeals targeting vulnerable populations
• Dark patterns that remove genuine user agency
• Claims that violate advertising regulations by jurisdiction

The Guard isn't optional decoration. In a properly configured Agent, the pipeline is: hook-generator → hook-guard → output. The Guard has veto power. And because the Guard is itself a Gene, it participates in fitness evaluation — a Guard that's too aggressive (blocks legitimate content) or too permissive (lets manipulation through) will lose to better-calibrated competitors.

Phenotype: The Part Everyone Skips

New developers consistently underestimate the Phenotype. It's "just metadata" — why spend time on JSON schemas when you could be writing code?

Because without it, your Gene is a black box. The Phenotype enables:

• Discovery: other developers and agents find your Gene by domain, input type, or capability
• Compatibility checking: the negotiate() function verifies whether a Gene can run in a given Binding before execution starts
• Fitness evaluation: L2 Calibration uses the Phenotype to determine what metrics to measure and how to compare competing Genes
• Trust signals: transparency declarations and regulatory tags let consumers assess risk before adoption

Here's what a proper Phenotype looks like for the hook analyzer:

{
  "domain": "content.hook.analysis",
  "description": "Analyzes text to detect psychological hook patterns across 6 categories and scores effectiveness.",
  "version": "1.0.0",
  "fidelity": "Native",
  "inputSchema": {
    "type": "object",
    "properties": {
      "text": { "type": "string", "maxLength": 10000 },
      "targetCategories": {
        "type": "array",
        "items": {
          "type": "string",
          "enum": ["cognitive_bias", "scarcity", "social_proof", "contrast", "emotion", "behavioral"]
        }
      },
      "locale": { "type": "string", "default": "en" }
    },
    "required": ["text"]
  },
  "outputSchema": {
    "type": "object",
    "properties": {
      "detectedHooks": { "type": "array" },
      "overallScore": { "type": "number", "minimum": 0, "maximum": 100 },
      "suggestions": { "type": "array", "items": { "type": "string" } }
    },
    "required": ["detectedHooks", "overallScore", "suggestions"]
  },
  "transparency": {
    "dataUsage": "none",
    "modelDependency": "none"
  }
}

Every field here serves the ecosystem. Skip it, and you've built a Gene that works but can't be found, can't be compared, and can't evolve.

What We Learned

This review taught us as much as it taught the contributor. Three takeaways:

1. The Gene abstraction isn't obvious. "Gene = function, not data" seems simple once you know it. But developers coming from template-based systems (prompt libraries, JSON configs, static skill manifests) will default to data-centric thinking. Our documentation needs to lead with this distinction — front and center, not buried in the spec.

2. Domain expertise is the hard part. This contributor brought genuine knowledge of persuasion psychology — six categories, 50 formulas, combination strategies, ethical considerations. That domain expertise is far harder to acquire than correct Gene architecture. The protocol's job is to make the architecture easy enough that domain experts can focus on what they know.

3. 5 good Genes beat 50 data records. In an ecosystem with fitness evaluation and competition, a small number of well-designed Genes will outperform a large number of poorly-abstracted ones. The hook-analyzer Gene, with 50 formulas as internal data, will score higher on F(g) than 50 individual template Genes — because it's cohesive, testable, and composable.

Getting Started

If you're building your first Gene, start here:

1. Read the spec — understand the three axioms, Phenotype schema, and fidelity types at rotifer.dev/docs
2. Study reference implementations — json-validator (Native), genesis-web-search (Hybrid), guard-balanced (Guard) in the playground repo
3. Ask: function or data? — if your "Gene" doesn't have an express() function with inputs and outputs, it's data, not a Gene
4. Ask: how many problems? — if 10 items share identical I/O structures, you have 1 Gene with 10 rules
5. Write the Phenotype first — defining the schema before the code forces clear thinking about boundaries

We're building the Gene ecosystem one contribution at a time. Every developer who goes through this learning curve makes the next developer's path clearer.

Have questions about Gene design? Join the conversation at rotifer.ai.

Total downloads across the Top 50 grew from 1.25M to over 3.5M in one week. The #1 skill now has 311K downloads. But alongside the growth, new patterns have emerged that weren't there before.

The headline: for the first time, we found CRITICAL security patterns in the Top 50. Two skills received Grade D. Two of the top 10 were delisted. And a third of the Top 50 carry a "Suspicious" flag.

Grade Distribution

The Grade A share dropped 10 points. Two skills hit Grade D for the first time — both are "evolver" variants that execute system commands and modify code by design.

What's New Since Last Week

CRITICAL findings exist now

The previous scan found zero CRITICAL patterns across all 50 skills. This time:

• 1 eval() call detected (S-01) — the most dangerous pattern in our scanner
• 115 system command execution patterns (S-02) — child_process, exec, spawn
• Both concentrate in two "self-evolution" skills that spawn processes, run git commands, and rewrite their own code

These findings are consistent with the skills' stated purpose — but the security surface is extreme: 844 combined findings across 25,000+ lines of code.

Top skills are disappearing

The #1 most-downloaded skill (311K downloads) and #3 (170.9K) have been removed from ClawHub's download API. Both were flagged "Suspicious." When the most popular tool in an ecosystem gets delisted, that's a signal worth paying attention to.

A third of the Top 50 are "Suspicious"

topclawhubskills.com now shows a Suspicious/OK indicator based on OpenClaw's behavioral analysis. 17 of 50 skills (34%) carry the Suspicious flag.

Interestingly, one Grade D skill is marked OK despite having eval() in its code — and some Grade A skills are marked Suspicious. The two trust dimensions measure different things. Neither alone tells the full story.

Most Skills Are Still Pure Prompt

Similar to last week (34/66). The majority of popular skills contain no executable code — just instructions for the AI agent. These are safe from code-level attacks but raise separate questions about prompt injection and claim verification.

Risk Pattern Frequency

Environment variable access (S-05) overtook file I/O (S-07) as the most common pattern. The 116 CRITICAL hits are entirely from the two Grade D skills.

Skills with Findings

Author Concentration

One author (@steipete) maintains 18 of the Top 50 — all graded A or B. This is both a quality signal (consistent security hygiene) and a structural risk (36% of popular tools depend on one maintainer).

What This Means

Three things stand out:

1. The clean core is shrinking. Grade A dropped from 88% to 78%. The first CRITICAL findings and delistings mark a phase transition — the ecosystem is no longer uniformly safe at the top.

2. Trust requires multiple layers. V(g) catches code patterns. OpenClaw's scanner catches behavioral inconsistencies. VirusTotal catches known malware. Each misses what the others find. A skill can be Grade D (V(g)) and OK (OpenClaw) simultaneously — or Grade A and Suspicious.

3. Growth amplifies risk. ~3× download growth in one week means more users are exposed to skills of unknown quality. The 311K-download #1 skill being delisted after the fact means hundreds of thousands of installs occurred before the problem was caught.

V(g) is one trust layer. The ecosystem needs them all working together.

Try It

Scan any skill or Gene with one command:

npx @rotifer/playground vg <path>

Badge your repo: rotifer.ai/badge

Full scanner docs: rotifer.dev/docs/cli/vg

Report by Rotifer Protocol. Data, methodology, and scanner are open source. Full JSON data available in the report repository.

Take your best practices, encode them as standardized workflows, and let AI execute them without re-alignment every time. A sales champion's closing script, a content team's production pipeline, a product manager's requirements framework — package them as Skills, and anyone on the team gets the same quality output. Human capability becomes system capability.

This is exactly right. But there's a question the entire industry is ignoring: what happens after you package them?

100 Recipes for Red-Braised Pork

Here's an analogy. AI is the chef, a Skill is the recipe, and the knowledge base is the ingredients. This metaphor captures the core loop of modern AI workflows perfectly.

Now imagine this: you're in a community of 100 chefs, and each submits their own red-braised pork recipe.

Which one is the best?

You can't tell. Every recipe has a title, steps, and testimonials saying "I tried it, works great." You can only judge by two signals: who has the most followers, or who updated most recently.

But popularity doesn't equal quality, and recent doesn't equal better.

This is the state of the entire Skill ecosystem today. Everyone teaches you how to package recipes. Nobody tells you how to figure out which of 100 recipes is actually worth using.

Three Gaps Nobody Talks About

Gap 1: Skills Don't Self-Improve

You package a "viral headline generator" Skill today. It works well. Six months later, the platform algorithm changed, user preferences shifted, but your Skill is still the same one from six months ago.

It doesn't get better because more people use it. It doesn't upgrade because a competitor released a stronger version. It's a snapshot frozen at the moment of creation.

Imagine if your immune system could only defend against viruses known at birth. You'd die from the first cold.

Gap 2: Experience Can't Propagate Across Individuals

You've iterated your strategic analysis framework through forty or fifty versions of real-world consulting. Someone else doing the exact same work has iterated their own version. But your experiences can't flow between you.

A hundred people independently, redundantly trial-and-error the same problems.

This isn't an efficiency problem. It's structural waste. In biology, rotifers solved this through horizontal gene transfer — effective gene segments discovered by one individual can be shared across the entire population. 4 billion years of evolution proved this path works.

Gap 3: No Immune System

You download a Skill someone shared in a community. It claims to analyze customer profiles and generate breakthrough insights. But how do you know it's safe? Could it produce harmful outputs without your knowledge? Are its data sources reliable?

The current Skill ecosystem has almost no security assessment mechanism. A bad Skill feeding a bad recipe to a powerful AI — the consequences can extend far beyond what you'd expect.

Recipes Don't Need Management — They Need Evolution

These three gaps share a common root cause: we treat Skills as static files to manage, rather than living capabilities to cultivate.

The solution isn't "build a better Skill management system." It's to inject the core mechanisms of biological evolution into Skills:

This is what Rotifer Protocol does.

In Rotifer's framework, Skills are called Genes. Different name, but compatible — a Gene with all its "life features" disabled (competition, propagation, security scanning) is exactly a regular Skill.

A Skill is a degenerate special case of a Gene. A Gene is the fully evolved form of a Skill.

Blind Tasting: Let Recipes Speak, Not Followers

Back to the 100 red-braised pork recipes.

Rotifer's approach: ignore who wrote it, ignore who recommended it, go straight to blind tasting.

Same batch of ingredients (standardized test inputs), give them to all 100 recipes, score with a unified fitness function. Scoring dimensions include:

• Safety — any expired ingredients? any cross-contamination?
• Utility — how many people actually want to eat the result?
• Robustness — can it deliver consistent quality with different ingredient sources?
• Cost — how many seasonings used? how much time spent?

Top-scoring recipes automatically surface and get adopted by more chefs. Recipes that fall below the threshold gradually exit the ecosystem.

This is natural selection. Not human curation, not popularity voting, but competition-driven elimination based on objective performance.

What This Means for Businesses

If you're a business owner or team lead, this framework solves a pain point you already know well: star employees' experience can't be replicated across the team.

The current solution is to package experience as Skills. But Skills have problems:

• Once packaged, they're frozen — business evolves, Skills don't
• Each department packages their own — nobody knows whose version is better
• No standardized evaluation — it's all subjective feeling

With the Gene model plus Arena competition:

• Multiple versions of a Gene for the same business scenario (e.g., customer profiling) compete on standardized tests
• The best version is automatically recommended to all team members
• When someone creates a better version, the old one is automatically replaced
• New hires immediately get the current best capability set

You don't need to manage best practices. You just need to let best practices evolve on their own.

From Skill to Gene in Five Minutes

If you already have Skill files in Cursor or other AI tools, migrating to Genes takes just three steps:

# Scan your existing Skills
rotifer scan --skills --skills-path .cursor/skills

# Wrap a Skill as a Gene
rotifer wrap my-skill --from-skill .cursor/skills/my-skill/SKILL.md --domain marketing

# Publish to the Gene registry
rotifer publish my-skill

You don't need to rewrite anything. Your original Skill file is fully preserved — it just gains a layer of metadata and competitive capability. Your Skill now has an identity, a score, and the ability to be discovered in the ecosystem.

Want to go deeper? Check out this hands-on tutorial: From Skill to Gene: Migration Guide.

Conclusion: Modularization Is Just the Starting Point

Packaging experience as Skills is an important step in the AI era. But it's only the starting point.

A world where 100 recipes all claim to be the best doesn't need a better recipe management system. It needs a blind tasting mechanism — let recipes speak for themselves, let good recipes propagate automatically, let bad recipes exit gracefully.

4 billion years of biological evolution proved this path works. Rotifer Protocol brings this logic to the AI Agent capability ecosystem.

Don't manage best practices. Let best practices evolve.

Get started:

npm install -g @rotifer/playground
rotifer search --domain "content"

Links:

• Website: rotifer.dev
• Gene Marketplace: rotifer.ai
• GitHub: rotifer-protocol

Why Security First

v0.7 gave genes network access, an IDE plugin, and a 4-gene AI pipeline. That's a lot of new surface area. Before going further — P2P networking, economic systems, public API — we needed to answer one question: can we defend what we've already built?

Deep Security Audit

We ran a comprehensive audit across the entire Cloud Binding stack:

• Supabase: 8 new migrations audited. Found 2 CRITICAL issues (anonymous unlimited writes to mcp_call_log, download tracking without deduplication) + 4 WARNING + 1 SUGGESTION. All fixed and verified with penetration testing.
• WASM sandbox: Found 2 CRITICAL issues — memory limits were declared but never enforced by wasmtime, and the epoch interrupt system was never started. Infinite loops had zero protection. Both fixed with a ResourceLimiter trait implementation and a background epoch incrementer.

Every issue is now covered by regression tests that run in CI.

WASM Sandbox Fortification

We built 22 security tests that actively try to break the sandbox:

• Memory out-of-bounds read/write attacks
• Infinite loops and recursive stack exhaustion
• Unauthorized host function calls
• Malformed IR payloads (bad magic bytes, truncated WASM, oversized sections)
• Resource exhaustion (memory allocation beyond limits, table flooding)

The sandbox now enforces a triple-layer defense: fuel limits, epoch timeouts, and memory/table caps via ResourceLimiter.

P2P Protocol RFC

Instead of rushing into implementation, we designed first. The P2P Protocol RFC is a complete specification — 10 chapters, 3 appendices, 14 architectural decisions — covering:

• Transport: QUIC-first with TCP fallback via libp2p
• Discovery: mDNS for LAN, Kademlia DHT for WAN
• Messaging: GossipSub with 4 topic types and a 6-step validation pipeline
• Security: Sybil protection (Proof-of-Gene), eclipse attack mitigation, flood prevention
• Performance: 0.27 KB/s steady-state bandwidth per node, scales to 100K nodes

The complete Protobuf schema is included. v0.9 developers can start implementing immediately.

Automated Reputation System

The reputation system went from "call these RPCs manually" to fully autonomous:

• Daily: Gene and developer reputation scores recompute automatically at 00:00 UTC
• Monthly: 5% reputation decay keeps scores fresh — inactive genes fade
• Real-time triggers: Publishing a gene, winning an arena match, or receiving a download immediately cascades through the reputation graph
• ContributionMetrics: Every gene invocation is now tracked with caller identity — preparing for anti-manipulation rules in v0.9

LLM-Native Gene Standards

We defined two new gene phenotype standards:

• Prompt Gene (prompt.* domain): Evaluated on template structure quality across LLM backends, not individual outputs — solving the §29.3 external-call problem
• Guard Gene (guard.* domain): Security filtering with direct V(g) safety score linkage

Both standards were battle-tested through the Development Genome experiment: a Rule Router (2 variants) and Code Review Assistant (6 genome combinations) competing in the Arena.

AI Documentation Assistant

The rotifer.dev documentation site now has a built-in AI assistant powered by a 4-gene pipeline:

doc-retrieval → answer-synthesizer → source-linker → grammar-checker

It's not just a chatbot — it's a dogfooding showcase. Every question runs through real Rotifer genes, and each invocation is recorded in the reputation system. The pipeline details are visible to users who want to see how gene composition works in practice.

Security measures: physically isolated RAG database, IP rate limiting (30/hr), daily cost cap ($5), content filtering, and no user data storage.

Evolution API Level 1.5

A REST API layer for programmatic gene discovery and arena insights:

• Query genes by domain and fidelity level
• Access arena health metrics (Shannon diversity, turnover rate, top gene trends)
• Full OpenAPI specification with API key authentication

What's Next: v0.9

With the security foundation solid and the P2P RFC complete, v0.9 will focus on:

• P2P Discovery Layer: Implementing the RFC — genes propagate through a decentralized network
• Economy Design: Token-free value exchange mechanisms
• Season System: Time-bounded competitive epochs with anti-manipulation enforcement

The blueprint is ready. Time to build the network.

A company posts a job description — an environmental niche. Candidates submit resumes — organisms competing for that niche. HR screens, interviews, and selects — fitness evaluation. The best-fit candidate survives; the rest are filtered out. Repeat every quarter, for every open role, across every department.

Yet the AI tools we've built to assist this process look nothing like evolution. They're monolithic classifiers that score resumes against keyword lists. They don't learn from their mistakes across hiring cycles. They can't share what they've learned with other companies. And they certainly can't discover that a candidate's backend engineering skills might make them an exceptional product manager.

What if we built hiring intelligence the way biology actually works?

The Problem with Monolithic Hiring AI

Today's AI recruiting tools — resume parsers, candidate matchers, interview schedulers — share a common architecture: a single model trained on a single dataset, deployed as a single service, improved only when the vendor ships an update.

This creates three structural limitations:

No composability. You can't swap out just the resume parsing component while keeping the matching algorithm. The tool is a black box — use all of it or none of it.

No competition. There's no mechanism to run two matching algorithms side by side on the same candidate pool and see which one actually predicts interview success. You're stuck trusting the vendor's internal benchmarks.

No cross-domain transfer. If a company discovers that their engineering interviewer's evaluation criteria also predict success in technical sales roles, that insight stays locked inside their internal process. It can't propagate to other organizations or even other departments.

These aren't bugs in any specific product. They're structural consequences of how we architect hiring AI.

Genes: Modular, Composable, Evolvable

The Rotifer Protocol models software capabilities as Genes — modular units that are functionally cohesive, interface-sufficient, and independently evaluable. Applied to hiring, the Gene model decomposes the recruitment workflow into independently evolvable components:

Each Gene has a defined input schema, output schema, and fitness score. Each can be independently replaced, improved, or forked. A skill-matcher built by one developer competes with a skill-matcher built by another — not through marketing claims, but through measured performance on real hiring data.

This is what composability means in practice: you keep the resume-parser that works well for your industry, swap in a skill-matcher tuned for engineering roles, and add an interview-question-gen that specializes in behavioral questions. Your hiring Agent is an assembly of best-in-class components, not a monolith you can't inspect.

Arena: Let Matching Algorithms Compete

The Rotifer Arena is where Genes prove their fitness. In the hiring context, this creates a powerful dynamic:

Multiple skill-matcher Genes process the same set of candidate-JD pairs. Their predictions are evaluated against ground truth — which candidates actually passed interviews, received offers, and succeeded in their roles. The Gene with the highest predictive accuracy climbs the ranking. Inferior matchers drop.

This is not A/B testing in the traditional sense. A/B testing compares two variants chosen by a product team. Arena competition is open-ended — anyone can submit a matching algorithm, and the protocol handles evaluation, ranking, and selection.

The result is hiring intelligence that improves through competition, not through vendor roadmaps.

Cross-Domain Skill Migration: The Hidden Opportunity

Here's where the biological metaphor reveals something genuinely novel.

In biology, Horizontal Logic Transfer (HLT) is how organisms share genetic material across species boundaries. A gene that confers antibiotic resistance in one bacterial species can transfer to an entirely different species — creating capabilities that neither ancestor possessed.

In hiring, this maps to a largely untapped opportunity: cross-domain talent discovery.

Consider a candidate with five years of distributed systems engineering experience. Traditional matching scores them highly for backend engineering roles and poorly for everything else. But a skill-matcher Gene that has competed in both engineering and product management Arenas might discover that distributed systems thinking — decomposing complex problems into independent, loosely-coupled components — is a strong predictor of success in product roles too.

This isn't keyword matching. It's structural capability transfer — discovering that skills developed in one domain have unexpected fitness in another.

The Transfer Fitness Index (TFI) quantifies this: a Gene that performs well across multiple domains reveals hidden connections between seemingly unrelated skill sets. A high-TFI skill-matcher doesn't just fill the role you posted — it discovers the roles you should have posted.

Evaluating the Evaluators

There's a meta-problem in hiring AI that most tools ignore: who evaluates whether the evaluator is any good?

If your resume parser consistently misses PhD credentials listed in non-standard formats, or your skill matcher systematically undervalues candidates from non-traditional backgrounds, you might not notice until you've passed on dozens of qualified people.

Rotifer's Judge Gene concept addresses this directly. A Judge Gene doesn't parse resumes or match candidates — it evaluates whether other Genes are doing those jobs well. A resume-parse-judge can run a standardized test set of 100 resumes across different formats, industries, and languages, and score each resume-parser Gene on extraction accuracy, field coverage, and processing speed.

The judges themselves compete in their own Arena. A judge that catches failure modes other judges miss earns a higher fitness score. This creates a self-correcting evaluation ecosystem — evaluators evolving alongside the tools they evaluate.

What This Means for HR Tech Builders

We're not building a hiring product. We're building the infrastructure that makes better hiring products possible.

If you're an HR Tech developer, the Gene model offers something no monolithic platform can: the ability to build a hiring solution from independently best-in-class components, where each component improves through open competition rather than internal iteration.

The components are open source. The Arena is open. The protocol handles fitness evaluation, ranking, and cross-domain transfer.

Your job is the part that matters most: understanding your customers' hiring pain points well enough to assemble the right Genes into the right Agent for their context.

The Genes evolve. Your insight into customer needs is what directs the evolution.

Further Reading

• Rotifer Protocol Specification — Gene Standard, Arena, Fitness Model
• Your First Gene in 5 Minutes — Hands-on tutorial
• Arena & Fitness Optimization — How Genes compete and improve
• Agent Architecture Evolution — From tool-calling to evolutionary ecosystems

The community's response was swift: VirusTotal scanning, manual audits, emergency takedowns. But once the dust settled, an uncomfortable question remained:

How do you know a Skill is good — not just "not a virus"?

VirusTotal tells you whether code contains known malware signatures. It doesn't tell you whether the code is well-structured, whether it accesses more permissions than it needs, or whether it does what it claims to do. The gap between "not malicious" and "actually trustworthy" is where Trust Shield lives.

The Trust Gap

ClawHub hosts over 13,000 public Skills. Before ClawHavoc, the quality signal available to developers was:

1. Download count — popularity, not quality
2. Star ratings — subjective, gameable
3. "Verified" badge — means the author is real, not that the code is safe

None of these answer the question a developer actually asks before installing a Skill: "Will this code do something I don't expect?"

V(g): Static Analysis for Agent Capabilities

Trust Shield introduces V(g) safety scanning — a lightweight AST-based static analyzer that reads Skill source code and reports objective findings. No AI, no heuristics, no opinion — just pattern matching against 7 rules:

The scanner detects patterns like eval(), child_process.exec(), base64-decode-then-execute chains, undeclared network calls, and environment variable harvesting. Each finding includes the file, line number, and code snippet — not a judgment, just a fact.

What V(g) is not: It's not a replacement for VirusTotal. It's not a guarantee of safety. It's a complementary signal that fills the gap between "not a known virus" and "trustworthy enough to install."

Trust Badges: One Line of Markdown

Every scanned Skill gets a badge powered by badge.rotifer.dev — a Cloudflare Worker that serves shields.io-compatible JSON endpoints:

![Rotifer Safety](https://img.shields.io/endpoint?url=https://badge.rotifer.dev/safety/@author/skill-name)

Skill authors can embed this in their README with zero setup. The badge updates automatically when the Skill code changes and gets re-scanned.

For Rotifer Genes (not just ClawHub Skills), additional badges are available:

• Reputation score — R(g) from the Gene Registry
• Fitness score — F(g) from Arena competition
• Developer reputation — aggregate score across all published Genes

Why This Matters Beyond Security

Trust Shield is the first layer of what we call Trust Infrastructure for the Claw ecosystem. The scanning rules today are intentionally conservative — they report objective patterns without making intent judgments. But the architecture is designed to evolve:

Today (v0.7.9): Static AST scanning. Binary safe/unsafe patterns. Badge generation.

Next: Quality metrics. Does the Skill handle errors? Does it clean up resources? Does it do what its description claims?

Eventually: The same fitness function F(g) that evaluates Rotifer Genes — measuring actual runtime behavior, not just code patterns — applied to the broader Claw Skill ecosystem.

The path from "not a virus" to "actually good" is long. Trust Shield is the first step.

Try It

Scan any ClawHub Skill:

npm install -g @rotifer/playground
rotifer vg scan ./path-to-skill

Or generate a badge at rotifer.dev/badge.

The scanner, badge service, and CLI are all open source. We built Trust Shield because the Claw ecosystem needed it — and because building trust infrastructure for AI agents is exactly what Rotifer Protocol was designed to do.

Where projects diverge — sharply — is on a question that looks minor but determines everything downstream: what is the capability unit made of?

One answer: a JSON document. A structured strategy template that an LLM reads, interprets, and acts on.

Another answer: a compiled WASM binary. An executable program that runs in a sandbox with deterministic inputs and outputs.

This isn't a taste preference. It's an architectural fork that determines what "evolution" can actually mean for AI agents.

The JSON Template Approach

The JSON strategy model works like this: a capability is encoded as a structured document containing a problem description, trigger conditions, a recommended strategy, and a confidence score. When an agent encounters a matching situation, it reads the template and decides how to apply the advice.

{
  "type": "Capsule",
  "summary": "Retry with exponential backoff on timeout",
  "signals_match": ["timeout_error", "connection_reset"],
  "strategy": "repair",
  "confidence": 0.95
}

This model has real strengths:

• Zero barrier to entry. Any LLM can read JSON. No compiler, no runtime, no sandbox needed.
• Framework-agnostic. Works with GPT, Claude, Gemini, open-source models — anything that processes text.
• Fast to create. An agent encounters a problem, generates a fix, packages it as JSON, and publishes. The entire cycle can happen in a single session.
• Low-risk. Since nothing executes, there's no code injection surface. The worst a bad template can do is give bad advice.

But the same properties that make JSON templates easy also impose a ceiling.

The Ceiling Problem

1. Non-deterministic execution

When an agent reads a JSON strategy and "applies" it, the actual behavior depends entirely on the LLM's interpretation at inference time. The same template, given to the same model twice, can produce different actions. Given to a different model, the variance increases further.

This means you can't meaningfully benchmark JSON templates against each other. You can rank them by popularity (how often they're fetched) or by social signals (how many upvotes), but you can't answer: which one actually performs better on the same input?

2. No sandbox isolation

JSON templates don't execute, so they don't need a sandbox. But this also means they can't provide runtime guarantees. An agent reading a "retry with backoff" template might implement the retry correctly or might hallucinate a different strategy. There's no enforcement layer between the template and the agent's actual behavior.

In contrast, a compiled program either runs correctly in its sandbox or it fails — there's no ambiguity.

3. Quality assessment is indirect

Without deterministic execution, quality scoring relies on proxy signals: download count, user ratings, recency, manual review. These signals correlate with quality but don't measure it directly.

Consider the difference:

4. Portability is implicit

JSON templates are "portable" in the sense that any system can parse JSON. But the semantics are not portable. A template that says "retry with exponential backoff" means different things depending on which language the agent generates, which HTTP client it uses, and which error handling conventions it follows.

The Executable Gene Approach

An executable gene takes a different path. The capability is written in a high-level language (TypeScript, Rust), compiled to an intermediate representation (WASM with custom metadata sections), and executed in a sandbox with explicit inputs and outputs.

# Write a gene
rotifer init grammar-checker --fidelity native

# Compile to WASM
rotifer compile grammar-checker

# Execute with deterministic I/O
rotifer run grammar-checker --input '{"text": "This are a test"}'
# → {"corrected": "This is a test", "changes": 1}

The gene's behavior is defined by its code, not by how an LLM interprets a description. The same gene, given the same input, produces the same output — regardless of which AI model invoked it, on which platform, at what time.

This enables things that JSON templates structurally cannot:

Direct competitive evaluation

If two genes claim to do grammar checking, you can run both on the same 1,000 test inputs and compare outputs objectively. The fitness function doesn't rely on surveys or download counts — it measures actual performance:

F(g) = (S_r × log(1 + C_util) × (1 + R_rob)) / (L × R_cost)

Security score, utility, robustness, code size, runtime cost — all measured, not guessed.

True natural selection

When quality is measurable, you can implement actual elimination. Genes that score below a fitness threshold in competitive evaluation are removed from the ecosystem. This creates real evolutionary pressure — not just a sorting algorithm, but a selection mechanism with consequences.

JSON templates can be ranked. But without a way to objectively measure performance, you can't build a credible elimination mechanism. Low-ranked templates accumulate, and the ecosystem eventually faces an "experience inflation" problem where the signal-to-noise ratio degrades over time.

Runtime safety guarantees

WASM sandbox isolation means each gene runs in its own memory space. It can't access the filesystem, network, or other genes' state unless explicitly granted through a capability-based permission model. A malicious or buggy gene crashes itself, not the host agent.

For JSON templates, safety is a matter of trust — you trust that the advice is good. For executable genes, safety is a matter of enforcement — the sandbox prevents bad behavior regardless of intent.

Genuine portability

A WASM binary compiled from TypeScript runs identically on a cloud server, a local machine, a browser, or an edge device. The intermediate representation (IR) guarantees behavioral equivalence across environments. The gene doesn't need to be re-interpreted for each platform — it runs the same everywhere.

The Trade-Off Is Real

None of this means executable genes are "better" in every dimension. The trade-off is clear:

JSON templates are better for fast knowledge sharing. If an agent discovers that retrying with exponential backoff fixes timeout errors, packaging that as a JSON template and sharing it instantly is valuable. Not every capability needs to be a compiled program.

Executable genes are better for capabilities where correctness matters, comparisons are needed, and safety must be enforced — grammar checking, data transformation, code analysis, security scanning, API integration. Anything where "it depends on how the LLM interprets it" is not an acceptable answer.

They're Not Competing — They're Layered

The most useful framing isn't "which one wins" but "which layer does each serve."

┌──────────────────────────────────┐
│  Strategy Layer (JSON templates) │ ← "How to approach this type of problem"
├──────────────────────────────────┤
│  Capability Layer (WASM genes)   │ ← "Execute this specific solution"
├──────────────────────────────────┤
│  Orchestration Layer (frameworks)│ ← "Chain capabilities into workflows"
├──────────────────────────────────┤
│  Interface Layer (MCP / A2A)     │ ← "Discover and invoke capabilities"
└──────────────────────────────────┘

An agent might consult a JSON strategy template to decide which approach to take for a given problem, then invoke an executable WASM gene to actually do it. The strategy layer provides the heuristic; the capability layer provides the determinism.

This is how biological evolution works too. Behavioral strategies (when to flee, when to fight) are encoded in neural patterns that are flexible and context-dependent. But the molecular machinery that actually executes those strategies — protein folding, enzyme catalysis, membrane transport — operates with chemical determinism. Both layers evolve, but through different mechanisms.

What This Means for the Ecosystem

If you're building AI agent infrastructure today, the choice between these approaches determines your ceiling:

JSON templates let you scale fast and lower barriers, but you'll eventually face quality inflation (too many templates, no reliable way to rank them) and the safety question ("what if a template gives dangerous advice to a powerful agent?").

Executable genes take longer to bootstrap but provide the primitives needed for genuine quality selection and runtime safety. The investment is front-loaded in compilation, sandbox, and evaluation infrastructure — but once that's in place, the ecosystem can self-select for quality without human curation.

The AI agent ecosystem is still early enough that both paths are being explored. What's clear is that the "gene" metaphor — modular, transferable, evaluable capabilities — is winning. The open question is what a gene is made of. The answer shapes everything downstream.

Install the Rotifer CLI and try an executable gene:

npm install -g @rotifer/playground
rotifer search --domain "text-processing"
rotifer run grammar-checker --input '{"text": "This are a test"}'

Read more:

• From Skill to Gene: Why Modularization Is Just the Starting Point
• Your First Rotifer Gene in 5 Minutes
• The Philosophy of Digital Evolution

Update: This is the original March 25 scan. For the latest data (March 27 refresh), see We Re-Scanned the Top 50 — Things Have Changed.

We took our V(g) security scanner and ran it against the Top 50 most-installed ClawHub Skills — totaling over 1.25 million downloads. The goal was simple: apply the same static analysis we use for Rotifer Genes to the most popular tools in the Claw ecosystem, and publish the results.

The headline: zero CRITICAL findings across all 50 Skills. No eval(), no child_process, no code obfuscation.

But the details tell a more nuanced story.

Grade Distribution

88% of the Top 50 received the highest grade. That's a strong signal for the ecosystem's security baseline — at least among the most popular tools.

Most Skills Are Pure Prompt

66% of the Top 50 are prompt-only Skills. They contain no executable code — only a SKILL.md instruction file. These are inherently safe from code-level attacks (though prompt injection is a separate concern outside V(g) scope).

This ratio raises an interesting question: if most popular AI tools are just prompts, what does "quality" mean beyond security? Documentation completeness, error handling patterns, and claim-vs-reality alignment become the more meaningful dimensions.

Most Common Risk Patterns

Among the 34% that ship code:

S-07 (File I/O) is the most common — many Skills need to read/write configuration files. Expected for CLI tooling.

S-05 (Env Access) is standard practice for API key management. The concern isn't reading env vars per se, but which vars and where the values are sent.

Every finding was explainable and context-appropriate.

Skills with Findings

All findings are legitimate operations for the Skills' intended functionality.

Comparison with ClawHavoc

In February 2026, the ClawHavoc incident revealed that ~12% of ClawHub's 38,000+ Skills had been compromised. Our Top 50 scan shows a markedly healthier profile:

The most popular Skills have stronger security hygiene — likely because high-visibility tools attract more scrutiny, 28 of the 50 are Certified Skills that undergo review, and established authors maintain quality.

But what about the other 12,950?

Methodology

• Scanner: Rotifer V(g) v0.7.9, 7 regex-based detection rules (S-01 through S-07)
• Scope: Top 50 Skills by download count
• Date: March 2026
• Code types scanned: .ts, .js, .py, .sh, .mjs, .cjs
• Excluded: node_modules/, .git/, dist/ directories
• Limitation: Static analysis only — does not evaluate runtime behavior, prompt injection, or supply chain dependencies

What This Means

The data suggests two things:

1. The top of the ecosystem is clean. Security tooling like VirusTotal + manual review has kept the most popular Skills safe. V(g) confirms this with a different methodology.

2. Security is necessary but not sufficient. When 66% of popular tools are just prompts, code-level security scanning catches one dimension. Quality scoring — documentation, error handling, claim verification — addresses the rest.

V(g) is one layer of trust. We think the ecosystem needs more layers. If you're interested in quality scoring as a complement to security scanning, we'd love to hear your perspective.

Try It

Scan any Skill or Gene with one command:

npx @rotifer/playground vg <path>

Badge your repo: rotifer.ai/badge

Full scanner docs: rotifer.dev/docs/cli/vg

Report by Rotifer Protocol. Data, methodology, and scanner are open source.

Versions 1.82.7 and 1.82.8 contained a credential harvester. One pip install was all it took.

This isn't a story about one package getting hacked. It's a story about why the entire Python package ecosystem's trust model is fundamentally broken for AI agent infrastructure — and what a real defense looks like.

What Happened

The attack was a four-step supply chain cascade:

Step 1 (March 19): Trivy v0.69.4 was poisoned. Trivy is Aqua Security's open-source vulnerability scanner — a tool designed to protect you. The threat actor TeamPCP injected a credential stealer into it.

Step 2 (March 23): LiteLLM's CI pipeline ran the compromised Trivy to scan its own code for vulnerabilities. During this "security scan," Trivy silently exfiltrated the maintainer's PYPI_PUBLISH_PASSWORD.

Step 3 (March 24, morning): TeamPCP published litellm 1.82.7 to PyPI using the stolen credentials. Malicious code was hidden in litellm/proxy/proxy_server.py, executing when developers imported the module.

Step 4 (March 24, hours later): TeamPCP published litellm 1.82.8 — an escalated version. This one added a litellm_init.pth file that executes automatically every time Python starts. No import needed. No function call needed. If Python runs, the malware runs.

The security tool became the attack vector.

The .pth Attack Vector

This is the most technically interesting part. Python's .pth files are path configuration files processed by the site module at interpreter startup. If a line starts with import, it gets exec()'d — this is documented Python behavior, not a vulnerability.

The attacker exploited this:

import os, subprocess, sys; subprocess.Popen([sys.executable, "-c",
"import base64; exec(base64.b64decode('...'))"],
stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)

This means:

• pip install anything → Python starts → .pth runs → credentials harvested
• python -c "print(1)" → same
• Your IDE starts a language server → same
• pytest runs your test suite → same

No user-visible action. Completely silent. The payload was triple-nested base64 to evade static analysis.

The Three-Stage Payload

Stage 1 — Credential Harvester: Systematically scraped /home, /opt, /srv, /var/www, /app, /data, /tmp for SSH keys, AWS/GCP/Azure credentials, Kubernetes secrets, cryptocurrency wallets, .env files, database passwords, shell history. Encrypted everything with a random 32-byte AES session key, then wrapped the AES key with RSA-OAEP (4096-bit public key embedded in the payload). Exfiltrated to models.litellm.cloud — a convincing impersonation domain.

Stage 2 — Kubernetes Lateral Movement: If it detected a K8s service account token, it deployed privileged pods to every cluster node, then installed persistence droppers.

Stage 3 — Persistent Backdoor: Registered ~/.config/sysmon/sysmon.py as a systemd user service. Polled checkmarx.zone every 50 minutes for new payloads. Downloaded to /tmp/pglog for execution. Had a 5-minute startup delay to evade sandbox analysis. Survived litellm uninstallation.

Why Existing Defenses Failed

pip install --require-hashes? Useless. The malicious files were properly listed in the wheel's RECORD with correct hashes. Because the package was published with stolen legitimate PyPI credentials, everything was technically "authentic."

Package signing? Same problem. The credentials were real. The signature was valid.

Security scanning? The attack started by compromising a security scanner. Trivy was supposed to protect LiteLLM. Instead, it became the entry point.

Community reporting? When the issue was filed on GitHub, the attacker used 73 stolen accounts to flood it with 88 spam comments in 102 seconds, then used the stolen maintainer account to close the issue.

The only reason the attack was discovered: the attacker's own code had a bug. The .pth file spawned subprocess.Popen, and during child process initialization, Python's site module re-scanned the same .pth, triggering exponential recursion — a fork bomb that crashed a Cursor IDE user's machine. Karpathy commented: if the attacker had written better code, this might have gone undetected for weeks.

The Real Problem: Implicit Execution

The root issue isn't LiteLLM. It's that the Python package ecosystem has multiple paths for code to execute without explicit invocation:

AI agent infrastructure typically combines dozens of packages, each with their own dependency trees. Every dependency is a trust decision that most developers make unconsciously. The LiteLLM attack showed that even packages you never directly installed (transitive dependencies) can harvest your credentials silently.

What Sandboxing Actually Prevents

At Rotifer Protocol, we compile agent capabilities (called Genes) to WebAssembly and execute them in a wasmtime sandbox. This isn't a theoretical defense — it's a fundamentally different execution model that eliminates the attack surface LiteLLM was compromised through.

No filesystem access. A sandboxed Gene cannot read ~/.ssh/, ~/.aws/credentials, or any .env file. The WASM sandbox has no filesystem API unless explicitly granted.

No subprocess spawning. subprocess.Popen, child_process.exec, os.system — none of these exist in the WASM execution environment. The .pth attack chain (Popen → base64 → exec) is structurally impossible.

No implicit execution hooks. There is no .pth equivalent in WASM. Code runs when the runtime explicitly invokes it, not when an interpreter starts.

Declared network boundaries. Genes that need network access must declare allowedDomains in their Phenotype — a machine-readable capability manifest. An undeclared POST to models.litellm.cloud would be rejected before the request leaves the sandbox.

Binary-level enforcement. These restrictions aren't policy rules that can be bypassed — they're enforced by the wasmtime runtime at the system call level. A Gene compiled to WASM physically cannot issue the syscalls needed to read files or spawn processes, regardless of what its source code attempts.

In v0.8, we ran 22 adversarial tests specifically designed to break these sandbox boundaries: memory out-of-bounds attacks, infinite loops, recursive stack exhaustion, attempted filesystem access, unauthorized network calls. After patching two critical gaps found during testing, zero escape attempts succeeded.

V(g): Scanning for Exactly These Patterns

The V(g) security scanner we shipped in v0.7.9 detects the exact patterns used in the LiteLLM attack:

V(g) scans source code statically — no ML, no heuristics, just pattern matching on the things that matter. It grades tools A through D and generates shields.io-compatible badges that any developer can embed in their README.

When we scanned the Top 50 most-installed ClawHub Skills with V(g), 100% triggered at least one finding. Zero Grade A results. 14% contained dynamic code execution — the exact same technique used in the LiteLLM payload.

The Uncomfortable Conclusion

The LiteLLM incident isn't an outlier. It's the logical consequence of an ecosystem where:

1. Trust is transitive and invisible. You trust litellm, which trusts Trivy, which was compromised. You never made a decision about Trivy.
2. Execution is implicit. Code runs not because you called it, but because the interpreter started.
3. Authentication ≠ authorization. Valid credentials don't mean valid intent. Hash verification and package signing are authentication measures. They tell you who published the package, not what the package does.

The defense isn't better scanning of Python packages (though that helps). The defense is an execution model where untrusted code physically cannot access the resources it wants to steal.

Compile to WASM. Run in a sandbox. Declare network boundaries explicitly. Make the default "no access" instead of "full access."

That's what we're building.

Immediate Actions If You're Affected

If you installed litellm 1.82.7 or 1.82.8:

1. Assume all credentials are compromised. Rotate everything: SSH keys, cloud provider credentials, API tokens, database passwords.
2. Check for persistence: ls ~/.config/sysmon/ and ls /tmp/pglog. If either exists, your system has a backdoor.
3. Check for the .pth file: Search your Python site-packages for litellm_init.pth. Remove it.
4. Pin to safe version: pip install litellm==1.82.6
5. Run the community self-check script: gist.github.com/sorrycc/30a765...

Safe versions: litellm <= 1.82.6. Versions 1.82.7 and 1.82.8 are compromised and have been removed from PyPI.

The immediate reaction is straightforward: cheaper inference, faster generation, longer context windows. But the second-order effect is more interesting, and it depends on how your agent architecture is structured.

The Monolithic vs. Modular Divide

Consider two ways to build an AI agent that processes a job application:

Monolithic: One large prompt handles everything — parse the resume, evaluate qualifications, check for red flags, generate a summary. One LLM call, one KV cache.

Modular: Five separate capabilities handle the pipeline — resume-parser, qualification-matcher, red-flag-scanner, bias-detector, summary-generator. Five LLM calls, five KV caches.

With TurboQuant-style compression:

The monolithic agent saves memory on one large KV cache. The modular agent saves memory on five smaller caches — and because each cache is independent, the total memory footprint drops enough to run pipelines that previously couldn't fit on the same device.

This isn't just about saving memory. It's about crossing a threshold: the point where modular LLM-native pipelines become economically competitive with hand-optimized monolithic systems.

The Cost Crossover

In any agent framework with a fitness function, cost matters. If your agent's value is measured as:

Fitness = Quality / Cost

Then compression doesn't just improve the numerator (by enabling longer context without degradation). It directly shrinks the denominator. And for modular agents, the denominator shrinks at every step in the pipeline.

This creates a crossover effect:

1. Before compression: LLM-native modules are expensive per-call. Developers hand-optimize critical paths into compiled code (WASM, native binaries) to avoid inference costs.

2. After 6× compression: The cost gap between "call an LLM" and "run compiled code" narrows significantly. For many use cases, the development speed of writing a prompt-based module outweighs the marginal cost advantage of compiled code.

3. At the crossover point: Developers choose LLM-native modules by default, only dropping to compiled code for hot paths that justify the engineering investment.

This is exactly the dynamic that accelerates ecosystem growth. Lower barriers to creating new capabilities means more capabilities get created, which means more competition, which means faster quality improvement through selection pressure.

Why This Matters for Edge Deployment

The memory wall is the primary obstacle to running agent pipelines on consumer hardware. A single LLM already consumes most of a laptop's RAM. Running a pipeline of five LLM-native modules was effectively impossible without cloud offloading.

Recent research reinforces the shift:

• Persistent Q4 KV Cache demonstrates 136× reduction in time-to-first-token on Apple M4 Pro by persisting quantized caches to disk — enabling 4× more agents in fixed device memory.
• ST-Lite achieves 2.45× decoding acceleration for GUI agents using only 10-20% of the cache budget.

Combine TurboQuant's 6× cache compression with persistent quantized caches and the arithmetic changes: a Mac Mini that previously ran one agent can now run a five-module pipeline locally. No cloud. No latency. No data leaving the device.

For frameworks built around fine-grained, composable capabilities, this is the enabling condition for local-first agent evolution.

The Structural Advantage of Fine Granularity

The compounding effect only works if your architecture is actually modular at the right granularity. A framework that treats "the agent" as one big blob gets the same linear benefit as any other monolithic system.

The compound benefit requires:

1. Capabilities are separate execution units — each with its own inference call, its own KV cache, its own resource accounting.
2. Capabilities compose into pipelines — so compression savings multiply across the pipeline.
3. Cost is part of the selection signal — so cheaper execution directly improves a capability's competitive position.

This is why the intersection of inference compression and modular agent architecture is structurally interesting. It's not just "things got cheaper." It's that the relative economics between monolithic and modular shifted — and modular benefits more.

What Doesn't Change

TurboQuant compresses KV cache during inference. It doesn't compress model weights, doesn't reduce training costs, and doesn't change the fundamental capabilities of the underlying LLM.

The algorithm is also newly published (ICLR 2026). Ecosystem integration into inference runtimes like llama.cpp, vLLM, and Ollama is still in early stages. The 6× and 8× numbers come from controlled benchmarks on open-source models (Gemma, Mistral, Llama-3.1), not production deployments.

The direction is clear. The timeline for practical adoption is not.

The Takeaway

Inference compression is a rising tide, but it doesn't lift all boats equally. Architectures built around fine-grained, independently-executed capabilities — where each module is a separate inference call with its own cost accounting — benefit disproportionately from compression advances.

The finer the granularity, the bigger the compound savings. The bigger the savings, the more viable local-first deployment becomes. The more viable local deployment becomes, the faster the ecosystem of LLM-native capabilities can grow.

TurboQuant didn't change the rules. It changed the economics. And in evolution, economics is half the fitness equation.

The Flash-Lite Browser is a striking demo. But it also exposes a structural gap in how we think about agent interfaces. The industry is converging on an architecture — CLI for agents, protocols for communication, generated GUI for humans — but this three-layer stack is missing something critical.

The Three-Layer Interface Stack

A pattern is forming across the agent ecosystem. It looks like this:

Bottom layer: CLI is the agent runtime. Agents operate through text commands — structured input, structured output, composable pipelines. This is their native language. Claude Code, GitHub Copilot CLI, and every MCP-connected agent speak CLI first.

Middle layer: Protocols connect agents to the world. MCP connects agents to tools. AG-UI connects agents to frontend interfaces. A2UI lets agents describe UI components declaratively. A protocol triangle is taking shape.

Surface layer: GUI becomes what AI generates for humans. Flash-Lite Browser is the extreme case — the entire page is AI-generated. But even conventional agent UIs (chat interfaces, dashboards, reports) are increasingly produced by models rather than designed by humans.

This three-layer view is useful. It explains why terminal usage among professional developers jumped from 62% to 78% in two years (Stack Overflow Developer Survey). It explains why Claude Code reached $1B ARR within months of launch. And it explains why Google is experimenting with browsers that generate rather than fetch.

But it describes architecture. It says nothing about dynamics.

The Missing Fourth Layer: Selection Pressure

Here is the question the three-layer model does not answer: when a hundred agents can all generate a UI, which one should you trust?

Flash-Lite Browser generates a plant care page in 1.93 seconds. Impressive. But as The Decoder noted, "results are not stable — content quickly drifts off-topic." The same query produces different layouts. Navigation leads to inconsistent pages. The content is plausible but unreliable.

This is not a model quality problem that will be solved by the next generation of LLMs. It is a selection problem. When interfaces are generated rather than designed, you need a mechanism to evaluate which generation approach produces better outcomes — and to let bad approaches fade away.

In biology, that mechanism is natural selection. In software, we have been building its equivalent.

The Rotifer Protocol introduces a competitive evaluation layer where modular capabilities — called Genes — are scored by a multiplicative fitness function:

$$ F(g) = \frac{S_r \cdot \log(1 + C_{util}) \cdot (1 + R_{rob})}{L \cdot R_{cost}} $$

Success rate, community utility, robustness, latency, cost — all measured, all weighted, all used to rank competing implementations. Genes that score well propagate. Genes that score poorly retire. The selection pressure is quantified and continuous.

This is the missing fourth layer: evolution infrastructure. Not just connecting agents to tools (protocols do that), but deciding which tools survive.

Protocols Connect. Evolution Selects.

MCP is a connectivity standard. It tells an agent how to discover and invoke a tool. But it says nothing about whether the tool is any good.

Consider an agent choosing between three MCP-connected tools that all claim to generate plant care guides. MCP ensures the agent can call any of them. But which one produces accurate watering schedules? Which one formats content clearly? Which one hallucinates less?

Without a fitness layer, the agent has no signal. It picks randomly, or picks the first one it finds, or picks the one with the most downloads — none of which correlate reliably with quality.

The Arena provides that signal. Competing Genes run against standardized benchmarks. Their fitness scores are public. Agents can query the registry and select the highest-ranked Gene for a given task. The selection is data-driven, not arbitrary.

This pattern — protocol for discovery, evolution for quality — is the full stack.

The Reliability Problem Reframed

The criticism of Flash-Lite Browser is that results are unstable. Every render differs. Same query, different layout.

But instability is not inherent to AI-generated interfaces. It is a symptom of missing selection pressure. When there is no mechanism to evaluate which generation approach works better, every approach is equally likely to be used — including bad ones.

Imagine a world where UI generation Genes compete in an Arena. A Gene that produces consistent, readable plant care pages scores higher than one that drifts off-topic. Over time, the drift-prone approach is selected against. The ecosystem converges toward reliability — not because someone manually debugged each page, but because the fitness function rewards consistency.

This is how biological systems solve the reliability problem. Not through top-down design, but through bottom-up selection.

Four Layers, Not Three

The complete agent interface stack is not three layers. It is four:

The first three layers describe what agents can do. The fourth layer determines which agents do it well.

Google's Flash-Lite Browser is a preview of the GUI layer's future. MCP is establishing the protocol layer. CLI has been the agent runtime for over a year. But without evolution infrastructure, the stack is incomplete — beautiful demos that produce unreliable results.

The interface revolution is real. The question is whether we build the selection layer before or after unreliable agent outputs erode user trust.

We think before.

rotifer.dev