At Google, I did not have one clean job.
Before a contract, I trained sales teams, ran technical demos, built parity sheets, translated customer requirements into BRDs and PRDs, and explained what Google Ad Manager could do today versus what needed product work.
After the contract, the work changed shape but did not change owners. I built the onboarding plan and the giant checklist. I sent help-center articles, taught teams how to use the platform, worked with their engineers, pulled logs internally to validate the setup, handled the questions that arrived between meetings, ran QBRs, found relevant product betas, made the case for customers to join them, and carried the strongest requests back to Product.
Different companies split that work across solutions engineers, customer engineers, forward deployed engineers, implementation consultants, technical account managers, professional services, and customer success. Sometimes one person quietly does all of it.
Lately the titles have multiplied again: AI Success Engineer. Agent Deployment Engineer. Forward Deployed AI Engineer. Technical Deployment Lead.
We wanted to know whether this was a naming trend or a new underlying job.
So we studied the work.
The study
We collected exactly 150 active US and US-remote jobs from 53 companies across AI, developer tools, data, infrastructure, security, and complex B2B software. Every row came from an employer career page or a public Ashby, Greenhouse, or Lever feed on August 5, 2026. LinkedIn helped us notice title language; it is not a source in the dataset.
The public release includes the 150-row CSV, source register, methodology, codebook, validator, analysis scripts, chart generator, and a documented second-pass review of 30 randomly selected rows.
For clarity, this dated snapshot used the committed collectors against public ATS feeds and first-party employer pages; we did not scrape LinkedIn. If you want to extend the source universe or build a similar dataset, we also published a practical guide to using rtrvr.ai Cloud, the Scrape API, the CLI, the browser extension, and MCP for public, dynamic, authenticated, and agent-driven collection workflows.
We did not republish job descriptions. The dataset contains provenance, factual metadata, boolean responsibility labels, short original paraphrases, and links. A false label means “not stated strongly enough to code,” not “this employee never does it.”
That distinction matters. Job descriptions are uneven instruments. The findings below describe what employers chose to publish, not a time-and-motion study of the people they hired.
125 titles, nine families
The 150 openings contained 125 distinct posted titles. We normalized them into nine families.
Solutions Engineering was the largest family at 52 roles, or 34.7%. Forward Deployed Engineering followed at 33 roles, or 22%. Deployment and Implementation represented 17, Sales Engineering 16, Technical Account Management 14, Customer Engineering 12, AI or Agent Success 4, and the explicitly named Professional Services Engineering and Technical Success families one each.
This is fragmentation, but it is not random. The titles describe where a company places emphasis:
- Solutions and Sales Engineers lean toward discovery, demos, technical evaluation, and architecture.
- Forward Deployed Engineers move deeper into code, integrations, deployment, and production outcomes.
- Implementation and Deployment roles carry signed customers through launch and adoption.
- Technical Account and Success roles keep the system healthy, useful, measurable, and expanding.
The important finding is not that the titles are interchangeable. They are not. It is that the responsibilities overlap across a customer lifecycle that no title owns cleanly.
What companies are actually buying
We coded fifteen responsibility signals. A role can carry many.
The most common signal was playbook creation: 97 roles, 64.7%. Employers repeatedly asked people to create best practices, documentation, reusable patterns, enablement assets, and field knowledge.
That surprised me less than it might have before Google. The visible work is the customer call. The scaling work is what happens afterward: turn this deployment into a reference architecture, this failure into a runbook, this explanation into training, this workaround into a product requirement.
Next came adoption in 85 roles (56.7%) and cross-functional coordination in 78 (52%). Training appeared in 70 (46.7%). Demos appeared in 59 (39.3%). Value or QBR work appeared in 58 (38.7%). Debugging/support and product feedback each appeared in 57 (38%).
The long tail is not optional work. Onboarding appeared in 55 roles. Architecture in 47. Coding and integration in 42. POCs and renewal/expansion in 40 each. Discovery in 38. Validation in 31.
No single title family stayed inside one stage.
A customer problem does not respect the org chart. The person who discovered the use case may need to prove it, help integrate it, validate the setup, teach the team, debug the first failure, measure adoption, and carry what they learned back into the product.
That is why the job feels larger than the title.
Compensation is a scarcity signal, not a replacement calculation
The postings also show how expensive this judgment is to hire—and how easy it is to misuse salary data.
Only 67 of 150 roles (44.7%) disclosed an explicit base-salary interval we could normalize. Among that disclosed subset, the median lower bound was $135,000, the median upper bound $200,000, and the median per-role midpoint $167,500.
Only 27 roles (18%) disclosed an explicit OTE interval. Within that separate subset, the median lower bound was $155,000, the median upper bound $205,000, and the median per-role midpoint $180,000.
We do not combine those numbers. OTE is not base. A posting is not total employee cost. Equity, benefits, location, level, travel, and variable compensation differ. Posted compensation is certainly not “replaceable cost.”
It does tell us that companies pay a premium for people who can carry technical context across organizational seams. Nearly half of the postings also mentioned travel. This is scarce, high-trust work attached to real customer outcomes.
The opportunity for AI is not to turn that salary into a savings slide. It is to stop spending so much of a scarce person's day rebuilding context and repeating already-known work.
This is not a chat job
The common unit of work in these postings is not a conversation. It is a loop:
understand the account → inspect the real state → take or coordinate an action → verify the effect → preserve what was learned
A chatbot can answer “Where is the SSO setting?”
A customer engineer has to know which account is asking, what they agreed to deploy, who owns identity, what changed since the last call, whether the setting is already configured, which logs prove the integration works, whether the user has authority to change it, and what should happen next if verification fails.
Then the engineer updates the plan, tells the right people, and remembers the pattern for the next account.
That is context, action, coordination, and verification. Chat is only one surface.
What an agent can own
The repeated portions are substantial:
- assemble the account brief before a meeting from permissioned systems;
- keep onboarding plans and checklists current;
- prepare and run a known demo against the customer's use case;
- guide configuration or execute an approved change in the real product;
- inspect account-scoped logs and validate the resulting state;
- draft training, follow-ups, QBR inputs, and status reports from verified work;
- notice a repeated blocker and turn it into a playbook or product-feedback packet;
- keep Slack, email, CRM, tickets, product state, and meeting decisions synchronized; and
- stay present between calls so a small question does not wait a week for the next expert slot.
The agent should not silently choose commercial commitments, invent product promises, override security policy, infer authority, or force a novel architecture through ambiguity. Humans remain responsible for relationship judgment, negotiation, exceptions, risk, and the genuinely new.
The useful division is not “AI does easy accounts; humans do important accounts.” It is: the agent owns bounded execution and evidence; the human owns judgment and accountability. Each can hand work to the other.
The missing employee
The dataset did not describe one uniform role. It described one missing employee-shaped system behind many roles: persistent account memory, technical execution, lifecycle coordination, and verified follow-through.
That is the category we are building Rover toward: the AI Customer Engineer.
Rover already lives inside a product, where it can guide and act in the user's real session. The larger direction connects that product presence to the surfaces where customer work already happens—meetings, customer Slack, email, CRM, tickets, documents, and developer tools—under one account-scoped permission model.
The next article in this series asks what happens when Rover is live in the call, and why understanding a meeting should begin with shared work rather than guessing emotion from a webcam.
We are opening a small design-partner program for leaders in Customer Success, Professional Services, Solutions, and Forward Deployed Engineering. If you have a repeated workflow that consumes your best technical people, show us that workflow. Put it in the “Anything specific you want to see?” field. That is the demo we will build around.