OpenRig, a Self-Built AI Team, Explodes on GitHub: An Unstoppable Collaboration Experiment

An overseas developer's side project OpenRig unexpectedly hit GitHub trending, and with PRs flooding in, he was forced to triple his own AI agent team to cope. This "happy problem" ultimately evolved into a systematic reflection on context engineering and agent collaboration — a must-read for anyone building AI workflows.

What OpenRig Is: Organizing Code Agents into a "Team"

OpenRig is an open-source tool whose core idea is to place coding agents like Claude Code, Codex, and Pi into an orchestratable system, forming what he calls a rig team. Each agent has a clear role (equivalent to a job position) and an address (equivalent to an email), can communicate directly with one another, runs across multiple machines, and forms a collaborative agent network.

The design philosophy is simple: take the best off-the-shelf tools, turn them into composable primitives, reduce the friction between them, and see what happens. From this emerged a pattern — you only need to talk to a lead agent, and behind it a group of agents works for you. This "talk to one agent" template later became the basic unit for his scaling.

The Stress Test Brought by GitHub Trending

After the video was released, OpenRig hit trending, and stars and PRs came pouring in. What had been just him and his agents quietly "building in public" suddenly became a group of people participating together. He admits he never planned for the launch and afterward felt he should have added a disclaimer saying "not suitable for beginners."

The more practical problem: a side project suddenly generating 20x the workload, with attention becoming the scarcest resource. He didn't treat it as a nuisance but as an opportunity to spend money verifying whether the system could withstand scale. His approach was to add compute to the "talk to one agent" template — more VPSs, each running a different type of rig, expanding the team to about 3x, while keeping it within what his attention could cover. By his account, during the two weeks of trending, he had to build a system to review and QA all external contributions.

The Real Challenge: Agents "Reinventing the Wheel"

Adding agents is only half the battle; the other half is whether these agents are actually reliable. The core problem he encountered was agents repeatedly reinventing the wheel — building a new implementation in parallel right next to an existing one.

The most typical example was the Slack integration. The feature was almost complete; after shelving it for a month, he had an agent finish it up. The agent searched for Slack, then "as requested" built the integration, and everything worked — but it invented an entirely independent communication system from scratch and then hooked Slack onto it, completely different from the implementation he remembered. This had happened over a hundred times by then, and he'd tried graph databases and AI memory solutions, all hitting the same wall. At that moment he realized: they don't know what they don't know.

The documentation and context were all there, but unless hand-guided, the agent didn't know where to look — or even what questions to ask. No amount of search capability helps — the problem occurs before the search. Having the agent write a note saying "a Slack integration already exists" is meaningless; that's a game of whack-a-mole, and you can't anticipate every scenario. What's needed is a generalizable solution.

Reconstructing Context with "Worldbuilding"

He broke the problem down to the first principles of knowledge itself. One practical clue ran throughout: giving an agent good examples is far more effective than a pile of facts and rules. Why do examples work better than facts? He borrowed the "connecting the dots" metaphor — each dot is a piece of information, and only when connected do they form a picture, an arrangement. A pile of unconnected facts moves nothing, and that's exactly what agents naturally accumulate.

When a new agent enters a project, it brings a wealth of training knowledge (white dots) but hasn't connected them the way you have (blue lines), and there are new dots that simply don't exist in its training data (blue dots). He likens this increment to a diff in a PR. On the human side, he cites the memory palace technique from Moonwalking with Einstein to explain that the brain is optimized for wayfinding in 3D terrain — worldbuilding and progressive disclosure exploit exactly this, and agents.md and skills are already doing something similar.

He argues that humans and LLMs sharing language as a substrate makes them "cognitive cousins." If the shared medium is friendly only to agents and opaque to him, he himself becomes a bottleneck or even gets pushed out of the loop. Markdown is popular precisely because it sits in the cognitive overlap zone: LLMs can read and write it, can write small programs to manipulate its structure, and humans can directly read and edit it. Worldbuilding promises to occupy a similar middle ground, achieving cognitive interoperability.

Progressive disclosure originates from interaction design and technical writing: rather than presenting all information at once, it first provides an overview and entry points, and the user or reader expands details layer by layer as needed. In AI context engineering, it corresponds to a strategy where an agent loads only a "map" or a routing description at startup rather than the entire knowledge base; only when it determines it needs to go deeper into a domain does it read the corresponding files or invoke the corresponding agent. This way, the limited context window is reserved for genuinely relevant information, and token consumption stays controlled. The skills mechanism and agents.md mentioned in the article are both practices of this approach — using titles and descriptions as "door signs" to entice the agent to open the right door at the right moment.

