There is a part of every large revenue organization that is structurally unprofitable to serve with humans. The long tail of customers. Thousands of small accounts, each generating modest revenue, each requiring the same onboarding, billing support, upsell conversations, and renewal management as the largest customers. The unit economics never work. The struggle is always between whether you underserve these accounts, or you overinvest in them, and either way the P&L suffers.
I spent years staring at this problem. At a large P&L I led, the small business segment represented an enormous number of accounts but the revenue per account made human coverage economically impossible to justify. I was leaving money on the table at scale, and I knew it. The segment was growing organically but not nearly at the rate it should have, given the size of the market opportunity sitting in front of me.
The decision to build an AI agent to manage that segment end to end was one of the most consequential revenue decisions I made. The agent handled onboarding, product recommendations, billing queries, basic troubleshooting, and proactive outreach when usage patterns signaled churn risk. What happened next was not what I expected. The segment did not just become more efficient to serve, it doubled. The agent materially reduced cost to serve, while surfacing a revenue opportunity that human coverage had structurally prevented me from capturing. The accounts were there, the demand was there, but I never had a scalable way to reach them.
That experience fundamentally changed how I think about where agents create value in a revenue organization. The right question is not where AI can automate tasks, it is where an AI agent can deliver revenue outcome because human coverage does not scale.
What needs to be in place before you build
Three things are non-negotiable before deploying a revenue-facing agent.
First, your product and pricing data must be current, accurate, and accessible to the agent in real time. A customer-facing agent quoting the wrong price or describing a product that was updated six months ago is not a technical failure you can quietly fix. It is a commercial and reputational problem that lands with your customer immediately. In my experience, most organizations significantly underestimate how much work it takes to keep the knowledge base an agent draws from, genuinely current. This is the piece I would invest in first and most heavily before anything else.
Second, you need documented workflows for the scenarios the agent will handle, and equally important, clear escalation paths for the scenarios it will not. The biggest risk is not the situations your agent handles well. It is the situations it has not been trained for, where without a defined escalation path, it will either hallucinate an answer or get stuck in a loop that frustrates the customer. Every revenue agent needs a human in the loop or, at minimum, a human audit layer for edge cases.
Third, access to billing and finance systems must be governed carefully before an agent touches them. The permissions question, what can the agent read, what can it write, what requires human approval, needs to be answered explicitly before deployment, not after the first error surfaces.
What I deprioritized at the start was perfection. The goal of the first deployment was not a flawless agent. It was a good enough agent that handled the highest volume scenarios reliably, learnt from real interactions, and earned the right to be expanded over time. I reasoned that an 80% accurate agent deployed today with a feedback loop would generate more value and more learning than a 95% accurate agent still in testing six months from now. And that bet paid off.
Managing risk when the agent faces your customer
A revenue-facing agent carries a different risk profile than an internal tool. When it gets something wrong, the customer experiences it directly and immediately.
The risks I have navigated most in practice are wrong pricing, outdated product information, hallucinated answers to questions outside the agent’s knowledge base, and inappropriate handling of billing disputes. None of these are inevitable but all of them require specific design decisions upfront.
I deliberately kept the agent’s scope narrow at launch. I defined precisely which customer interactions it owns and which it hands off. I built explicit triggers for human escalation: billing disputes above a certain value, complaints that include specific language, scenarios that fall outside documented workflows. And I built a monitoring layer from day one that flags interactions for human review systematically, based on signals that predict a poor outcome rather than random sampling.
Treat the first three months in production as an extended test. The real world will surface scenarios you did not anticipate. The organizations I have seen scale agents successfully invest as much in the feedback and correction loop as they do in the initial build.
One agent or many
My strong recommendation is to start with one. Multi-agent architectures, where several specialized agents hand off tasks between each other, are powerful but they almost always require changes to backend legacy systems that take months or years to complete. I have watched agent projects stall before they deliver anything because the team pursued a multi-agent design from day one.
A single well-scoped agent with clear ownership, a defined set of scenarios, and a human audit layer will teach you more in three months of production than a multi-agent design will teach you in twelve months of planning. Once the single agent is performing reliably and you have a clear picture of where its boundaries are, the case for a second agent, and what it should do, becomes obvious from the data rather than theoretical.
The goal at the start is not to build the most sophisticated architecture. It is to put something in front of real customers, learn fast, and earn organizational confidence before you scale. That is how a neglected revenue segment becomes the fastest growing one.