Learn what it takes to build and maintain an AI RevOps headcount, with stories from Kevin Heraly, VP of RevOps at DemandScience, and our head of AI, Sundeep Bhimireddy.
The most capable RevOps people I know are builders. Hand them a new model and a free afternoon and they will have something clever wired up by dinner. That skill is exactly what you need these days on your revenue team. To get the most out of it, those builds need a strong foundation under them, a robust context graph and harness made specifically for RevOps teams. That is what makes building on Von so powerful.
We took a deep dive into this on our June 2026 webinar with our co-founder Sahil Aggarwal, Kevin Heraly, the VP of RevOps at DemandScience, and Sundeep Bhimireddy, our head of AI. The question we are all evaluating is this: under which circumstances should I build, and when should I buy something already made, tested, supported, and maintained?
Here is what you should consider as you make that decision for your business.
Everyone in revenue adds to the RevOps queue, and RevOps is already underwater
to query, and it clears the backlog so the team can spend its time on strategic work rather thanStart with the problem, because it is one you already know
RevOps has access to all the disparate data sources, structured and unstructured. They have a variety of ways to reach that data and turn it into the insights, reports, and dashboards the go-to-market team runs on. So when anyone needs something, they go to RevOps. The CRO goes to RevOps. The CMO goes to RevOps. Sales managers, CS managers, and BDR managers all go to RevOps with their requests, reports, and projects.
RevOps already has a full queue, and on top of it sits a list of strategic projects they have been meaning to get to for months.
Two problems follow.
The first problem is speed. Getting an answer is a loop. You ask, you wait, you get a report, you go back and forth, a new question sends you digging deeper, and eventually you decide and take action. That loop takes days, sometimes weeks, rarely minutes or hours.
The second problem is silence, and it is worse because it is harder to see. When RevOps is running so many of these loops on top of the day-to-day, everyone knows the queue is long. People assume their request will never climb to the top, so they stop asking. When they stop asking, they stop getting the insight at all. Neither outcome is good.
Sahil describes what an AI RevOps headcount should feel like, and that is what Von is. It is a headcount, not a chatbot you query, and it clears the backlog so the team can spend its time on strategic work instead of operational requests. In the webinar, he showed how that plays out, turning work that used to take days or weeks into finished output the team gets back in minutes. You can watch the walkthrough in the on-demand recording.
A builder's case for buying
Kevin is a builder. He is the VP of RevOps at DemandScience, he knows how to code, and he is one of those highly technical, capable RevOps leaders. He was excited about what he was already building. Then he tried Von.
Before he switched, he had assembled his own stack. He used GPT for the reasoning, experimented with Claude, wired up Zapier for automations and triggers, and ran his pipeline analysis in Python notebooks. Each piece worked on its own. Stitching them into something dependable was the hard part, and it never held. Every session started from zero.
When we build with AI, we assume we can prompt our way to the best answer. If the output falls short, we tell ourselves the fix is a better prompt. That does not hold up at scale. You can paste your MQL definitions or your stage rules into a chat, and the model will use them for that one task.
The trouble starts when you need to do more than one task well, again and again. Three things break, and no prompt fixes them.
Scale is the first. A model cannot reason across tens of thousands of deals, hundreds of thousands of calls, and millions of emails at once. It runs out of context long before it works through your data.
Retrieval is the second. Pulling the right records from disparate, structured, and unstructured sources is a hard problem in its own right, and a prompt does not solve it.
Governance is the third. Your business definitions must remain current, shared, and trusted across the entire revenue team. Paste them into a chat, and they live for a single session, then go stale.
Knowing the definition was never the hard part. Using it at scale across the org every time is the hard part.
Once he saw Von, Kevin's question was not whether he could build it. It was whether he should. He is candid that he could not keep up with the pace of Von's releases, the quality of the answers, the breadth of use cases, or the work of rolling it out and supporting the rest of the revenue team. Every hour he spent maintaining Zapier triggers and webhooks was an hour he was not spending on the strategic work that is the job.
Once he switched, the use cases compounded:
- A Salesforce change log that runs every Saturday, documenting what changed across fields, workflows, and flows, with a recommendation on what needs enablement.
- A full Snowflake assessment after he lost his BI analyst, which surfaced thousands of orphaned tables and cut real costs by removing what was no longer used.
- A re-onboarding document for his director returning from two months of paternity leave, built from a full audit of system changes, that got him caught up in a day.
- APEX and flow error diagnosis that used to get handed to a developer, now returned in two minutes with a remediation plan, and in some cases, Von builds the fixed flow in draft for review.
For the first time in months, he said, he could breathe. He had the extra headcount the team never got to hire.
He never pushed Von on anyone. His CRO built an entire board deck in under an hour and started talking about it on LinkedIn. The CMO, newer to the company, asked for access and got sharper answers once Von learned the lead progression rules and saved them to org memory. Then sales leadership wanted in, then the SDR team, then BI. To this day, Kevin fields license requests almost every day. The adoption was pull, never push, because the value did not need explaining.
What it takes to build Von yourself
If Kevin's story is the why, Sundeep's is the how.
Sundeep is our head of AI. He spent years building large-scale deep learning and LLM systems at AWS before joining, studied mathematics in graduate school and engineering at IIT Kharagpur, and has spent more than a year building Von. He knows what good looks like, and his expertise across AI and machine learning runs deep.
He opened with the movie Memento. The main character cannot form new memories, so every morning he rebuilds his world from a wall of photographs and scribbled notes before he can function. Foundation models have the same condition. They are brilliant at general knowledge, and they do not learn your business. To make one useful for revenue work, you end up building that same wall yourself, with a pile of MCP connections, hand-written skill files, and your own orchestration holding it all together. It works for small tasks. It does not get you far.
What you need instead is something that learns your business on its own and remembers it. Sundeep calls that the harness, and it is what you cannot build when you picture spending a weekend putting together something like Von yourself. Von's harness runs on a context graph with a few layers working together:
- A semantic layer that learns your business definitions, how you define churn, qualified pipeline, and sales stages, by crawling your systems and proposing definitions you review and approve.
- A knowledge graph that stitches data across systems and understands how your entities relate, so the analysis holds up.
- A deal intelligence layer that pre-analyzes tens of thousands of deals, hundreds of thousands of calls, and millions of emails, so complex analysis comes back in minutes instead of hitting context or rate limits.
- A shared memory you govern at the org, team, or user level, with the access controls, human-in-the-loop approval, and audit logging that production work requires.
Those layers are the answer to the three failures from Kevin's stack. Scale, retrieval, and governance are not prompt problems; they are harness problems, and the harness is what you would be signing up to build and maintain. Strip it out, and you are left with a model reasoning over raw data it does not understand. You can write a flawless prompt and still get a confident, wrong answer, because the model does not know which of your fields are dead, how you define qualified pipeline, or that your closed won numbers include renewals. As Sundeep put it, you have an engine with no car around it.
Build what you can. Buy the context graph and harness.
This was my conclusion after listening to Sahil, Kevin, and Sundeep, and it is the one our customers reach on their own. Build what you can. Buy the context graph and harness. You are in the business of driving revenue, not maintaining MCP connections, skill files, and figuring out governance, while your backlog grows.
Two places are worth your time if you want to go further.
1. Read what our customers say on the customers page. Kevin is one voice, and several others have been candid about why they made the same call.
2. If you want our full position on building versus buying, the build versus buy page lays out where each one makes sense.
3. When you want to see Von work against your own data, that is what a demo is for.
