Plenty of AI agents look capable in a demo, but VenuMadhav Kattagoni spends his time on the harder stage that follows: when an agent has to work inside a customer’s actual CRM, with its duplicate accounts, stale opportunities and permission rules that were never written with software agents in mind.
Kattagoni is Head of Engineering at Von, a San Francisco AI revenue intelligence platform backed by Insight Partners, GV, Sequoia Capital India and Lightspeed. He joined in August 2025, to lead a rebuild of its product and engineering organization, and in under a year the new platform went from zero to $2 million in annual recurring revenue while he hired more than 20 people across the US and India. Before Von, he was an engineering manager at Rippling, where he led the reporting and workflow automation platforms and is a named co-inventor on four granted US patents. Earlier he was a founding engineer at Klarity.
In the following, he tell us about where enterprise agent projects tend to fall apart, how Von tests an agent before it’s allowed to change a CRM record, and why per-use model costs are pushing AI companies away from straight seat-based pricing.
When you joined Von in the middle of its pivot, how did you decide which parts of the old platform were worth keeping and which had to go?
The direction was clear: we wanted to automate the product’s workflows using agents. We stabilized the existing product and made it self-serve so customers could continue using it while we built the next version.
The harder question was whether our existing team had the experience and skills needed to build that new product. We concluded that the shift required a substantially different team, which meant making difficult decisions about departures and hiring for the capabilities we needed. The rebuild was as much an organizational change as a technical one.
Where do enterprise agent projects usually break down once they move past the demo stage and into a real revenue team’s systems?
Most enterprise agent projects break down in everything surrounding the model. A demo can run on clean data, one connected system and a predictable workflow. In production, the agent has to work across different systems, inconsistent data models, authentication flows and permissions, alongside data hygiene issues and hundreds of other operational details.
Revenue teams have duplicate accounts, stale opportunities, missing fields and conflicting information across their CRM, calls, email and Slack. The agent has to determine which information to trust, whether it’s current and whether the user is allowed to access or act on it.
Then it has to handle expired connections, rate limits, timeouts and partial failures without duplicating actions or silently dropping work. Getting an agent to produce a convincing answer is one step. Making it dependable inside a customer’s actual systems is the much larger engineering challenge.
Talk us through the role the knowledge graph and fine-grained permissions play in letting an agent touch sales and finance data safely.
The knowledge graph connects the pieces of a business process. An opportunity relates to an account, people, conversations, documents and activity. Those relationships help an agent find relevant evidence instead of treating every record as an isolated piece of text.
But a relationship between two records doesn’t grant permission to read or change either one. My principle is that the user’s permissions in the connected system set the ceiling. Context can narrow what the agent should do; it should never expand that authority.
Reading a document, updating a CRM field and sharing a report are different actions and need distinct checks. The questions I want the system to answer are: who is acting, on whose behalf, on which data, and for what purpose? That’s the foundation for the runtime-permissions approach I’ve advocated.
What does testing an agent look like at Von before it’s allowed to act inside a customer’s CRM?
I separate the quality of the reasoning from the correctness of the action. An agent can explain itself convincingly and still update the wrong record.
Our evaluation design starts with repeatable queries and reference criteria: did the agent retrieve the right evidence, support its claims and use the appropriate tools? We also measure latency, tool calls and cost. Otherwise, an improvement in answer quality can hide a substantial regression elsewhere.
The sandbox environments companies already maintain are important here. Where available, they let us test against the customer’s own CRM configuration, custom fields and workflows without changing live business records. The closer that environment is to production, the more useful the test, though we still need to account for differences in data, permissions and integrations.
For CRM actions, the standard I want is to verify the target record, the proposed change, the permission and the resulting state. The tests also need cases where the right answer is to stop or ask a question, along with retries and partial failures. A test should establish what actually happened, not just whether the final response sounded correct.
How has the per-use cost of running AI models changed the way Von prices and meters its product compared with a traditional SaaS subscription?
A seat no longer tells you much about the workload. One user might ask a short question; another might run an investigation across several systems with large amounts of context and multiple model calls. Both have a license, but their consumption can be very different.
That has pushed our pricing design toward licenses with usage allowances. We need to attribute consumption to the user, organization and work being done, while giving customers an understandable view of where their allowance went.
It also changes how I evaluate engineering decisions. The useful metric is the cost of completing the work at an acceptable quality and latency. A cheaper model can cost more overall if it takes several attempts. An expensive model used indiscriminately can make a valuable workflow difficult to sustain.
Is there anything from building pre-LLM contract review systems at Klarity that still shapes how you design agents today, or did most of that work have to be relearned?
A lot of the discipline carries over. At Klarity, we worked on turning unstructured contract language into information people could use in a business process. You still had to define what a field meant, find the supporting evidence and understand the consequences of a mistake.
LLMs have made it possible to handle much more variation in language. But the need for evidence hasn’t gone away. A reviewer should still be able to understand where an answer came from and when human judgment is needed.
What has expanded is the range of behavior. An agent can choose tools and intermediate steps, which creates many more paths to evaluate. The lessons around evidence and verification still apply; now we also have to examine the execution path.
What’s worked, and what hasn’t, in running a fast rebuild with a team split between the US and India?
Honesty and ownership matter a lot across time zones. I tell candidates that I’d rather hear exactly where they’re stuck than get an optimistic update that hides a problem. Otherwise, you can lose an entire working day before the next person discovers it.
I also want people to automate repetitive work and take responsibility for larger outcomes. Giving everyone access to AI tools helps, but responsibility for the result still belongs to the person using them.
The risk is letting every ambiguity wait for a meeting. My standard is a clear owner, a clear definition of done and enough written context for someone else to continue. During onboarding, I use frequent short check-ins and a substantial project to build that ownership.
