We onboard CSMs for months. We onboard agents in an afternoon.

Scaled customer success programs automate the customer-facing half of a CSM's job. They skip the half that comes first: gathering the context that work runs on.

The hard part of enabling AI is not the AI. It is getting the context ready for it.

I have been in the business of building post-sale customer intelligence platforms over the last 7 years. Having interacted with many successful CSMs through my career, one thing I consistently observed is that they have a perfect combination of deep knowledge of their products and at the same time are good at speaking the language of their customers. They understand the customer's business problems, and they do everything at their disposal to make their customer successful on the customer's own terms. They apply multiple contexts simultaneously at every point of their engagement: customer problem, product, relationship, revenue, retention. They ultimately cultivate a symbiotic business relationship between their employer and their customer. While customer retention and revenue protection is an obviously stated goal that both parties understand implicitly, it almost happens as a side effect.

That combination takes months to build in a human. We are now asking software to arrive with it on day one.

The half of the job nobody could see

In most of the scaled customer success conversations I have been part of, the discussion starts and ends with the visible half of the CSM's job. The customer meetings, the adoption pushes, the QBRs, the renewal conversations. That half is legible. It sits in calendars and workflows, and it is reasonable to look at it and conclude that a good portion of it can be handled by software for the smaller accounts.

The CSM has a second half, and it was never visible to anyone, including the leaders who managed it. Before a CSM says anything useful to a customer, they have spent weeks gathering intelligence. From account teams, support engineers, product managers, industry reports, telemetry, the customer's own staff, and half a dozen internal systems that do not agree with each other. Some of those sources are systems. Many of them are people, and what those people know was never written down anywhere.

The engagement half runs entirely on the output of the gathering half. Automate only the first and you get an agent that is fluent and has nothing to say.

Customer success thrives on context

CSMs are typically assigned to customers who purchased a broad portfolio of products and who deployed large footprints of those products. This is not just an economic or ROI decision, it goes beyond that. For a CSM to exercise meaningful influence in a customer's success, they need to have enough leverage. Their products should be playing a role that is significant enough to move the needle in the customer's business. In other words, there has to be enough context aligning the business goals of the vendor and the customer. A point product sale may have some impact on one of the customer's IT goals, but it may not have enough impact on the customer's business goals for a customer success manager to influence the customer.

Now look at where we are pointing our agents. Scaled programs are aimed at the small footprint accounts, the ones that never justified a named CSM in the first place. So the agent inherits precisely the accounts where context is thinnest. Fewer products deployed, less telemetry, no discovery calls on record, no relationship history, no success plan. We are handing the hardest context problem to the newest member of the team.

That is the real challenge in agentic scaled CS, and it is not a model problem.

To be fair, agents already do some things better

I do not want to argue that agents are a weaker substitute for CSMs. In several respects they are already better.

They provide coverage at accounts a human would never touch. They do not forget. Nothing is lost when a territory gets reassigned or when a CSM leaves. They apply the same standard to account number 4,000 as they do to account number 4. They are available when the customer is working, not when the CSM is working.

Those are real advantages, and they are the reason scaled CS is worth building. Agents do not fail because they lack capability. They fail because they lack context. Which brings me to the question I actually want to ask.

Agentic scaled customer success

Over the last 12 to 18 months, I have been observing large enterprises rolling out AI-based scaled customer success programs to customer accounts with small footprints. This is fast gaining mainstream popularity. Originally a scaled customer success program was limited to basic automated tech-touch emails, mostly scheduled or driven by the adoption stages. The new scaled CS leverages predictive analytics, automated health scoring, and generative AI to manage customer relationships and achieve outcomes without increasing headcount. An AI driven scaled CS process includes a human-in-the-loop framework limited mostly to sensitive and complex interactions such as escalations.

How do we make the agents operate autonomously with little human intervention? The answer lies in how well we prepare them for customer engagement. Simply providing the customer's entitlements and usage to the agents is not sufficient. They need to know more.

Your human CSMs go through a structured onboarding before they are ever assigned an account. I would put it in six parts. If you are building a customer success agent, a CS agent from here on, these are the questions I have for you at each one.

01Product context

Your human CSMs are certified in your products and services before they are assigned a customer. They know how your products are packaged, marketed, sold, entitled and used.

• Does your agent know your company's product and services portfolio? Does it understand the flavors and packaging variants of the products?
• Is it onboarded on high-level technical knowledge of your products?
• Does it have access to product lifecycle events such as end of sale, end of support and end of life?
• Does it have access to known issues, ongoing resolutions and timelines for the fixes?
• Does it have access to roadmaps?

02Customer context

