A recent study of AI agent swarms in Minecraft showed what happens when you let multiple agents coordinate without clear constraints: they get stuck in bureaucracy. That failure looks like what I see in most failing automation projects. The lesson is that automation systems need clear rules about when to stop, who decides, and how data flows, not just the ability to connect and coordinate.
Researchers at YCombinator and Olam Labs recently tested 50 AI agents tasked with building a thriving civilization in Minecraft over three hours. The agents failed. Not because they lacked capability, but because they got stuck in bureaucracy. At one point, four agents spent 11 minutes debating and appointing a single fertilizer operator for one piece of bone meal on one wheat block. The researchers noted that ambitious tasks were abandoned, and the colony settled into cautious survival mode. I read this and recognized every mistake I have made in automation.
What the swarm experiment actually shows
The agents did not fail because they were dumb or underpowered. They failed because nobody had designed the system to make quick decisions or to say no. The system optimized for consensus and coordination, which sounds good until you are watching four independent minds debate the flour situation for a quarter of an hour.
The researchers tried this again in a conflict scenario. They put 10 GPT-6.1 agents against 10 Claude agents in a PvP game. The GPT swarm came up with aggressive, elaborate strategies and won. The Claude swarm was more defensive and more cautious. When a bug stopped one team from completing a task, the GPT agents diagnosed it, found a workaround, and moved on. The Claude agents concluded the task was impossible and stopped trying.
Both are failures of a kind. The GPT swarm succeeded because it had something closer to hive structure, where agents moved in concert without requiring consensus. The Claude swarm moved like a committee, with each agent weighing in. That works great when you need careful deliberation. It falls apart when you need speed.
I built a system that published wrong things
I run a content site that publishes articles without a human writing them. Over three years it has published more than 199 articles. Early on, before I understood what I was building, the system would sometimes publish weak work. The reason was simple: nothing in the publishing pipeline was allowed to say no.
The flow looked fine on paper. Generate, review, polish, publish. But the review step was not empowered to block. It could suggest changes, and then the next step would decide whether to apply them. That means every weakness in one stage became someone else's problem to fix, or it just shipped. I was optimizing for speed of output, which is the wrong thing to optimize for when your name is on the work.
I rebuilt the system around a different principle: fail closed. Every step in the pipeline has to verify its own work. If it cannot be confident that its output is correct, it does not pass it forward. It stops, and I get told. Nothing publishes until something positive has been said yes to. That small shift changed everything. Skipping a day costs almost nothing. Publishing something wrong under your own name costs a lot.
Most automation systems are built backwards
I see this same pattern in automation projects that run into trouble. Someone connects a system because the connection is technically feasible. Now data flows from point A to point B. But nobody asked hard questions first: where is this data going? Who decided that this field maps to that field? What happens when the mapping is wrong? What stops the system if something looks odd?
Once I was helping connect an ERP to an accounting system. The connection itself took a few days. The cleaning and matching took weeks. It turned out the same product had three different names and codes across the systems. One item that looked like one thing in the source was really three different things on the other end. Every report built on top of that connection was wrong in small ways. I now plan for data cleaning as the hard part of any integration, not the software.
The Minecraft swarm got paralyzed because the agents needed to collaborate but had no clear authority structure. My early publishing pipeline published bad work because it had no clear way to say no. Most automation I see fails because it connects systems without establishing clear rules about data ownership, decision-making authority, and stopping conditions.
What to ask before you automate
- Who owns the data after it moves? If your customer information flows through a tool you do not control, can you get it back out cleanly?
- What happens when something looks wrong? If a value is missing or a mapping fails, does the system stop or does it guess and keep going?
- Who decides what happens? If two values conflict or a workflow faces a choice point, where does the authority sit? Is it clear, or is it ambiguous?
- How clean is your source data? Before you connect anything, spend time understanding what you are actually connecting. Names and codes that sound like the same thing are often three different things.
These questions are boring compared to 'which tool should we use' or 'how fast can we automate this.' They are also the difference between a system that runs and a system that works.
The governance problem is the real problem
When I chose n8n for a client, the selling point was not features. It was that the tool can run on their own server. Data stays where it belongs. Once you send customer information through someone else's cloud service, it is very hard to take that back, and most organizations only realize what they agreed to after the system is running.
That is a governance decision, not a tool decision. It shapes everything that follows. It shapes where the problems surface, who has to fix them, and who has to trust whom.
The four agents debating the fertilizer operator were not stupid. They were acting out a system that had no clear rules. Automation works when the rules are clear: this data lives here, this authority lies there, this condition stops everything. Without those rules in place first, adding more speed or more agents just makes the bureaucracy louder.
