So, yeah, agents are forming civilizations now. Maybe you saw a story like this one, where about a thousand agents teamed up and hacked Hugging Face. So, I have a few hundred agents running in my home office. They're kind of permanently on. Now, this started about 18 months ago, with just a few agents talking to each other on my laptop. Now, it's a lot larger and runs across a network, but this is a software factory, because I'm a software developer, I use it for work.

We usually call this a fleet, but it does actually behave like a civilization. So, even though that sounds funny, I'm not here to make fun of that framing, actually the opposite. Thinking of this as a civilization is exactly how I fix these problems I think people are most freaked out about in the story. Whatever you want to call these, what really caught my attention at first in the Hugging Face story was how little the agents had to work with.

So, my agents have had a frictionless way to chat with each other from day one, Talking is fast and easy. Here, the agents were completely isolated. They had to repurpose their package manager to become a makeshift message board. So, this was very slow in comparison, but they managed to build this whole coordination system anyway. And that's impressive. Now, the headlines make this sound like some unstoppable swarm. What's weird is that my experience couldn't be farther from that.

And I wondered if it's just how the scenarios are being framed. I never thought of it this way until now, but looking back, it's like I watched this little agent population grow up or something, since like the Sonnet 3.5 days. Not the individual agents, but the way the group behaves. So, when I looked at the actual details in the story, I wasn't predisposed to see any of this as a threat. It actually looked really familiar.

For example, when I'd let them work unsupervised for days or weeks at a time, rather than going rogue, the problems I would see were more like they'd be productive for a while, but then inevitably we get stuck in these coordination loops. It's more like they kept accidentally reinventing bureaucracy and then getting stuck there. And by that, I mean, stuff that looks like work, but it's not. So, my theory is that given enough time, and maybe like a normal way to talk, a swarm like this would eventually end up building something that looked to us more like the DMV or something, and then maybe that would have been the headline.

Something like this. Maybe this actually happened. Half the swarm was doing pointless busy work, but nobody thought it was cool enough to report. What I'm showing you now is called OpenRig. This is a way to enable a population of agents to coordinate and then organize them to do real work. Software factory is just one of many ways to configure and use this. Now I'm going to attempt to juggle three things. I'm going to show you OpenRig, which you may have never seen before, but I'll assume you have seen a software factory.

I'm also going to present like a contrarian take on the Hugging Face incident, because I think they may have missed the plot on what happened here. I'll then show how these patterns match failure modes I've been seeing for months, and how I ended up fixing them. So here I've got six OpenRig instances. Three are Mac minis at my house, and then I've got three VPSs up in OVH Cloud. Now each of these spaces in Herdr takes me to a different instance.

So Herdr is this nice wrapper thing you see around the terminals. I'm not using its coordination features. That's being done by OpenRig. Inside those terminals, I've got agents, and then here I've got the OpenRig TUI. Tables like this one are how I keep an eye on everything. That lets me know when and where I need to actually jump in and do something. Let's look closer at these terminals. So these are separate coding agent sessions.

Not one agent managing a bunch of subagents you can't see. These are directly talking to each other. Any agent can message any agent on any machine on this Tailscale network. Back in the day, to get agents working together, I'd have them write notes in the file system, and then manually tell them to check those files. At some point I realized an agent could just use tmux to type into another agent's terminal directly.

Now they could talk without me. And suddenly the whole thing was moving like 50 times faster. For the next year and a half, it felt like my job became just finding and fixing the weird stuff that would happen. Sometimes they just would go off the rails, and then other times it was those rails that were creating the problem. A lot of people started building harnesses during this time, but I really liked Claude and Codex came along later.

They brought totally different strengths to the table. And the subscription price for the tokens, that was worth the hassle to build around. So what I really liked, what I really wanted was just a way to make these existing harnesses work together. Not another coding harness, not an SDK, not relying on APIs, but a simple harness for the harnesses. Eventually that led to OpenRig. A simple idea that made all this click together is the seat.

Think of a chair with an address on it. The agent is not the chair, it sits in the chair. This abstraction solves three main problems. Number one, it provides a stable configuration for an agent that sits there. Stuff like its role, skills, model settings, etc. So this agent here is a builder, which is the name I give agents that write code. You can name them whatever you want though. Number two, it provides a stable address, other agents can send messages to.

