The all-purpose agent isn't an architecture. It's a single point of failure with a system prompt.

Intro

In a demo, one agent that "does everything" looks like impressive economy: one prompt, one API call, one mental model. Nobody's testing it against thousands of edge cases a day, and nobody's paying for the tokens burned parsing forty unrelated instructions to answer a two-line question. In production, that same design is where teams spend their first real outage. Below are four failure modes that show up once a monolithic agent hits real traffic. (Illustrative composites, not case studies from a specific client.)

The system prompt that nobody can safely edit

Picture a support agent that started as "answer product questions" and grew, feature request by feature request, into a 4,000-word system prompt covering billing, refunds, technical troubleshooting, and tone guidelines for three different customer segments. Adding a new instruction for edge case #41 quietly changes how the model handles edge case #12, because both are competing for the same attention budget in the same call. Nobody can point to which line caused the regression, because there's no isolation between concerns, only proximity.

Every request pays for capabilities it doesn't use