Agent-Led Growth — Issue 02
Customer success is going through the shift sales and marketing already went through. As the work gets automated by agents, a new hybrid role appears to build, connect and monitor the automation.
Call it the customer success engineer. Part CS, part builder.
It isn’t a rebrand, and it isn’t a CSM who learned some SQL. It’s a set of responsibilities that didn’t exist two years ago, showing up inside CS teams for the same reason a near-identical role showed up in go-to-market first.
The GTM Engineer, One Beat Earlier
Go-to-market hit this first. Once AI tooling got good enough to draft outreach, enrich leads and route signals between tools, someone had to actually build and maintain those systems.
Not a rep. Not a RevOps hire. Someone comfortable enough with APIs, automations and prompting to wire the stack together — sitting inside a function that used to be almost entirely non-technical.
The role existed because the work changed faster than the skill set. Knowing how to run a great outbound sequence stopped being the ceiling. Someone had to build the system that ran a hundred versions of it.
CS is at the same inflection point now, a beat later.
Why the Same Shift Is Hitting CS
Agentic support isn’t plug-and-play. Standing it up — and keeping it good — is real work, and it never stops being work:
Configuring objectives and guardrails per segment. What “good” means for a free-trial user isn’t what it means for an enterprise admin, and the agent needs to know where it hands off.
Connecting behavioural and account data so it reasons from live context, not a static script.
Monitoring where it’s quietly wrong. Catching the confidently bad answer before a customer does.
Keeping it current every time the product ships.
We wrote about the management side of this in August — defining good, setting guardrails, reviewing performance. This is the other half. Someone has to build the thing being managed.
None of that is traditional CS work. None of it is traditional engineering work either.
The tooling has already noticed. Support platforms like Pylon are noticeably more API-first than the CS tools of five years ago — built assuming someone on the CS side will want to configure and extend the system, not click through a settings page.
The second front is workflow automation. It’s increasingly normal to see CS teams building their own connected flows: a call gets transcribed, an AI workflow drafts the follow-up, updates the CRM and runs sentiment on the conversation, with nobody touching each step.
A lot of these are stitched together directly with tools like Claude, by people on the CS side who picked up enough fluency to build it rather than file a ticket and wait two quarters.
The person who can do both — understand what good customer success looks like and build the system that delivers it — is the customer success engineer.
What the Role Actually Does
In practice it clusters around two things.
Running the agent. Defining what it handles versus escalates, by segment. Reading real conversations to find where it underperforms. Adjusting guardrails as the product and the customer base move. Judgment work wearing a technical hat — the instincts a good CSM already has, applied to a system instead of a call.
Building the automation layer. Wiring together what used to be manual handoffs: transcripts into CRM updates, sentiment into health scores, follow-ups drafted instead of typed. Increasingly with AI tools and SDKs directly, rather than waiting on a point solution that does exactly this one thing.
Neither is CS as usual. Both need enough technical comfort to build something, not just request it.
Why This Wasn’t Possible Two Years Ago
This isn’t a staffing trend. It’s downstream of what the tooling made possible.
Building a custom automation used to need a dedicated engineer and a slot in someone’s backlog. Now a person with CS judgment and a working knowledge of how to prompt and chain AI tools can build a meaningful piece of it themselves.
The bar dropped far enough that CS-native people can clear it without becoming engineers.
The Part Most Teams Will Get Wrong
Here’s where the GTM parallel earns its keep.
The instinct will be to solve this with a hire from engineering. Someone technical, dropped into CS, told to own the agent. It’s the obvious move, and it mostly doesn’t work.
The scarce input was never the ability to call an API. It’s knowing what a good outcome looks like for a specific customer at a specific point in their lifecycle — which questions signal risk, which silence means churn, when the agent should say less. That’s a year of pattern-matching inside a function, and it doesn’t transfer in an onboarding week.
GTM engineers overwhelmingly grew out of revenue teams, not out of engineering. The direction of travel is the whole point:
It’s easier to teach a strong CSM to build than to teach a strong engineer what a healthy account feels like.
What This Means for CS Teams
Hiring shifts, but not toward engineers. Alongside traditional CSM skills, you want a few people who aren’t allergic to APIs, automation tools and AI workflows. Comfort, not credentials.
The role sits inside CS, not alongside it. Not an engineering headcount bolted on. An evolution of the CS skill set — the same way GTM engineers emerged from within revenue teams.
It compounds. Every automation one of these people builds hands time back to the rest of the team for the commercial, relationship-driven work that was always the point of the job.
The function doesn’t get bigger. It gets denser.
What that person should build first — the three automations worth doing before anything else — is the next one.
The Customer Success Engineer: FAQ
Is a customer success engineer the same as a support engineer? No. A support engineer handles technical customer issues directly. A customer success engineer builds and maintains the systems — agentic support, automation workflows — that the rest of the CS team runs on.
Do they need to know how to code? Not in the traditional sense. Most are building with AI tools, SDKs and low-code workflows rather than writing software from scratch. Comfort with APIs, prompting and connecting tools is the actual requirement.
Should we hire an engineer into CS instead? Usually not. The technical half is teachable in weeks; knowing what a good customer outcome looks like takes a year inside the function. Build the role from your existing CS team.
Why is this emerging in CS specifically now? Because agents got good enough to absorb a real share of CS work, and the bar to build that automation dropped far enough that CS-native people — not just engineers — can clear it.
Is this the same trend as the GTM engineer role? Yes, a beat later. As AI absorbs more of a function’s day-to-day work, a hybrid role emerges from inside that function to build and maintain the automation.
Want to see this working on your own product? autoplay.ai · Quickstart docs: developers.autoplay.ai