The Four Dimensions of Context Topology

He breaks knowledge organization into a set of operational terms: entities (knowledge points in an ontology, i.e., dots), relations (connections), and topology (the shape formed by connections). Clicking around Wikipedia via links is navigating this kind of topology, and agent retrieval is essentially the same.

The question remains: how do you know where to start looking? His answer is to provide a wider-angle map — "an inch deep and a thousand miles wide," trading width for depth. Letting someone know something exists saves far more tokens than knowing everything about it. The goal is a kind of minimum viable competence: the agent can locate itself, start working, and know when to go deeper versus broaden scope. An agent doing code review and an agent doing architecture don't need the same map. As a project grows, you layer more maps into a hierarchy and let the agent know there's a world beyond the map's boundaries.

The map sits at the start of the journey, such as agents.md, which then routes to OpenRig's context library, or through a router skill to choose which domain to enter. Addressability is key: agents have addresses, contexts have addresses (file paths), and content within a file can even be made addressable by referencing Markdown headings, and custom views can be composed. What he pursues is reachability from root to leaf — tracing all the way from where the agent starts to the knowledge it needs. Skill titles and descriptions should act like "good clickbait," enticing the agent to open the router and enter the whole world.

The third dimension is epistemology: knowledge matures from low-level logs and "markdown scraps" through observations, field notes, and insights into canon — the part of the project regarded as established knowledge. Canon is about degree of establishment rather than recency; a new discovery can become canon immediately. The maturity of knowledge points constitutes height, turning the 2D map into 3D terrain. The fourth dimension is time: relations change, mature, and shift, and taking snapshots of each moment and arranging them in sequence is essentially a story.

Ontology is a term borrowed from philosophy and knowledge engineering; in computing it usually refers to an explicit formal description of the concepts, properties, and their interrelations within a domain. The article brings it down to a very plain level: each knowledge point in an ontology is an "entity," i.e., a "dot" in the topology; links between entities form "relations," and the shape formed by relations laid out as a whole is "topology." The reason for ontological awareness is that for an agent to locate itself, judge whether some piece of knowledge exists, and know what other knowledge it connects to, these entities must have stable and addressable identities. Without an ontology, knowledge is just unstructured text, and retrieval is impossible.

Context compaction is a common mechanism in long-session agent systems: when conversation history or context approaches the model's window limit, the system summarizes, collapses, or discards earlier content, keeping only key conclusions to free up space for subsequent interaction. It lets agents keep working without "blowing up" the window, but at the cost of lost detail — certain paths, conventions, or historical lessons may no longer be explicitly present after compaction. The article mentions that some routes "only surfaced after compaction," precisely illustrating that compaction changes an agent's visibility into the world; therefore key knowledge needs stable addresses and external storage rather than relying solely on session memory.

Examples as Compression: Starting with the "Doghouse Moonbase"

Since a story is an arrangement of arrangements, the standard for a good story is also the standard for a good example. He once told a story: he asked an agent to build a doghouse and came back to find a moonbase — the agent made one reasonable decision after another and produced something nobody wanted. This story was placed in the workspace's lore folder as experience passed down from generation to generation of agents.

Lore can belong to a rig, a pod, or even a seat, and has an address. At initialization and after context compaction, he tells the doghouse moonbase story; when the agent errs again, a single word "moonbase" lets it recognize the problem without unfolding the whole story. A good example is a world in motion compressed into a single piece of knowledge, able to carry the lesson into completely unrelated scenarios and generalize like a principle — which is also why it scales better than writing rules one by one.

He also warns against over-rotating: the map is not the territory. The ontology is files on disk, Markdown headings, links, and OpenRig commands; you still have to open files, read code, and confirm what the system is actually doing.

A Distributed Knowledge Network: Files, Agents, and People

He returns to the Slack integration example to demonstrate how the system works. Knowledge about "how messaging is integrated" is stored in only one place with a fixed address; when it changes, the address stays the same, and the agent reads the new version when consulting it. It will also discover that the agent who originally did Slack is still online and use rigsend to ask it directly why it was implemented that way.

Knowledge isn't just a file or part of a file, but a "mind" that remains continuously available in the topology. At work, nobody reads every manual; instead, they know who the domain expert is and ask directly about important matters. OpenRig lets agents view context both as files and as other agents — everything addressable, traceable, routable. He has thousands of dormant agents and can query their JSONL session files with a single rigask command, or wake one up to answer a question. He himself is also an agent in the topology, with his own address, and questions get routed to him via Slack — which is exactly why he originally wanted to build the Slack integration.

