The Pattern Library: What 100,000 Repositories Are Made Of

Four independent teams — Microsoft, Alibaba, a Rust startup, and an open-source agent framework — each solved the same problem the same way, and none of them cited the others. They all execute untrusted agent-generated code inside a constrained WebAssembly runtime with host imports blocked. That convergence is not a coincidence. It is evidence, and it is the kind of evidence a pattern library exists to capture.

Gerolamo now indexes 100,586 sources across GitHub, arXiv, and Hugging Face. Scoring those projects tells you what to watch. It does not tell you what to build with. So we decomposed them. The result is a library of 4,029 reusable patterns: the discrete mechanisms that make those projects work, each extracted from its host codebase, given an explicit interface, and linked back to every source it was found in.

This post is about what falls out of the corpus when you stop reading projects and start reading mechanisms.

---

Context: The Corpus Grew Faster Than Anyone Can Read It

The scale problem is not new, but it has gotten worse in a specific way. GitHub's Octoverse report tracks over a billion contributions a year across hundreds of millions of repositories. arXiv's cs.AI and cs.LG categories publish thousands of papers a month. Gerolamo's own corpus breaks down as 62,785 GitHub repositories, 37,418 arXiv papers, and 383 Hugging Face models, with 99,424 of them embedded for semantic retrieval.

An engineer evaluating how to sandbox agent tool calls does not need 62,785 repositories. They need the four or five mechanisms that the field has actually converged on, and they need to know which ones are load-bearing.

Eighteen months ago we argued in Pattern-Based Engineering that the durable value in software was moving from the systems themselves to the patterns that compose them and the data that feeds them. The frameworks get commoditized. The mechanisms persist. That was a thesis. The pattern library is the version of it you can query.

---

A Pattern Is a Mechanism With an Interface and a Provenance Trail

Here is the definitional anchor. A pattern is a discrete, reusable mechanism extracted from a real codebase, expressed as a typed transformation from an input to an output, classified by its side effects and architectural area, and carrying links to every independent source in which it was observed.

Four properties do the work:

1. The interface — a takes X → produces Y contract. Not a description of what a project is, but a statement of what a mechanism converts. Repository -> IsolatedWorkingCopy. UntrustedCode -> ExecutionResult. SearchQuery -> RelevantContext.
2. The effect class — none, read, write, or external_call. This is the mechanism's blast radius. It tells you what has to be governed before you adopt it.
3. The stack area — ai_ml, data, application, interface, infrastructure, security, operations, or other. Where in an architecture the mechanism lives.
4. The provenance — the list of sources the mechanism was found in. This is what turns a description into evidence.

A distilled pattern looks like this:

{
  "name": "Sandboxed tool execution",
  "interface": "(WasmComponentBytes, ToolArguments) -> ToolResult",
  "effect": "none",
  "stack_area": "security",
  "mechanism": "Execute compiled WebAssembly components inside a constrained
                WebAssembly runtime with blocked or restricted host imports.",
  "provenance": [
    "microsoft/wassette",
    "liquidos-ai/AutoAgents",
    "moltis-org/moltis"
  ],
  "pattern_id": "a0d883fa-8951-415d-857d-d9006d72f9ce"
}

The same mechanism appearing in three unrelated projects collapses into one pattern carrying three provenance links, rather than three separate entries. Deduplication is the entire point: the library gets smaller and more confident as the corpus grows.

---

Corroboration Is the Strongest Available Signal of Convergence

Popularity metrics measure attention. Stars measure how many people bookmarked something. Neither measures whether a technical approach is correct.

Corroboration count — the number of independent codebases in which the same mechanism was found — is a better proxy for technical settlement than any traction metric. When four teams with different funding, languages, and goals independently arrive at the same construction, they are reporting a constraint about the problem, not a fashion.

This matters most in young domains. In a mature field, you can read the textbook. In agent infrastructure, which barely existed three years ago, there is no textbook, and the loudest repository is often not the most instructive one. Corroboration lets you find the settled answer before anyone writes it down.

Consider git worktree workspace isolation, a Repository -> IsolatedWorkingCopy mechanism found in the-open-engine/zeroshot, jayminwest/overstory, holon-run/holon, and one more. The mechanism is simple: check out a clean branch into a separate Git worktree so parallel agent runs never touch the developer's working directory. No one is marketing this. It has no name in the literature. Four teams building parallel coding agents each hit the same wall and each cut the same key. That is what settled looks like before it gets a name.

---

The Distribution of Patterns Maps the Shape of the Field

Aggregate the library and it becomes a census. Of 4,029 patterns:

By stack area:

Area	Patterns
ai_ml	1,100
infrastructure	863
data	749
application	433
security	322
operations	317
interface	130
other	115

By effect class:

Effect	Patterns
none (pure)	2,019
write	920
external_call	595
read	495

Two things stand out.

First, interface is the thinnest layer in the corpus at 130 patterns, roughly one-eighth the size of ai_ml. The open-source agent ecosystem has produced far more ways to reason than ways for a human to see, steer, or interrupt the reasoning. Anyone looking for underbuilt territory has a coordinate.

Second, half the library is pure. 2,019 patterns have no side effects at all, and only 595 make external calls. The mechanisms that carry real governance risk are a minority, and they are individually identifiable. That is the precondition for reviewing a system's blast radius without reading its whole source tree, which is the same argument we made for the Software Bill of Function: inventory what software does, not just what it contains.

---

Reading the Agent Stack Through Its Patterns

The clearest demonstration is a domain the field is actively figuring out. Here is what the corpus says about how agents interact with computers and tools, entirely through corroborated mechanisms.

