We're Scaling CS Wrong.
We don't usually reshare other people's content on this blog. But when Daphne Costa Lopes published this piece, we felt like we had to.
As one of the leading voices in customer success, Daphne makes the case that the CS org structure most of us are running is fundamentally broken, and that the fix isn't optimization. It's a rebuild.
What she describes in the architecture section is exactly what we're building at Agency. The context layer, the execution layer, the orchestration layer. These aren't abstract ideas. They're real, and the technology to do this is here now.
If you lead a CS team and you've been wondering why the current model keeps falling short, read this.
Written by Daphne Costa Lopes.
Originally published in the Unconventional Growth newsletter.
What if your CS org structure is wrong for the world you're now operating in?
It's an overwhelming thought, but I think it's time we admit that we've outgrown it.
The CS org most of us have was built for a different era.
One where the economics made sense: hire humans, assign accounts, and the coverage ratio determines who gets attention. Enterprise gets high-touch. Mid-market gets some. Long-tail gets a welcome email and a help centre.
It never worked. Retention dropped the further you went down the segmentation.
But we had to accept it, because there wasn't a better option.
That's no longer true.
I keep hearing the same conversation everywhere I go.
- Brian Halligan and Jack Dorsey discussing a circle org model with AI at the centre and humans at the edge doing specialised work.
- Elias Torres building proactive CS agents at Agency, with a new role emerging: the agent who manages other agents.
- Asana hiring for a Head of Customer AI Transformation to bring about a new model designed for consumption, not seats.
- Kieran Flanagan arguing that marketing teams need a full rebuild with context as the foundation, execution with agents and craft specialists in the middle, and orchestration to manage the system.
Nobody is talking about optimising what already exists.
They're talking about rebuilding from scratch.
So what does that look like for Customer Success?
The Model That's Breaking
The current CS model has a basic economics problem. You hire humans, assign them accounts, and the coverage ratio determines who gets attention.
- Enterprise customers with big contracts get high-touch.
- Mid-market gets some touch.
- SMB and long-tail customers? They get a welcome email and a help centre.
It sucks that we've normalised ignoring such a huge portion of our customers.
We call it "scaled CS", and we make it sound intentional. But the reality on the ground is grim. Thousands of customers your business spent so much money to acquire get no proactive engagement, and then start churning.
These are customers who bet on your business.
And they are failing, not because your product isn't good, but because no one ever showed them how to get value from it, or noticed the early warning signs of change, or helped them connect the dots between what they bought and the outcome they actually needed.
They never got a customer success experience. They got nothing.
And if we keep the same structure, we will keep doing this to our customers. Because if we don't change how we think about CS teams, we can't help but segment them into how much each spends, and allocate resources accordingly.
The Architecture That Changes This
I've been thinking a lot about what an agentic CS org would actually look like. And I don't think the structure is too dissimilar to what Kieran Flanagan proposed in his LinkedIn post.
Layer 1: Context - The intelligence foundation that everything else runs on.
Pre-AI, this lived in your CSMs' heads and walked out the door when they left. In an agentic org, it's a shared, continuously updated system. Every action feeds back in, and it gets smarter every day.
Most CS orgs don't have a clean intelligence foundation.
Customer data is scattered across CRM, product analytics, support tickets, and Slack threads. Before you can deploy agents effectively, you need a system that aggregates and structures that intelligence in a way agents can act on.
Getting this right isn't just about connecting data sources to an LLM; it's about an AI-ready data infrastructure that understands your organisation, relates contacts to companies, links email conversations to in-app behaviour, and applies the right models to each problem. That's why specialised products like Agency exist (and why I think they'll win in this space, vs. generic tools like Glean).
Layer 2: Execution - Where the work gets done.
It's not good enough to surface data signals. You need to act on them.
This layer of execution is where agents and humans live.
An Onboarding Agent runs activation sequences from day one. A Success Planning Agent builds and monitors success plans. A Risk Agent flags health deterioration before humans spot it. A Growth Agent surfaces expansion opportunities. A Renewal Agent manages the commercial close. A Relationship Manager Agent maintains personalised touchpoints across the whole book.
We should think less about the segment and more about the jobs to be done.
Yes, you'll still want to leverage humans for your high-stakes situations and high-value customers, but the jobs need to be done independently of the customer size. For many jobs and customer sizes, you'll use autonomous agents.
Layer 3: Orchestration - The 6,000ft view.
Someone has to manage the system. Not the accounts, the system. Routing decisions, output quality, ensuring agents read from the right context, and flagging where humans need to step in.
In the future, this is not a new kind of CS operations role, it's another agent.
Combining a system of intelligence with a system of action and orchestration is where the magic happens.
Layer 4: Leadership - Setting the direction.
If agents can do so much, what's the job of leadership?
The CS leader's job is to set the direction for the system. Coordinating a team of agents and people to achieve a specific strategy for the business.
That's a fundamentally different skill set than the average CS executive today. It rewards systems thinkers who understand both the customer journey, humans and how the mechanics of how agents operate.
What doesn't change is that the CS leader owns the outcome.
If this looks far-fetched right now, look again.
The technology to deliver this is moving quicker than you think.
What This Means for CS Teams
- Start with the context layer, not the agents. You can't build good agents on bad data. Audit what you actually know about your customers and where that knowledge lives.
- Your long-tail customers should be the proof of concept. They have nothing to lose and everything to gain. If the agent layer works for them, you scale. If it doesn't, you learn cheaply.
- Orchestration is not a choice. Too many agents without orchestration becomes AI slop. If you don't design this role explicitly, it gets messy quickly.
- Human coverage should be allocated by impact, not account size. The question isn't "how big is this account?" It's "where does human presence change the outcome in a way an agent can't?"
The Bottom Line
Every CS leader I know is under pressure to do more with less. The instinct is to optimise the existing model with better tooling, tighter playbooks, and smarter segmentation.
But the existing model has a structural ceiling.
You can't hire your way to coverage across a large, diverse customer base. And you can't automate your way there with bolt-on AI.
The orgs that figure out how to build a genuinely agentic CS function won't just be more efficient. They'll be competing on a different basis entirely.
The question isn't whether to rebuild. It's whether you're going to do it on your terms or scramble to catch up later.
I'd start now.
