From One Agent to Three: Splitting a Generic ChatClient into Specialized AI Agents

#ai #mcp #rag #springai

Why giving an AI assistant one job — instead of every job — makes it dramatically better at all of them.

One model. Every question. What could go wrong?

When you start building an AI assistant, the natural move is simple: spin up one ChatClient, write a system prompt that covers everything your app does, attach all your MCP tools, and let it handle whatever the user throws at it.

It works. At first. But as the product grows, cracks appear.

Three things go wrong as the system grows.

The model wastes attention tokens processing tools it will never call for the current question.

The system prompt expands to cover every domain — FAQ policies, property search filters, reservation rules — and starts to contradict itself.

And perhaps the sneakiest problem: a customer who just searched for three-bedroom apartments in Lisbon suddenly asks about cancelling a reservation, and the model's short-term memory is still full of property data.

The core problem: Shared context means reduced focus. The model divides its attention equally across everything it was told, whether relevant or not.

Think like a company, not like a monolith

Imagine you call a real estate agency and a single receptionist answers every call, handles every topic, and takes every note in the same notebook. They're busy, often confused about what they told which caller, and occasionally give FAQ answers when you asked a property question.

Now imagine the agency has three dedicated desks, each with their own specialist, their own file cabinet, and their own calendar.

When you call, a receptionist hears your request and routes you to the right desk. You get a faster, more accurate answer because the specialist you reached doesn't have to mentally filter out the irrelevant stuff.

This is exactly the architecture we're building. Each AI agent is a specialist with a bounded scope. The router is our ChatService.