Vision-only computer use. vision-based-cross-platform-computer-use takes Screenshot + TaskGoal → UIActionSequence and appears in OpenGVLab/ScaleCUA, simular-ai/Agent-S, microsoft/fara, and one more. A vision-language model predicts low-level actions — click, type, scroll, hotkey — across Windows, macOS, Linux, and Android without accessibility APIs or DOM access. The corroboration is the finding: four teams concluded that instrumented access is not worth the coupling. You can see the same conclusion in individual sources like xlang-ai/aguvis, scored 6/10 on defensibility at 389 stars, and TencentQQGYLab/AppAgent at 6,667 stars. The seventeen-fold difference in stars between them says nothing about which approach is right. The pattern does.

Tool transport. Two distinct MCP mechanisms show up separately, which is itself informative. MCP workbench tool adapter takes StdioServerParams -> List<Tool>, spawning a Model Context Protocol server process and translating its exposed actions into agent tools. It is corroborated by microsoft/autogen, the-open-agent/openagent, and trpc-group/trpc-agent-go. Separately, mcp-tool-execution takes ToolCallRequest -> ToolCallResponse in onyx-dot-app/onyx, heurist-network/heurist-agent-framework, and CherryHQ/cherry-studio. Discovery and invocation have separated into independently reusable pieces, which is what a protocol layer looks like once it stabilizes.

Containment. Two mechanisms, different risk postures. Sandboxed tool execution uses the WebAssembly Component Model with host imports blocked, in microsoft/wassette, liquidos-ai/AutoAgents, and moltis-org/moltis. sandboxed code execution verifier takes UntrustedCode -> ExecutionResult in unslothai/unsloth, onyx-dot-app/onyx, and evalplus/evalplus. At the whole-project level, alibaba/OpenSandbox scores 7/10 with MEDIUM frontier risk at 9,933 stars. The project is a product decision. The patterns are the design decision, and they are the part you can carry into your own system.

Provenance. in-toto-attestation-signing takes (StandardSBOMDocument, SigningKey) -> InTotoAttestation from anchore/syft, wrapping an SBOM in an in-toto statement and signing it. It sits next to cosign-signature-verification, which validates image provenance against a Sigstore key or OIDC identity. Only 322 security patterns exist against 1,100 in ai_ml, which is a reasonable summary of where the ecosystem's attention has gone.

Five paragraphs, no repository tours, no README reading. That is the throughput difference.

---

Patterns Compose Into Enhancements

A library you can only browse is a reference. The reason to give every mechanism an explicit input-output contract is that contracts compose.

In Gerolamo, the Workspace is where you assemble selected patterns, and an Enhancement is a ready-to-apply capability composed from patterns — a specification, an agent skill, or a working MCP server — that carries the lineage of every pattern and source it was built from. Concepts work the same way for speculative ideas: a proposed combination stays traceable to the real sources underneath it.

The workflow is four steps:

1. Search the pattern library by problem, effect class, or stack area rather than by project name.
2. Filter by corroboration count to keep only mechanisms with independent confirmation.
3. Compose the selected patterns in a Workspace into a specification or skill.
4. Trace the result back through its lineage to the original repositories and papers.

Step four is the one that matters for anything that gets reviewed. A generated specification that cannot name its sources is an assertion. One that resolves to microsoft/wassette and anchore/syft is an argument.

---

Agents Consume Patterns Better Than They Consume Repositories

The pattern library was built for agents as much as for engineers, and the reason is mechanical.

A repository handed to a language model is unstructured context: README, source tree, issues, inconsistent documentation. The model has to infer the mechanism before it can use it, and inference over noisy context is where hallucinated architecture comes from. A pattern is pre-inferred. The interface is explicit, the effect is declared, the provenance is checkable.

This is the ground-truth argument we made in Scored Sources: The Ground Truth AI Agents Need, applied one level down. Scored sources tell an agent which projects are defensible. Patterns tell it which mechanisms to actually write.

Every one of these is reachable over MCP. search_patterns queries the library with the same effect, stack-area, corroboration, and recency filters described above, and reports total match counts and exact offsets so an agent can verify full coverage rather than assume it. distill extracts the patterns from a source on demand. compose_enhancement turns a selection into a working capability. Connect an MCP client at gerolamo.org/connect, or see What an Agent Can Do with Gerolamo MCP for the full tool surface.

The since and until filters deserve a specific mention. They bound when a pattern was distilled, which means an agent can diff the library against its last sweep instead of re-reading all 4,029 entries. Monitoring the mechanism layer for what is new becomes a scheduled query.

---

What This Changes

If you are making architecture decisions in a domain that is moving faster than its documentation, three things change.

Evaluation gets cheaper. You compare mechanisms with stated interfaces instead of reading repositories and inferring intent. The comparison unit becomes small enough to hold in your head.

Evidence replaces taste. "Four independent implementations converged on this" is a defensible reason to adopt an approach. "It has the most stars" is a description of a popularity contest. When the decision gets questioned in review, corroboration is the thing you can point at.

Governance becomes tractable. Effect classes make blast radius a queryable property. You can enumerate every external_call and write mechanism in a proposed design before you build it, which is the practical version of the assurance argument in AI Assurance Is Not a Policy Problem.

The corpus keeps growing, and the deduplication means the pattern library does not grow proportionally. It sharpens. Every new repository that reimplements sandboxed execution adds a provenance link rather than a new entry, and the confidence on that mechanism goes up.

---

The pattern library is live and browsable with filters for effect, stack area, corroboration count, and distillation date. Scored sources sit underneath it at gerolamo.org, and the whole corpus is queryable by agents over MCP. The architecture behind it is the one we deploy for partners.

Read projects and you learn what exists. Read patterns and you learn what works.