Most conversations about go-to-market AI are still largely theoretical. People describe use cases in the abstract and cite ROI estimates as fact. In the few cases where they’ve actually implemented the use case, they leave the messy, hard-won details of what it actually took to ship it out of their #HumbleBrag post. Practitioners tend to learn more from each other's war stories than from any vendor presentation.
In a recent RevOps Co-op webinar, Matthew Volm, CEO and Founder of RevOps Co-op, sat down with Jackson Mattox, Manager of Marketing Operations at Cockroach Labs, and Dom Freschi, Director of Go-to-Market Operations at Openprise, to walk through what AI in go-to-market actually looks like at a company that has shipped it. Jackson demoed Micah, Cockroach Labs' internal AI-powered GTM tool, and the conversation surfaced some of the most honest and specific lessons available on this topic right now.
The session also opened with a live poll asking attendees which challenge they were working through as they scaled AI. Data quality was the top response — a result neither Jackson nor Dom found surprising, and one that shaped the conversation that followed.
The version of AI-powered outbound that Cockroach Labs runs today looks clean in a demo. The reality of building it was not.
Jackson was honest about the pains they experienced. Cockroach Labs experimented with automated SDR technology, built internal flows using n8n and Snowflake, and iterated on contact briefs, account-level signals, and AI-generated email sequences — before arriving at anything that felt stable enough to trust.
"I think I oversimplified what that flow looks like. It was, you know, genuinely like eight to 10 months of grueling work and playing around with where we wanted things to live." — Jackson Mattox
The outbound motion today works like this: account-level signals, contact engagement data, anonymous web traffic, and intent indicators are pulled into Snowflake. n8n flows use that data to generate personalized first- and second-touch emails on behalf of SDRs, which are automatically loaded into Outreach. Reps then review and call. The system accounts for buyer committee roles — different personas receive different messaging — and considers contact coverage before sequencing, automatically sourcing net new contacts from large accounts when needed.
The inbound motion is simpler by design: leads that hit a score threshold are automatically sequenced without requiring the rep to touch the Micah app first. Jackson was deliberate about this. Adoption uncertainty — particularly with tenured reps who have established routines — made full reliance on the app too risky for time-sensitive inbound response. The automated sequencing layer ensures SLAs are met regardless of whether someone logs into Micah that day.
This is a harder ask than it sounds to replicate. As Jackson noted, "you finally get things working, and then you run into — okay, well, there's these caveats of like, the record must have all these enrichment fields filled out before we feel comfortable automatically sequencing them." Data readiness is a prerequisite for any of this to function, a theme the conversation returned to repeatedly. This connects directly to the broader question of AI readiness in revenue systems — you can't shortcut the foundational work.
Micah is Cockroach Labs' branded, internal AI-powered GTM application — built by an internal engineer named Carlos using Claude and a shared Python scripting layer connected to more than a dozen company apps via OAuth. The name comes from the company's rock-themed internal product naming convention; mica is a mineral. There is no acronym, though Jackson joked that "marketing intent Claude automation" might be retroactively claimed.
Matthew raised a point worth noting here: naming matters more than it might seem. When you're deploying a tool that's expected to be used across an entire sales and marketing org — not just by the team that built it — the name is part of how people understand what the thing is and whether they trust it. Micah being recognized company-wide as a brand is a deliberate choice, not an accident.
The demo Jackson walked through showed what Micah looks like from a rep's perspective:
The most powerful design decision, in Jackson's framing: Micah shows each rep their own data at a user level, and allows AEs to map contacts to SDRs in real time from within the same app. Changes made by an AE are immediately visible to the SDR they've assigned. This kind of live coordination between roles is something most shared Claude instances can't replicate, because updates in one user's session don't propagate to another.
A score breakdown panel — showing how product signals, ICP fit, and external signals each contributed to a ranking — addresses one of the most common failure modes in rep-facing prioritization tools: reps ignoring the tool because they don't understand or trust why an account ranked the way it did. Transparent scoring is not an aesthetic choice. It's adoption infrastructure.
One of the most practically significant things Jackson said came in the context of signal architecture.
Cockroach Labs now treats Snowflake as their primary source of truth — not Salesforce. Salesforce remains the system of record, but for building the kind of robust, AI-queryable data environment that powers Micah, Snowflake is where everything lives.
"For a long time it was Salesforce had to be that repository. Now with AI and its ability to sift through unstructured data and consolidate information, you don't have those same field limitations in Snowflake. You can bring in a ton of data and have AI summarize it in a cohesive way." — Jackson Mattox
This shift has real architectural implications. Claude is configured to query Snowflake directly, monitoring structured tables for external signals, product signals, and engagement data. Separate tables capture hiring signals (sourced through Clay's relationship with LinkedIn data), outage signals (cross-checked against custom Claude queries because Clay's outage data produced too many false alarms), and other external events relevant to Cockroach Labs' selling motion.
A gateway layer called Agent Hub — a proxy URL for LLM calls — routes requests to multiple AI services at significantly lower cost than calling the API directly through individual tools like Clay. Jackson cited roughly 50% cost reduction for the same query. This is the kind of operational detail that rarely makes it into a conference presentation but that has real budget implications at scale.
The practical implication for RevOps teams is worth sitting with: Salesforce wasn't designed to be a signal warehouse. If you're trying to build AI applications that need to synthesize multiple signal types, enrich account profiles, and serve personalized data to individual reps, you may need to reconsider where the true source of truth lives. This is consistent with the evolving guidance on connecting CRMs to LLMs and building toward AI-ready revenue systems.
One of the session's most honest moments came when Jackson named the organizational consequence of building something like Micah that most teams don't anticipate.
"You build something like this and you've essentially developed a product, and a product needs an owner, and a product is gonna get requests for new features, and all of a sudden you're gonna have a sprint schedule for this thing that you built when you have all these other things to get to as a go-to-market ops person." — Jackson Mattox
Carlos, the engineer who built Micah, is the product owner. Jackson acknowledged being mindful of how much of Carlos's time should be dedicated to Micah versus the other priorities the team carries. There's an open question about whether to eventually hand the tool off to an enablement function. None of that has been resolved, and Jackson presented it as an honest challenge rather than a solved problem.
The adoption concern is real. Micah launched in the current form about two weeks before the session. Jackson's primary worry is that a tool this robust — with multiple data panels, filtering options, plays, email generation, and sequence integration — may overwhelm reps who want simplicity. Older reps with established reporting workflows may not adopt it at all. The parallel auto-sequencing flow for inbound is a hedge against exactly this scenario.
This is the build-versus-buy tension in its sharpest form. You get maximum customization, but you also get maintenance responsibility, a feature request backlog, and an adoption challenge that a commercial product would have solved (or at least documented) for you. This connects to the broader question many RevOps teams face about when to build versus buy — a tradeoff without a universal answer.
The plays model inside Micah — structured messaging strategies tied to specific signals like product launches, outages, marketing engagement, and product usage — came from product marketing and was refined in collaboration with sales leadership. The intention is to give reps a ready framework for responding to the signal they see, rather than leaving them to decide independently what to say and when.
The measurement problem is unsolved. Jackson was candid that he attended a conference the week before the session and asked other operators running plays the same question: how do you know what's working? Nobody had a definitive answer. The current plan is to use Outreach sequence tags tied to specific plays and then evaluate sequence-level success metrics, but Jackson acknowledged this is still directional rather than precise.
Matthew pushed on the signal-to-noise question: how do you decide which signals to surface and which to suppress? Jackson's answer was surprisingly top-down: overcommunicate for now, show reps everything available, and let feedback drive pruning over time.
"Right now, it's like, because we have the capabilities of getting it, let's get it and put it in front of them in the off chance that it does work." — Jackson Mattox
The logic is pragmatic. When you're building new signal infrastructure, you don't yet have enough data to know which signals actually drive outcomes. Surfacing everything — while building in score transparency so reps understand what they're seeing — is a reasonable starting position. The alternative, curating too aggressively up front, risks discarding signals that turn out to matter. This is a reasonable approach while data management fundamentals are still being established.
One genuinely forward-looking idea Jackson raised: rather than a purely account-level ICP score, Cockroach Labs is considering a product-fit score that evaluates the specific business units or products within an enterprise account that are most likely to benefit from Cockroach DB. The granularity of this kind of scoring would have been computationally and logistically out of reach a few years ago. AI makes it tractable.
The live poll results landed exactly where Dom predicted: data quality was the top challenge among attendees scaling AI. It was not a surprising result.
Dom's framing of why data quality is the prerequisite rather than just one item on a checklist was precise:
"No matter how fancy AI gets, it's still — if it's based on bad training data or bad data itself, it's gonna lead to problems where go-to-market teams can't actively and accurately action on what they need to." — Dom Freschi
Jackson added the operational texture: when AI tools can query and look for specific records, duplicates and inconsistent fields don't just create minor annoyances — they create ambiguity about which record is correct, and the AI gets confused. Territory assignments go wrong. Records bubble up incorrectly. The compound effects of bad data are amplified when an AI layer is processing those records at scale and speed. Nine common pipeline hygiene fixes become even more urgent when an AI agent is acting on what it finds.
Jackson explained that Openprise fits into Cockroach Labs' stack as the layer that cleans records at scale, flags duplicates, handles lead-to-account matching from list uploads, and prevents new duplicates when immediate contact-routing flows run ahead of full deduplication logic. He used a phrase worth highlighting: Openprise functions as "a trusted, almost like a RevOps employee for cleanup" — a background process that catches the noise created by faster-moving AI workflows that prioritize speed over hygiene.
Dom extended this point to cost: dirty data increases token consumption. When an AI model has to parse duplicate records, reconcile inconsistent field values, or evaluate ambiguous account relationships, it uses more tokens doing so. Cleaner inputs produce more efficient outputs — both in quality and in cost. Right-sizing models (not defaulting to Claude Opus when a smaller reasoning model is sufficient) compounds these savings further.
Openprise is also extending its capabilities toward AI-native data orchestration — including Model Context Protocol (MCP) integration — to help teams balance probabilistic AI judgment with the deterministic rules required for compliant, predictable data processing.
The recurring theme across every section of this session is the same: AI amplifies whatever your GTM foundation already is. If the data is clean, the signals are structured, and the plays are grounded in real product marketing strategy, AI accelerates. If the foundation has gaps — duplicates, inconsistent territory fields, unenriched records — AI finds those gaps faster, surfaces them more visibly, and makes them more expensive to ignore. The teams making real progress are the ones who treated the unglamorous data work as a prerequisite rather than a distraction.
Learn more about how Openprise helps revenue operations teams acquire, clean, and orchestrate go-to-market data at scale — and build the foundation that AI-powered workflows depend on.
Check out our blog, join our community and subscribe to our YouTube Channel for more insights.
