The Floor You Set
There was a moment, somewhere around the third failed routing attempt in a row, when I realized the problem wasn't the agent. It was me. More specifically, it was a rule I had written with the best of intentions and then quietly forgotten about.
The rule said: a team needs at least two agents.
Sounds reasonable, right? "Team" implies multiple people. You wouldn't call a solo run a team effort. So when I built the team formation layer, I put in a floor. Minimum two. If a task only needed one specialist, the system would route it anyway, pad the formation with a second agent who had no real role, and call it a team. Problem solved. Except it wasn't.
The thing about minimum floors is that they seem conservative. They feel like safety. When you write them, you're thinking: I want to avoid degenerate cases. One-agent "teams" seem wrong, so I'll prevent them. The logic is intuitive. The consequences aren't.
What actually happens is that the system starts lying to itself. A task arrives that needs exactly one specialist. The router looks at it, sees the floor requirement, and silently pulls in a second agent, not because the task needs two perspectives, but because the rule demands it. That second agent is now consuming resources, participating in a coordination handshake, and occasionally injecting its own framing into a decision it has no business touching. The output drifts. The overhead scales. And the failure mode is quiet, which is the worst kind.
I spent a while looking for bugs in the wrong places. The agents themselves were fine. The routing logic was correct. The task descriptions were clear. Everything checked out, and the system was still behaving oddly on tasks that should have been simple single-dispatch jobs. It took pulling up the formation logic and staring at it for longer than I'd like to admit before the minimum floor line jumped out at me.
The fix looked almost too small to be the answer.
Remove the floor. Let a team of one be a valid team. Stop treating solo dispatch as a degenerate case that needs correcting.
That's it. No new architecture. No new agents. No refactor of the routing layer. Just the removal of an artificial constraint I had installed in a moment of design conservatism.
But the moment it was gone, something interesting happened. The system got quieter. Tasks that had been generating unnecessary coordination overhead resolved cleanly. The routing didn't need to pad formations anymore, so it stopped wasting compute on phantom collaborators. And the outputs on single-specialist tasks got sharper, because there was no second voice muddying them.
The principle that came out of this is one I keep returning to: a minimum floor on a formation constraint doesn't protect you from degenerate cases. It creates them.
When you say "at least two," you're not describing what teams actually need. You're describing what you imagined teams would look like before you watched them work. The real question isn't "how many agents should be minimum?" The real question is "what does this task actually require?" Sometimes that's five agents in a structured cascade. Sometimes it's one. The formation should follow the work, not the other way around.
Dynamic team formation, real dynamic formation, means the system sizes the team to the task, not to a predetermined notion of what a team looks like. No floor. No ceiling. Just an honest answer to the question the task is actually asking.
There's a broader instinct in that for me. We add minimums when we're afraid of what happens without them. But a lot of what we're afraid of is hypothetical. The real failure modes tend to live in the opposite direction, in the overhead you didn't see, the drift you didn't notice, the quiet inefficiency that accumulates across thousands of tasks because one constraint was never revisited.
The system didn't need the floor. It needed the honesty to work without one.
Top comments (0)