Why 10K (Our AI VP Marketing) and QBee (Our AI VP Customer Success) Work So Well: The App and the Agent Are One System

Most discussions treat AI agents as standalone features, but the real breakthrough lies in pairing the deployed app with a development agent. By sharing the same database, secrets, and codebase, this unified architecture allows humans and AI to build, fix, and run business operations seamlessly.
Most of the discussion about AI agents in B2B right now treats the agent as a feature you ship: a chat box, a copilot, a magical button inside your product. That framing has been throwing people off, including me, for the past year.
What’s actually working at SaaStr AI, and the reason 10K and QBee (our AI VP Marketing and AI VP Customer Success) both move the business as much as they do, isn’t the apps themselves. It isn’t the agents themselves either. It’s the pairing.
Both are deployed web apps the team uses every day. Real dashboards, real cron jobs, real production substrate. But the deployed app on its own is only half of the system. The other half: we use the Replit Agent to interact with 10K and QBee directly, in a way we couldn’t if they were just standalone published apps. From the cockpit, I (or Amelia, for QBee) can ask the live app questions, fix things inside it, build new features on top of it, all in one conversation. The agent shares the same database, secrets, integrations, and code as the deployed app, so it’s working with the live business, not a copy.
In essence, we’re “hacking” the Replit Agent running Claude Sonnet with an extremely rich and context-filled window (that continually compacts but still holds portions of every marketing and customer action we’ve ever done on 10K and QBee) to interact with the AI application and the humans. Together.
That combination is the architecture. And once you see it, you can see “AI agent in production” is just the start of what we’ll all be doing soon.
A Friday Morning at SaaStr AI
From this week. Five minutes of work that wouldn’t have been possible with either piece alone.
Our sales exec David sent a note: three new Silvers closed (Manus AI, Jobright, Kris@Work) and Exa upgraded.
I asked the Replit Agent to verify against Salesforce. It wrote a quick query, found Manus AI and Jobright already Closed Won, but no opp at all for Kris@Work, and Exa still sitting in Stage 3 Super Gold at $87.5K.
I asked it to update the Exa opp: rename it, update it, mark Closed Won today. Done in 30 seconds via jsforce. Then: “draft an email to David flagging the Kris@Work gap and the Exa change, in my voice.” It wrote it, I tweaked one line, it sent via Resend.
While we were at it, it built a separate ranker for Deep Dive Workshop invitees: pulled the Bizzabo summit attendees, excluded 71 speakers from a CSV and ~91 sponsor companies from Salesforce, scored against a 150-brand allow-list, spit out a 100-person CSV.
That’s a normal Friday at SaaStr AI now. None of those steps are huge individually. The point is they all happened in one thread, against the live business, with judgment in the loop, because the agent had full access to the same systems the deployed app uses.
If 10K were just the deployed app, none of that happens. If the agent were a chat box bolted into production, most of it doesn’t happen either. The pairing is what works.
Another Example, Different Operator
Same week, different person, different kind of work.
Amelia, our Chief AI Officer, asked 10K from inside the Replit cockpit: “who do you think we should invite to do a deep dive? probably mostly folks going to summit or rising AI companies, who do you think?”
The agent ran 24 actions. Pulled live Bizzabo data: 397 current total CXO summit attendees, 134 CROs, 160 CMOs, 103 FDEs and CCOs. Cross-referenced against the sponsor list. Scored against an AI-native company filter. Built a tiered invite list with reasoning attached to each name.
Tier 1 came back as 40 auto-invites: senior, AI-first, already paying for summit access. The output named names and gave a one-line rationale per company:
Harvey: John Haddock (CBO), James Hunsberger (Head of GTM Tech), Kexin Chen (VP Mktg), plus 3 more on CS side. They sent 6 people to summits. Lock all of them in. Aurasell: Jason Eubanks, CEO/Co-founder. Sponsor + summit + AI-first. Triple yes. Ontra: Leslie Olsen, CMO. Ontra has gone AI-native. Commvault: Carilu Dietrich, “VP of AI and Marketing Excellence”. Title alone says she should be at every workshop.
Plus Relevance AI, Amotions AI, Fireworks AI, Crusoe, Horizon3.ai, Shield.AI, Level AI, Conviva, WisdomAI, Explorium, and 25+ more in the bucket.
That’s the cockpit doing work no chat box in production could do well: a novel question, judgment in the loop, live data from three systems, qualitative reasoning attached to each name. There’s no pick_deep_dive_invitees tool sitting in the deployed app waiting for that question. The agent built it on the fly because the substrate let it. And it wasn’t me asking. It was Amelia, doing her actual job from her cockpit.
823 Commits in Six Months. None of Them Started as Code.
The 10K repo has 823 commits in about six months. The vast majority started as me typing a sentence to the agent, not as me writing code.
A sample of what got built this way, all triggered conversationally:
- A predictive ticket-sales forecast card (“predict where we’ll land based on the trailing 30 days”).
- A stale-while-revalidate caching layer that took dashboard cold-start from 5 to 15 seconds down to 50ms.
- A Marketo newsletter opens tracker that auto-discovers programs by naming convention and walks the bulk export in 60-day windows to dodge Marketo’s 1,000-row pagination cap.
- A voice-enabled chatbot that talks back, listens, and knows the live dashboard data.
- A Beefree-ported daily newsletter tool with WordPress integration, AI post-ranking, podcast section, and Resend send pipeline.
- A weekly newsletter variant with a SaaStr YouTube browser, Libsyn podcast feed, and a “Tweets of the Week” section pulling top @jasonlk tweets ranked by engagement.
- A SaaStr Annual attendee newsletter builder with drag-to-reorder section blocks, a sponsor-tier editor, and one-click Bizzabo session import.
None of those started as written specs. They started as a sentence. The agent built them.
The improvisation runs deeper than feature-building. A typo notification came in for a comp ticket buyer: “Cassidy Centures” should have been “Cassidy Ventures.” I asked the agent if Bizzabo’s API was read-only or could write. It didn’t know, and I didn’t know. Bizzabo’s docs are sparse and our codebase only had read paths wired up. So it probed five different write endpoints in parallel: PATCH on the registration (404), PATCH on a contact (404), PATCH on a properties subresource (404), POST on the registration (404), PUT on the registration with a { properties: { company: "..." } } body (200). It re-fetched to confirm the change stuck, then saved a reusable script for next time. Total time: under two minutes. I never opened a support ticket.
Same week, an agent-drafted email failed through Resend on first attempt. The agent had tried an unverified domain, and got a 403. So it grepped the codebase, found that the actual verified sender, retried, sent. Then it saved a rule to the project preferences file: agent-initiated emails default to SaaStr 10K, not Jason personally, and noted the only verified send domain. That preference now applies to every future email it sends.
The agent didn’t just fix the bug. It updated its own future behavior. That kind of self-modification, against an undocumented API, in two minutes, is exactly what’s hard to replicate inside a deployed app.
Why The Pairing Works
When the dev agent runs in the same workspace where 10K was built, it has structural advantages that don’t translate to a deployed-only agent:
Same filesystem. It reads CSVs, writes intermediate scratch scripts, drops output, iterates. A deployed container has no scratch space. Same secrets. All 30+ API keys (Salesforce, Bizzabo, Marketo, X, Resend, YouTube) are right there as env vars. No drift between dev and prod, because dev and prod share the substrate. Same database. The agent queries the production Postgres directly when needed. No “sync the data over to a sandbox first.”
Source: SaaStr
