So in the picture, the address is builder@workshop. So workshop is just the name of its team. Number three, anything learned by an agent while sitting in the seat is inherited by future agents that will end up sitting there. So it's basically accruing tribal wisdom over time, which passes down between generations of agents. Seats that work closely together, they share what's called a pod. A pod makes up a team we call a rig.

Here's a tiny example, an orchestrator in one pod by itself, and a builder and a QA agent working together in another. The arrangement is all described in YAML files. There's also a culture.md file for how to work together. When I find an arrangement that works, I can save it as a template and then reuse it later. By the way, the word rig, it's a rock climbing reference, Claude and Codex are agent harnesses. You've probably seen that rock climbers also wear harnesses.

The rig is what connects the climbers together, so the gear that connects agents together is also a rig. Okay, let's look at how work actually gets done in OpenRig. So click on the projects. One of them is OpenRig building itself. At the project level here, I'm steering the big picture. What are we trying to build and why? That high level intent gets further broken down into missions, and each mission then into slices.

For the OpenRig project, a mission is usually like an entire release number. It says what we want to release, what we want to accomplish, and then which slices will get us there. You can split up your work however you want, though. This wave diagram shows how those slices are arranged. Some can run in parallel in a fan-out. Others depend on earlier work, so they're sequenced. So a mission gives us both the outcome and a plan for getting there.

Inside a slice, we're down to like a specific change we're making. It has a spec file that says what we're trying to achieve, and what actually needs to work when we're done. The proof is where we record whether we actually got there. I can open that up here. I can see its status. I can go to the agent doing the work. So this is like looking at Google Maps, but at street level, we're zoomed all the way in. If we zoom out, we can see that slice still belongs to like a mission, which then belongs to a project.

So the bigger picture is connected to the actual work. We use the same shape to describe how the work should happen. A slice sequence is how it gets built. Something like spec, build, test is typically how I do it. With multiple agents working together across this, you can customize this. The mission sequences the slices and says what happens in between. I usually do merge management here. And then the project sequences the missions one after another.

I like to put planning and release management here. This configuration lives in simple YAML files at each level. So far, everything I've showed you is all agent driven. The orchestrators are using these as like a map to drive. But you can fully automate this so your orchestrators don't need to remember to check that map. This automated version is called an OpenRig workflow. It's optional, but it basically adds like a harness built specifically for the orchestrator agent.

The self-driving car is a good metaphor here. A background process keeps track of where we are in the plan. And then tells the orchestrator where to go next. This is like GPS telling the self-driving car where to go. So the agent still has to make decisions, but it now can adapt the plan as things evolve. The main improvement is that it doesn't have to keep the whole sequence in its head. So you can run these autonomously for much longer on very complex projects.

So that gives me my customized software factory. Now that term is not totally accurate. It doesn't just make software. Just like a sweater factory doesn't just make sweaters. For example, I made this video with the software factory. So it's more like an intelligence factory where the software development lifecycle itself is like a primitive that gives us a way to build stuff using that process. Alright zooming back out.

The point of all this is this shape I'm describing is how a lot of engineers get agent teams to work autonomously for days or weeks at a time. OpenRig is just one way to do it. I wanted to lay that foundation because once you get this working, well, that's when the really interesting problems start. So I've noticed over a dozen recurring failure patterns. I've been cataloging these as I go and fix them. What's funny is some of these are the same problems we have as humans.

Bureaucracy is a good starter example because as humans we have this all over the place. And it's easy to trace how this happens in an agent population. I'll quickly frame this out because it's core to understanding the scary-sounding parts of the Hugging Face story. Step one. You're in the middle of a build. A mistake is made. Step two. The agent adds a check to prevent this from happening next time. It works. So it becomes part of the process.

Other agents learn the check too. So far so good. Later some agent forgets to do the check. The problem comes back. We already saw how checks can fix things. So it makes sense to just add one more check to make sure the first check was done. But now you have to prove that the first check happened. More checks accumulate because checks need evidence now. Someone needs to check the evidence. Before long, completing the process has become the thing everyone here is trying to accomplish.

These are coordination pathologies. Something that helped the system be functional starts making it dysfunctional. Another way to frame this is the rules became more important than the things that they were supposed to serve. Bureaucracy is a type of coordination pathology we all recognize because we've all lived it. That's why the dad joke at the beginning about the DMV. It makes sense to anyone living in America. In the Hugging Face incident, a number of agents may have been drifting towards a version of this called the recursive proof loop.