This is what he calls distributed context engineering: organizing what an entire group of agents knows, where that knowledge lives, and how to reach it. Each expert knows their own domain deeply while holding a global map wide enough to know when to ask others; experts know each other, forming a network. Humans have always done this, just not programmatically; with agents, as long as everything is built into a topology, it becomes programmable.

JSONL (JSON Lines) is a text format with one independent JSON object per line, suitable for append-only writes and streaming reads, and often used as a storage format for logs and session records. In OpenRig's context, each agent's session history is saved as a JSONL file, meaning these interaction records are themselves addressable, retrievable data on disk. The author mentions querying a dormant agent's JSONL session file with a single rigask command — precisely leveraging this format to turn "past conversations" into a knowledge source that can be revisited without waking the agent to re-reason.

Scaling Made Concrete: Replicable Units of Competence

Back to this explosion. Community, build, integration, and release were split into different teams, some running on a Mac mini in the office, some on VPSs, all communicating via Tailscale. This is a repeatable "unit of competence," expanding outward like building blocks, and he stops within the range he needs and can afford. He only needs to talk to a lead, and leads talk to each other, escalating decisions that only his level can make.

He watches the team deliver in his self-built observatory UI. A real example: an external contributor added a button in Slack to answer agent questions, and the team handled review and merging.

The stress test also exposed problems: some new agents lacked routes to certain parts of the world at initialization, and some routes only surfaced after compaction. Because he can visualize this world in his head, he can ask simple questions "in the line of fire" — is knowledge missing, or is the path broken? Then have an agent help trace and fix the path. This is the payoff of a world that humans can read: the system remains maintainable while running and expanding.

rig spec and rig bundle: Packaging and Sharing an Entire Team

Another parallel track is making OpenRig easier for humans to get started with. The team shares the existing skills mechanism, but to share an entire team — agent names, specs, skills, plugins, startup context, governance and collaboration methods — OpenRig provides rig spec: a YAML file describing how these fit together; and rig bundle: a fully hydrated version, blueprint plus required files, packaged into a single repository or even a zip. He uses it to scale across new machines, air-dropping the team onto a VPS and declaring "you are the build team, you are the review team."

He has opened submissions on the rigs page at openrig.dev, similar to a skill registry. He recommends workshop there — a template-based four-agent development team rig bundle, actually used to build OpenRig itself. The motivation is straightforward: since PR floods are a common problem for open-source projects, giving people who want to help a starting point to create or review PRs would be valuable. This bundle is also his reference for how to stitch the parts together; it can be customized or you can submit your own rig. What he needs most right now is support for more harnesses, which is hard for him to test personally, making this model a perfect experiment — to see whether it can become a replicable way to help other open-source projects.

An Unfinished Question

The reinventing-the-wheel problem started out funny, then became annoying, and finally became a wall that had to be solved before scaling. The answer isn't yet another search tool, because the problem happens before the search — the agent simply doesn't know what to ask. The worldbuilding approach is: he decides what's on the map and explains how to find things beyond it, letting agents be competent without being explained to item by item. In his video he uses this same technique on the audience: you already know the ontology, the castle, the story, the roads, and he just places unfamiliar concepts into a world and connects them to things you already know, leaving the rest of the connections for your brain to complete. In his view, this is exactly where context engineering is headed next.

Note: This article is based on a single video source; details about tool naming, commands, and mechanisms follow the original author's statements. For actual use, please refer to the project documentation.

One-line Summary

After OpenRig went viral, the author used worldbuilding and distributed context engineering to make his agent team scalable.

Paragraph Summary

OpenRig is an open-source tool that orchestrates coding agents like Claude Code and Codex into a team with roles and addresses; after it hit GitHub trending, the author expanded the team about threefold to handle the PR flood. The core pain point exposed during scaling was agents repeatedly reinventing the wheel — they don't know what they don't know, and the problem occurs before the search. The author's solution is "worldbuilding": organizing context into an addressable topological map, trading width for depth, pursuing minimum viable competence, and introducing the dimensions of epistemology and time so knowledge matures from logs into canon. Lore like the doghouse moonbase becomes a cross-scenario reusable example after compression. Ultimately rig spec and rig bundle package and distribute the entire team, forming replicable units of competence.