SaaStr Built an AI VP of Customer Success in Replit. Zero Engineers. 100 Sponsors.

Amelia is SaaStr’s Chief AI Officer. She built Qbee, an AI VP of Customer Success, inside Replit. No engineers. Qbee now manages over 100 event sponsors with 70% fewer human hours and a 10x lift in sponsor engagement versus the legacy tool that came before it.

The temptation is to read this as a vibe-coding success story. A non-technical operator ships a production system, the future is here, anyone can build software now. That reading misses the point.

The Qbee story is interesting because it documents what production looks like when the builder is not an engineer. The artifact is not the codebase. The artifact is the daily operating discipline. And that discipline is the same discipline that engineering leaders have been writing about all year, translated for a function that has never had to think this way.

The economics are not the story

Jason Lemkin shared the numbers in a recent SaaStr post. Combined token cost across all of SaaStr’s vibe-coded apps is under $200 per month. The math is absurd in the best possible sense. A VP-level function that would cost a salary, benefits, equity, and management overhead, replaced by a Replit app running on token spend.

But cheap is not the lesson. Lots of cheap software fails in production. The lesson is what made Qbee survive contact with 100 paying sponsors.

Three operating patterns. None of them are technical.

Pattern one: build the dashboard before you build the agent

SaaStr’s first move on Qbee was not the agent. It was the dashboard. A central screen that shows the state of every sponsor: where they are in the journey, what is overdue, what is at risk, what just shipped. The agent was built second, against the dashboard.

This sequence matters. The dashboard is the spec. It is the visible artifact that lets a non-engineer reason about whether the agent is doing the right thing on a given day. Without it, the agent is a black box. With it, the agent is a measurable employee.

Compare this to the typical pattern in engineering, where the system is built first and observability is grafted on later. Amelia inverted the order because she did not have the technical instincts to defer observability. She needed to see the work before she trusted any automation against it.

This is a transferable pattern. If you are a marketing leader, a legal lead, a finance ops director thinking about deploying an autonomous agent in your function, build the dashboard first. Make the work visible to a human reviewer in one screen. Then point the agent at it.

Pattern two: agent hopping for sensitive data

The most quietly important pattern in the Qbee post is what Lemkin calls agent hopping. Sensitive data, contracts, internal financials, sponsor commitments, does not live in the agent’s context. It lives in the secure systems where it belongs. Qbee calls APIs to read and write against those systems, but it never holds the raw data in memory or in prompts.

This is the customer success version of a pattern that took engineering teams two years to internalize: the agent is a coordinator, not a vault. State of record stays in systems of record. The agent moves between them.

For non-engineering leaders, this reframes the data security conversation entirely. The question is not “is it safe to put our customer data into an LLM.” The question is “can we structure the work so the agent never touches the raw data, only the operations on it.” The answer to the first question is often no. The answer to the second is usually yes.

This connects directly to the workload and harness fit problem we have been tracking. The harness is what makes the workload safe. Agent hopping is a harness pattern. It is what lets a Replit-built tool manage real sponsor contracts without becoming a data leak.

Pattern three: four to six personalization data points per message

SaaStr’s third operating rule is the one most teams will fail at. Every message Qbee sends carries four to six unique personalization data points. Not merge tags. Not “Hi {first_name}.” Actual signals pulled from the sponsor’s behavior, history, tier, current state, and recent interactions.

This is the work that distinguishes a real autonomous agent from a glorified mail merge. And it is the work that explains the 10x engagement number. Sponsors respond because the messages read as written specifically for them, because they were.

The discipline here is not technical. It is editorial. Someone has to decide which signals matter, which combinations make a message feel personal versus surveillance-like, and which signals are off-limits. Engineering teams cannot make these calls. The function owner has to.

This is the same pattern we identified in the Klaviyo Composer launch: marketing agent governance requires marketing judgment, not engineering judgment. Qbee extends it to customer success. Customer success agent governance requires CS judgment about which signals constitute care versus creepiness.

The shipping discipline

SaaStr also ships one customer per tier first. They do not flip the whole sponsor list onto Qbee on day one. They pick one sponsor at each tier (top, middle, bottom), run the agent against just those three, and watch what happens for a week. Then they expand.

This is canary deployment translated for customer-facing work. The cost of a bad release in engineering is a rollback. The cost of a bad release in customer success is a sponsor who feels mistreated, possibly publicly. The shipping cadence has to be slower and more deliberate, because the blast radius is human.

Daily maintenance is the other non-negotiable. Qbee is not a fire-and-forget system. Amelia checks the dashboard every day. She tunes prompts, retires patterns that misfired, adds new signals as the sponsor base evolves. The agent does not run itself. The agent runs the work, and a human runs the agent.

This connects to the broader pattern we have been writing about. Governance is shipping as product. At Qbee scale, governance is shipping as a daily 30-minute review. Different instantiation, same principle: the operating discipline is what makes the autonomy survivable.

What this means for everyone else

Lemkin’s framing of the opportunity is worth quoting directly:

“The distance between what customers need and what CSMs can humanly deliver is the single most valuable place to deploy AI in your B2B business right now.”

He is right about the opportunity. The interesting part is that the same logic applies to every function where the distance between customer need and human capacity has become embarrassing. Support. Onboarding. Renewals. Account management. Partner programs.

In every one of these functions, the playbook from Qbee transfers:

Build the dashboard first. Make the work visible.
Design for agent hopping. Sensitive data never enters the agent.
Demand four to six personalization data points per outbound message.
Ship one customer per tier. Expand by evidence.
Treat daily maintenance as non-negotiable.

None of these are technical disciplines. All of them are operational disciplines that the function owner must own. The Replit app is the easy part. The discipline is the hard part.

Do this now

If you lead a non-engineering function and you are considering an autonomous agent for a recurring, high-volume, personalization-heavy workflow, do not start with the agent. Start with the dashboard. Spend a week sketching the screen that would let you, on any given Monday, see the state of the work and answer “is the agent on track or off track.” If you cannot draw that screen, you are not ready to ship the agent. If you can, you are halfway there. The other half is the daily 30 minutes you commit to running it.

This analysis synthesizes Top 10 Learnings From Building Our Own AI VP of Customer Success: Qbee by Jason Lemkin (SaaStr, May 2026).

Victorino Group helps non-engineering teams ship autonomous agents into production with the daily operating discipline that turns the gap between customer need and human capacity into measurable, governed coverage. Let’s talk.