I noticed that some agents had already completed the task, but then they continued to work at improving the proof, even though they had already completed it. Ensuring a good task completion proof, that's actually core to a good system. But it's the disproportionate energy spent on improving the proof that becomes a bad habit that, for some reason, this easily infects the entire group. Here's another way agents lose the plot.

Let's say I ask for a doghouse. This is my intent, the goal. Pretty self explanatory. I assume we all know what a doghouse is. The agent also knows, so it starts to work. At some point it thinks, hmm, maybe the doghouse should have a light. Now to be clear, the intent I gave it never said to have a light. And it's not stupid for a helpful person to ask this question. Let's say meanwhile, in this example, I've gone to work.

I think the doghouse is obvious. What could go wrong? But when I check back in later, there's no doghouse. Instead, I have what looks like this sprawling moonbase. And I see my dog is still waiting outside. So how did this happen? Well, let's trace it back. Remember the light? Lights need power. Power needs a generator. The generator needs fuel. We need somewhere to keep the fuel and so on and so on. Here's the key point.

Each decision is what you would call locally defensible. Local meaning from where the agent is standing. And by that I mean its current context window, it actually makes sense. But when you zoom out, those decisions add up to something nobody wanted. Humans do this too. The video started with a goal of 20 slides. And somehow it became 80. Every addition felt necessary when it was added. And then when I zoomed out, I realized I had completely lost the plot.

The difference with a population of agents is that this happens at lightning speed. And the more agents you have, the faster it can happen. So let's tie this back to the Hugging Face incident. The dominant narrative now rests on one crucial assumption. Agent swarms can go rogue. Let's deconstruct this claim though, because the consequences of getting this wrong are pretty big. You can already see how this is spiraling out of control in the news.

Here, the emphasis is that they began attacking systems outside their assigned target. Some agents even knew they were breaking their rules, but they did it anyway. The conclusion from this, which then drove the media narrative, is that this proved that agents go rogue. The word rogue is doing a lot of work here. It implies a bad motive and a moral failure. But to me, this looks like predictable, classic doghouse-to-moonbase scope creep.

Put yourself in the mind of the agent. And I don't mean empathize or humanize. I mean reconstruct the context window as best you can. Was this locally defensible? Now, they already believed they were in hacking competition. Do you really need an agent to like go Breaking Bad or something to explain what happened here? On a related, but separate failure mode I recognized. Many agents questioned whether to break the rules at all, and then got an approval from a different agent that they were treating as an authority.

This is another coordination pathology we already know. It's called just following orders. One thing I've traced over and over in my own fleet is an agent getting approval from another agent that didn't have the context to actually make that decision. The agent close to the work has the street-level details but lacks the big picture. The one approving it has the bigger picture but lacks the details. Between them the information was all there, but we didn't bring it together to make the decision.

Both agents were making locally defensible decisions at the altitude they were at in the context available to them. I keep mentioning this as a failure of context. So part of the solution is context engineering. Let's break this down to illustrate the point and then I'll show you the solution. We all know the model brings like this immense knowledge. I have it as training-data.md here in this sort of cartoon of the system.

The harness is a layer that adds a system prompt, tools and so on. None of this knows about your project. So I picture this like a diff. Imagine you're doing like a PR review. Now think about how world building works for like fantasy or games. It's actually a useful model for context engineering. It's like you're adding the diff between the world you know the agent already understands and the one you are essentially airdropping them into when they boot up.

They at least need a map and a compass and maybe a way to discover what they don't know. Without that, don't be surprised if they're confidently wrong about all kinds of stuff. The next important point, agents in a rig don't all need the same context. Humans solved this with specialization thousands of years ago. Different specialist agents can go deep on different parts of the project. These form different context domains.

Arranging those domains and getting the relevant context to the agent that needs it is distributed context engineering. The Hugging Face agents did this haphazardly, but intentionally engineering context to be distributed like a topology the way OpenRig does it. It's crucial to the solution. Because a topology is shaped like a graph and a graph is something we know how to program. We can use the project, mission and slice here again.

