Essay
One Agent Per Business Unit or One Agent For All
You're building customer service agents. The question is whether you build one agent that handles all business units or separate agents for each unit. The answer depends on how isolated your business units actually are.
You’re building customer service agents. The question is whether you build one agent that handles all business units or separate agents for each unit. The answer depends on how isolated your business units actually are.
You’re building customer service agents. The question is whether you build one agent that handles all business units or separate agents for each unit. The answer depends on how isolated your business units actually are.
If your business units share nothing—different products, different processes, different customer bases—build separate agents. If they share most things and only diverge on minor details, build one agent with unit-specific context.
Most organizations lie somewhere in between and get this decision wrong by defaulting to either extreme without examining their actual structure.
Your company has a B2B enterprise software division and a consumer mobile app division. These aren’t variations of the same business. They’re different businesses that happen to share a parent company.
Enterprise customers ask about contract terms, implementation timelines, and integration requirements. Consumer customers ask about subscription cancellations, feature requests, and password resets. The vocabulary is different. The escalation paths are different. The knowledge required is different.
Building one agent for both creates a context problem. Every enterprise query loads consumer knowledge. Every consumer query loads enterprise knowledge. The agent becomes mediocre at both because it’s spending capacity on irrelevant information.
Build separate agents. The enterprise agent knows contracts and implementations. The consumer agent knows subscriptions and features. Each performs better because each focuses on its actual domain.