Most revenue teams are running into the same wall with AI: they have a mandate to use it, a stack full of tools, and a growing list of reasons why now isn't quite the right time. The data isn't clean enough. The sellers won't follow the recommendations. Everything needs an agent, or nothing does. These aren't fringe concerns — they're the dominant conversations happening in RevOps right now.
In a recent RevOps Co-op webinar, Matt Volm brought together three practitioners who have actually deployed AI across go-to-market teams to pressure-test the assumptions holding organizations back. Sandy Robinson, VP of Revenue Operations and Go-to-Market Enablement at Quavo Fraud, Amanda Cole, CMO and AI Transformation Lead at Bloomreach, and Sara Kinsey, VP of Marketing and Revenue at Von, walked through three myths that are shaping — and sometimes stalling — how revenue teams approach AI deployment. The conversation was direct, occasionally profane, and consistently useful.
The most common reason revenue teams delay AI initiatives is also, in many cases, the most self-defeating one: the belief that data has to reach some undefined state of cleanliness before AI can be trusted with it.
Sara Kinsey has been in the room for this conversation more times than she can count. Across 35 events in 2026 alone, she's heard variations of the same refrain from teams who have been told to bring AI into the organization and are pushing back.
"You've been saying your data isn't ready and your data isn't clean for 25 years, and you've got it to that 80% mark. There is nothing in the world that's gonna get it to that pristine 100% cleanliness in your CRM. Why do you think you need it at that point for AI to be able to do the work?" — Sara Kinsey
Her answer is that you don't. What teams actually need, she argues, is a context layer — organizational intelligence that helps AI understand how your systems work, not perfectly sanitized records.
Amanda Cole pushed this framing further, drawing a distinction that cuts to the root of the confusion.
"The confusion that comes in is data cleanliness is confused with data structure." — Amanda Cole
What Amanda means is that the infrastructure that makes data useful — the hidden logic, the background triggers, the field definitions that nobody outside RevOps knows about — is actually the thing that matters. Sandy Robinson made this concrete with a real example from her own stack: a qualified checkbox and date stamp that fires automatically when an opportunity moves from stage one to stage two, invisible to reps, but foundational to every report and AI output her team produces.
The practical problem isn't that the data is dirty. It's that most people don't understand their own systems well enough to recreate that context for AI — and so they blame the data instead.
This connects directly to the challenge of data management for RevOps teams, where the real work isn't scrubbing records but understanding and documenting the logic embedded in the systems that generate them.
Sandy's definition of clean data is also more nuanced than the all-or-nothing framing that paralyzes most teams. For ICP-related data — the stuff that drives targeting and qualification — her bar is high and actively maintained using third-party sources. For institutional knowledge sitting in 3,500 unreviewed Confluence pages? Her advice to new hires is not to ask the AI anything from there yet. The standard isn't universal; it's use-case specific.
Amanda's final reframe on this myth is worth sitting with: the goal isn't clean data. It's alive data.
"I wanna know the moment an account changes. I wanna know the moment they start engaging and they're showing signals. And now we can, we really can have, with AI, alive data, and really enable the teams to do something with it across marketing, SDR, and sales in a way that we've never been able to before." — Amanda Cole
This one prompted Amanda Cole to note, unprompted, that nobody actually believes this myth — which is itself revealing. Teams build the recommendations. They set up the Slack alerts. They generate the signals. And then they watch them go completely ignored.
Sandy Robinson described the same pattern above, but on a slightly different tech stack: signals posted to a Teams channel that nobody read, Salesforce tasks with briefings nobody responded to, and intent scores without defined SLAs that nobody acted on.
The issue isn't that sellers are uncooperative. It's that sellers are extremely good at prioritizing what matters to hitting their number, and manual data entry, signal review, and prescribed next-step checklists don't make the cut.
"What they're also really good at is hyper-prioritization of the things that they need to do in order to hit a revenue number, and that's what we want them to prioritize. And I can tell you it does not include entering information into Salesforce." — Amanda Cole
AI created the ability to learn from sellers without requiring data entry. Call recordings capture positioning shifts in real time, deal room activity reveals competitor presence, and email and calendar data surface relationship signals. The feedback loop that used to depend on reps filling out fields now runs on data they generate through their normal tools, which now collect that same information in the background.
Sandy's response to this problem has been to build what she calls Account Watchtower — a capability that sweeps Jira, Teams chats, email, Salesforce, and her call recording solution to surface risk signals for accounts every Monday morning, presented to reps without requiring them to construct any of it themselves.
"When they have this Account Watchtower project, it'll pull from the chats they're in, from emails, from Salesforce, from Attention, and then from Jira if they're existing customers to see if there's a ticket that somebody's complaining about. And it's gonna present to them what they should worry about this week and what might be at risk." — Sandy Robinson
The enterprise rollout of her call intelligence solution also illustrates a point worth noting: the coaching signal gets dramatically richer when you capture not just go-to-market calls but technical discovery, partner calls, and MBR conversations. That breadth of context is what enables Von's approach to deal risk detection and surfaces the kinds of signals that inform real coaching decisions.
On the question of how to make recommendations land, Amanda shared a finding from Bloomreach's own deployment. Proactively pushing coaching feedback to reps immediately after calls did not go well. What worked was surfacing scored feedback to managers, who could use it in one-on-ones — and creating a pathway for reps to prompt the agent themselves for feedback when they wanted it.
"It changed the receptivity of the sales rep from us pushing it on them to making it more of a thing that we actually wanna help you help you get better." — Amanda Cole
Sara added that the CROs and sales managers she's spoken with have largely arrived at the same conclusion. The goal isn't to give sellers a process to follow. It's to give the sellers you actually want — the ones with the instincts and the drive — the context they need, exactly when they need it, so they can do the job you hired them for. For a deeper look at how this plays out across the seller lifecycle, Von's breakdown of AE use cases covers the specific contexts where this kind of just-in-time intelligence changes outcomes.
This dynamic also connects to broader questions about real-time enablement — the idea that effective enablement isn't a training event but a continuous information layer that activates at the moment of need.
One of the most practically useful moments in the session came when Matt raised a question that doesn't get enough airtime: what's the right model for surfacing AI-generated signals to sellers?
The options are roughly: deliver the signal with no instruction and trust the rep to act; deliver the signal with a specific recommended action and track compliance; or score signals and route the output to managers rather than reps directly. Each has failure modes. Signal delivery without context gets ignored. Prescribed actions create resentment. Score proliferation creates noise — a different version of the same problem.
Amanda's answer at Bloomreach has been to build what she calls cockpits for marquee accounts — a daily view of recommended actions with click-to-execute integrations. A rep wants to send a gift through Reachdesk? Button in the cockpit. They want to spin up an ABM campaign for an account showing intent? Button triggers the MCP integration and generates the page.
"The key has been the action doesn't have to happen off platform. You're in the tool, the button's there, you click it, and stuff happens." — Amanda Cole
This design removes the friction between signal and action — which, in practice, is often where the whole chain breaks. A seller might agree that a signal is worth acting on and still not do it because acting requires leaving the interface, logging into a different system, and completing a workflow that wasn't built for speed.
Amanda Cole agreed with this myth immediately — and then explained why agreeing with it is still the right answer.
"If workflows are agents, that's true. That's the new language." — Amanda Cole
The more useful question isn't whether everything is an agent. It's whether the thing being called an agent actually solves a specific problem, has a defined owner, and will still be maintained six months from now when the person who built it has left the team.
Sara raised the dashboard analogy, and it resonated: organizations built dashboards for years. Many of those dashboards were never looked at, broke over time, and became liabilities rather than assets when their creators moved on. Agents could follow the same trajectory if the governance doesn't exist to prevent it.
"My concern over this myth is how do we make sure that those agents don't go the route that dashboards have gone for us in the past decade — the dashboards don't get looked at, they don't get used, they break, whose responsibility is it to keep those up, and when that person who built them leaves, then what?" — Sara Kinsey
Sandy's response to this is governance, and it's informed by 20-plus years of building infrastructure in RevOps environments where control over tooling and access is what makes the difference between reliable output and noise. Her concern with organization-wide agent creation is the same as her concern with unreviewed Confluence pages: you don't want the C players setting the bar.
"You don't want a C student setting the bar. You want your A students setting the bar. Why would those be good? That's where the controlly side of me comes into play." — Sandy Robinson
Amanda's framing — individual agents for individual use, governed agents as organizational sources of truth — mirrors the dashboard model that already exists in most RevOps functions. The principle is the same. The scale of the risk is different because agents can take actions in the world that dashboards cannot.
This is also where the question of build versus buy becomes most consequential. Von's perspective on agentic AI for revenue teams is that purpose-built solutions with appropriate guardrails outperform general-purpose agent builders for go-to-market use cases, precisely because the governance layer is built in.
The build-versus-buy conversation surfaced as one of the most substantive threads of the session, and the practitioners in the room landed in meaningfully different places based on their context.
Amanda Cole leads an organization with AI engineering resources and runs an innovation lab that encourages anyone in any team to build small, iterative experiments. But her conclusion from that process isn't that building is better — it's that building first makes buying smarter.
"More often than not, we're able to identify really what we need going through this process, and it gives us a better selection and criteria set for what we wanna buy." — Amanda Cole
She also raised a structural consideration that deserves more attention in the build-versus-buy debate: foundational model lock-in. Teams that build on top of Claude or OpenAI infrastructure are, in her view, creating a dependency analogous to choosing a cloud provider — one that limits flexibility as the model landscape evolves and open-source options become more viable. Tools that sit as an orchestration layer above multiple foundational models — able to switch between them and eventually benefit from open-source cost reductions — offer a more durable architecture.
This is precisely the architectural position Von takes with its revenue agent approach, building a layer that can route across models rather than committing to a single foundational infrastructure.
Sandy's calculus is different and shaped by team size. For smaller RevOps organizations without dedicated engineering support, building creates fragility — especially when institutional knowledge walks out the door. Her preference is to buy tools that connect cleanly to the three foundational layers she cares about: Salesforce, Claude (as her primary interface), and Clay for workflow automation.
The build-versus-buy framework Von has published maps this decision across team maturity and use case complexity — useful context for any RevOps team currently working through this choice.
For teams navigating this decision, the question of AI readiness in the revenue stack is an important prior: what you can build and what you should buy both depend heavily on the condition of the infrastructure underneath.
The governance question that emerged from the agent discussion — who should have the ability to build, and who should be accountable for what gets built — doesn't have a settled answer yet. All three panelists acknowledged this openly.
Sara's concern is timeline: she suspects this will take longer to resolve than the community expects, and that the stakes are higher than they were with dashboard proliferation because agents take actions rather than just displaying information.
Sandy's position is that building should be centralized or at least tightly governed, especially in organizations where a single RevOps practitioner is carrying the operational infrastructure. Her approach — building skills in controlled environments, running office hours, and sharing documented project files so others can recreate what she's built — is a stopgap for the governance framework that doesn't yet exist in most companies.
Amanda's take is that individual agents for individual use are fine, as long as the person using them remains accountable for the agent's actions. The organizational risk comes from agents that are presented as sources of truth without the governance to back that up.
The underlying tension here is familiar to anyone who has dealt with the compounding cost of deferred governance in a RevOps context. Short-term flexibility versus long-term accountability. The outcome doesn't change just because the technology is new.
The through-line across all three myths is the same: AI doesn't remove the need for RevOps rigor — it amplifies whatever rigor already exists. Teams that have done the work of understanding their systems, documenting their logic, and building governance structures will get dramatically more out of AI than teams that treat it as a shortcut around that work. The unglamorous foundation is still the prerequisite.
Learn more about how Von helps revenue teams deploy AI across go-to-market workflows — with the organizational intelligence layer and governance controls that make outputs actually trustworthy.
Check out our blog, join our community and subscribe to our YouTube Channel for more insights.