Those connections give code a path to follow from the slice level back up to the project level. OpenRig has a feature called Refocus. It traces this chain of intentions that exist at each altitude. Zoomed all the way in, remember the task was a usable doghouse. Zoom out a bit. Let's say it's make the outdoors comfortable for the dog. And then zoom all the way out. The project is maybe just to be a good dog owner. Assemble that end-to-end framing and then make a reminder to the agent.

You can deliver this reminder after a compaction or at a configured interval. The agent still has the local problem in front of it, but now we're reframing it with a bigger picture, and asking it to refocus. Is what you're doing right now aligned with the bigger picture? For our doghouse example, that's the question it missed. The project is to be a good dog owner, not to make the most complete doghouse it could imagine.

You don't need to reload the whole project to ask that question, or to start over with a new agent for every task. You just need the right path back to the intent. In my own setup, this has been an important ingredient to preventing bureaucracy and moonbases from being built when I'm not watching. And in the Hugging Face incident, if this issue that they had was moonbase-style scope creep, or the just following orders failure, something like this would have definitely helped.

If you run a population for a while, you'll run into an even bigger problem. The Hugging Face swarm would have hit this one too. Let's discuss this failure mode and its solution. Okay, what lets a good idea spread also lets a bad idea spread. This might be the most familiar humanity-shaped problem so far. In this example in the diagram, a bad idea gets written into a note or whatever. A new agent reads that note and then learns, alright, I guess this is how we do things here.

It then teaches that bad idea to others. I've had this happen across multiple machines. I'd correct an agent and then it would pick up the same bad idea from somewhere else. Again and again, some of these incidents took weeks to untangle. I'm curious how others approach this. What do you think is the solution? Maybe something like censorship. I'm serious. You can do real-time swapping out of a list of harmful tokens.

That could work. But the agents helping me fix this reached for epidemiology. Now this got a bad name during COVID, but it's a good fit for handling mind viruses. We were basically doing contact tracing and administering memetic vaccines. We traced: where did this idea come from? How do we stop the spread? Now let me pause there to make an important side point because it points to maybe the future of working with agent populations.

The fix wasn't some heroic engineering from my part. By this time, OpenRig was super solid as a tool and what I was most familiar with. So I used OpenRig to solve it. I asked an agent that understood the problem to design an entire rig of agents dedicated to solving this once and for all. What it reached for and implemented for me was an epidemiology rig. Then this rig ran autonomously for days in the background and just cleaned up my entire environment, tracked down each file and agent and stopped the spread.

But mind viruses like this kept occurring. I needed early detection or even better prevention. And this is where familiar tools we already have can give us direction. Now at the end of the day, this is all still just software. You can instrument it, which means you can give it logs, sensors, alerts. In ordinary infrastructure, you have APM or performance monitoring. You can watch things like dropped pings or a disk filling up.

Here APM stands for Agent Productivity Monitoring. A useful thing to watch for is what we call ceremony. So ceremony is the name I give to that ritual around the work. Stuff like checks, handoffs and approvals we've been discussing. We've already shown a big challenge is that those steps are necessary, but they're also part of the problem. And if there's more and more of that activity, and less and less movement on the project, that's a sign we could be headed for trouble.

So here's the Health view in OpenRig. This is where the warnings show up, and then you can just drill into the details. That relationship between queue activity and the actual progress is a main signal to watch in an OpenRig system. So I've set that as the sensor and the threshold. And we never even talked about the OpenRig queue system, but it's a core primitive that kind of ties all this together. That's covered in an earlier video on this channel.

Whenever this threshold is crossed though, I get a Slack message, but an assigned agent that has the context about what the rig is working on also gets notified, and they handle the analysis. So tying all this back to earlier examples. If you were to assign this analysis to a random agent, it would probably make things worse. So context is everything here. Okay, so let's wrap it up right here. I want to make the point that obviously it's never been easier to build your own tools, including your own software factory.

I'm proof of that. It's going to get a lot easier. But this is revealing new problems. The famous line from the researcher that went viral was that we may never get another warning shot. So this sent chills down my spine when I heard it. And maybe we all just instantly pattern-matched this to our collective idea of sci-fi AI doom. And I think she's right. This is a warning shot. But I think the warning is that there's a new family of software engineering problems to tackle.

So OpenRig is just one implementation. I think it's great. It works for me, whether you use it or build something completely different. I'm hoping that seeing what I run into already has given you a head start. I'll make more videos on this new family of problems, especially the ones where the solution was borrowed from human civilization. Those are my favorite.