The first agent is the fun part. You set it up, give it a soul, wire in a few channels. It starts doing things. You get the feeling.
Then you want a second one. Maybe you want to keep work and personal separate. Maybe you want a dedicated coding agent that doesn't know anything about your calendar. Maybe someone on a forum said it's the right way to do it.
So you set up agent two. And that's when things get weird.
The binding config is twice as complex. You're not sure which agent is handling which message. Something breaks in agent one and you don't know if it was agent one or if agent two touched something it shouldn't have. You're burning tokens in two context windows simultaneously, including when both agents are idle. You type /status and get two different answers that contradict each other.
This week the most upvoted post on r/openclaw (352 votes, 66 comments) was a breakdown of the five mistakes that show up in almost every OpenClaw setup. Mistake number five: adding a second agent before the first one works. The author's advice: don't create agent two until agent one has been stable and useful for at least two weeks. Every agent you add is a separate token consumer even when idle. Every agent complicates debugging because you're never sure which one is causing the issue.
The advice is correct. But it's treating the symptom.
The reason two agents are hard is that nothing manages them. There's no native health monitoring. No unified view of what both agents are doing. No way to set different model defaults per instance, or route messages cleanly, or see when one agent has gone quiet because something broke. You're running two separate processes and hoping they don't interfere with each other.
This is exactly the problem that multi-instance tooling is supposed to solve. Not "add more agents" but manage the ones you have. Dedicated profiles so each instance has its own config and model defaults. Isolation so a bad context in one doesn't leak into the other. Visibility so when something breaks, you know which one.
The second agent isn't the mistake. Running two unmanaged agents is. There's a difference, and it's worth understanding before you either give up on multi-agent setups entirely or spend another week debugging why agent two is eating agent one's messages.
One agent doing everything is one kind of problem. Two agents fighting over the same config is another. There's a third option.