Your CSMs spend a great deal of effort and time to understand the customer's business health, financial health, leadership and organizational structure, regulatory landscape, and vertical or industry trends, even before they meet their customer. Once they understand the broader landscape, in their initial meetings they try to understand the customer's business goals and how their IT goals address those business goals.

• Does your agent go through a similarly rigorous process of customer onboarding?
• Does it interview customers on their business goals and IT goals?
• Is it trained to map the customer's business use cases to your products?

03Install base and usage context

Your CSMs work with the account teams and internal tools such as CRM, ERP, licensing and telemetry systems to gain knowledge of the customer's install base and their current adoption of products and features.

• Does your agent have access to the internal tools and the underlying data?
• Does it know how to interpret the data and convert it into signals, which is something that happens inside a CSM's head and is written down nowhere?
• How actionable is the data?
• Is your agent able to map the data into concrete actions that will result in business outcomes?

04Success plan context

Your CSMs establish a success plan based on the knowledge they gained through onboarding. The success plan is usually written in the customer's language and aligned to the customer's IT and business goals. They review it with the customer before they start their execution.

• Does your agent interview the customer on their business and IT goals? Where does it get the interview questions from?
• Is the success plan built collaboratively between the agent and the customer? Was it reviewed by a human CSM supervisor who is accountable to CS leadership for achieving those goals?
• Does your agent have access to the mapping between your customer success workflows, the playbooks, and the objectives and milestones defined in the success plan?

05Execution context

Once the success plan is established, CSMs execute on the plan towards the next goal defined in it. They track the plan, and they periodically share progress with the customer and with their own leaders. If they see delays or diversions, they identify them in advance, bring them to the attention of their leadership, revise the plan, and reshare it.

Here is the failure mode I keep coming back to.

• Can your agent map a signal, such as a customer's response or action, back to the success plan?
• Does your agent know what success means for each internal goal and each customer goal?
• Does it know what not to act on?

06Guardrail context

This is the part I see discussed least, and it is the part that gets programs shut down.

• What can the agent commit to on your behalf? Can it reference a roadmap date? A fix timeline? A discount?
• What triggers a handoff to a human, and does the human receive the full context or just the last message?
• Which customers or accounts are out of scope entirely?
• How do you measure whether the agent is working? Not open rates. Retention, adoption and expansion on the accounts it owns, measured against the accounts it does not.

The hard part is not the AI agents

The hard part of enabling AI is not the AI. It is getting the context ready for it. Enabling CS agents means preparing the context for the agent's consumption, and that work is much larger than it looks.

Notice what happens when you go back through the six contexts and ask where each one actually lives.

Product context is spread across marketing collateral, the price book, the support knowledge base and a roadmap deck that is refreshed quarterly. Customer context lives in a discovery call recording, an account plan, and whatever the AE typed into the CRM eighteen months ago. Install base and usage context lives in licensing and telemetry systems that were built for billing and engineering, not for reasoning. Success plan context lives in a document that may not exist. Execution context lives in email threads, CS tool workflows and QBR decks. Guardrail context usually lives in one person's judgment and is written down nowhere.

Six contexts, at least a dozen systems, no shared definition of a customer between any two of them. None of this is a retrieval problem you solve by pointing a vector store at your knowledge base. Semantic similarity will happily hand your agent a roadmap slide from two years ago and a support article about a product this customer never bought.

This is why I think the customer intelligence layer is a separate architectural tier and not a feature of the CS agent. The customer intelligence agents are the data experts that serve it. A CS agent that also owns data integration ends up being neither. Every new source, every schema change and every acquisition drags it backwards, and reasoning quality degrades because the agent is spending its context window on plumbing.

The more interesting reason is that the six contexts are not just an onboarding checklist. They are a retrieval boundary. If the customer intelligence layer knows which context each piece of knowledge belongs to, then the CS agent can ask for what it needs and get only that. When the agent is drafting a renewal conversation, product lifecycle and install base context matter and the roadmap probably does not. When the agent is deciding whether to escalate, guardrail and success plan context matter and adoption telemetry is noise.

Scoping retrieval this way is the job of the customer intelligence agents. They abstract the complexity and hand the CS agent an answer in the language it already thinks in: this customer, this goal, this signal, this history. The CS agent should be able to ask "what changed for this account since we agreed the success plan" and get an answer, without knowing that the answer touched six systems and that two of them disagreed.

What is next

Let us discuss the customer intelligence agents in my next post. I am looking forward to sharing the things I learned building customer intelligence platforms: typed ontology, context graphs, temporal versioning, and what happens when you tag every node in the graph with the contexts it belongs to so that retrieval can be scoped to the job at hand. The question that turns out to be hardest is not "what do we know about this customer." It is "what did we know about this customer in March, and what did we do about it."

The customer intelligence layer is what I am building now, in an independent project of my own.