The N+1 Problem in AI Agents - Everyone Wants Agents That Automate Other Agents

You build an agent that automates browser tasks. It fills forms, clicks buttons, navigates pages. The first question you get is always the same: can it automate other agents?

This is what we call the N+1 problem. You solve layer N - automating applications - and immediately everyone wants layer N+1 - automating the automators. It sounds reasonable until you try to build it.

Why the Layer Skip Fails

An agent that controls apps needs to understand UI elements, timing, and state. An agent that controls other agents needs to understand all of that plus the internal logic, failure modes, and recovery strategies of the agents it is orchestrating. The complexity does not add - it multiplies.

Think about it practically. Your browser agent clicks a button and waits for a page load. An agent-of-agents would need to tell the browser agent to click the button, monitor whether the browser agent succeeded, handle cases where the browser agent misinterpreted the instruction, and retry with different phrasing if needed. You have not eliminated work. You have added a translation layer that introduces new failure modes.

Nail the First Layer First

The agents that actually ship and work well are the ones that do one thing reliably. They automate a specific workflow end to end without needing a supervisor agent. The orchestration layer becomes useful only after the individual agents are rock solid.

We see this pattern in every mature automation ecosystem. Kubernetes did not start by orchestrating other orchestrators. It started by managing containers well.

If your agent cannot reliably fill out a web form without human oversight, adding another agent on top will not fix that. It will just make the debugging twice as hard with half the visibility.

Build the layer that works. Then think about stacking.

Fazm is an open source macOS AI agent. Open source on GitHub.