How Ramp Built Its GTM Orchestration Engine

The golf balls are not the point.

Arman Vaziri, who leads product and sales-led growth engineering at Ramp, opens his talk at the AI Engineer conference with a deliberately silly example: target golfers at East Coast construction companies, offer them Titleist Pro V1s, get them to try Ramp. He then mentions, almost as a footnote, that it actually works really well — and moves on. The joke lands because the absurdity is real. Someone at Ramp had that idea. The idea wasn't the problem. The problem was everything that has to happen between "we should target construction-company golfers" and a live outbound sequence, a paid creative, a web landing page, and in-app nudges all pointing at the same audience. Historically, that gap measured in months.

What Vaziri is describing — and what Ramp has spent several years building — is a system designed to collapse that gap to something closer to the time it takes to write a coherent paragraph.

---

The bottleneck was never creativity

This is worth sitting with, because it runs counter to how most go-to-market problems get diagnosed. The common failure mode in sales and marketing is assumed to be a lack of good ideas. Vaziri's diagnosis is the opposite: ideas are abundant. "Everybody across product and data and engineering and go-to-market have really good ideas for things that they want to do. And the bottleneck is kind of like everything after that."

The three bottlenecks he identified a few years ago: messy, inconsistent data across systems (everyone operating from a different source of truth); sales reps buried in operational busywork between the actual selling; and the coordination cost of convincing enough people to adopt a new playbook — a process that "can't happen on any pace that's not on the order of months."

As Cognism notes in their GTM data orchestration guide, the core challenge is that GTM data orchestration goes "beyond point-to-point integrations by creating a dynamic data" layer where every team, system, and signal works in sync. That's the gap Ramp decided to close from the inside out, by building its own.

---

The data foundation first — because there's no shortcut

Ramp's solution started where all serious GTM infrastructure has to start: the data. Vaziri describes building what is, functionally, an internal customer data platform — CRM data, product usage data, enrichment data, web signals, buying signals (both internally modeled propensity scores and external triggers like funding announcements), plus interaction data from emails, calls, and meetings. Real-time events flow onto Kafka topics; a Postgres store maintains referential integrity across entities living in different source systems; and the unstructured half — call transcripts, emails, notes — gets embedded for vector search.

The phrase he uses to describe the Postgres layer is "transactional guarantees," and that specificity matters. A lot of GTM tooling treats data consistency as someone else's problem. When you're running multi-channel campaigns with agents making decisions on behalf of sales reps, inconsistency doesn't just produce wrong numbers — it produces embarrassing or contradictory customer interactions. Ramp needed attribution to the right entity, with full metadata provenance, before any of the agent work could be trusted.

What's notable here is what Ramp didn't do: buy a third-party CDP and configure it. The build-vs-buy decision, largely unstated in Vaziri's talk, seems to have been made in favor of building — presumably because the granularity and real-time requirements were specific enough that off-the-shelf options couldn't satisfy them without significant customization anyway. That's a meaningful infrastructure bet, and it shapes everything downstream.

---

Solve one team, then copy the pattern

The architectural principle Vaziri keeps returning to is horizontal scaling via vertical depth first. Don't design the universal system; solve a real problem for one team well enough that the pattern becomes portable.

The example he walks through in detail is pre-meeting briefs for account managers. AMs are in back-to-back customer meetings all day. Before each one, they need: who they're meeting with, what the account's product usage looks like, open support tickets, the customer's stated agenda, and what the AM is trying to accomplish. Previously, assembling that was manual — tabs, CRM lookups, Slack messages. Now it's an overnight background job: agents fan out across accounts, pull from the CDP and the vector database, apply any custom format the AM has specified, and deliver a brief before the meeting starts.

The "sneaky hard" problem Vaziri calls out here is email-to-account mapping. At Ramp, an individual can work on behalf of multiple businesses, so a single attendee email might map to several accounts. Solving that fuzzy-match problem once — and persisting the result — means every downstream consumer of meeting data doesn't have to re-solve it independently.

The durability layer underneath all of this is built on Temporal. Every run is a durable thread, with each tool call and model call as an activity. If a worker dies mid-execution, it resumes from where it left off rather than starting over. That's not a small detail. Anyone who has built long-running AI agent workflows knows that failure handling in the middle of a multi-step process is where systems get ugly fast. Vaziri treats this as a foundational requirement, not an optimization.

---

The skill library — and why adoption actually happened

Here's where the story gets interesting from an operator's perspective. The technology is sophisticated, but Vaziri is candid that adoption didn't happen because the briefs were technically impressive. It happened because the team built a skill library that lets account managers define their own brief format.

"Different people have different formats that they care about. They have different information that they care about, and allowing them to kind of represent that, in text, giving that to the agent to pull it together, has been like very valuable for getting adoption."

This is a pattern worth noting more broadly. The Highspot revenue orchestration research points to automated GTM coordination replacing manual alignment meetings — but automated coordination that tells people how to do their jobs, rather than adapting to how people already work, tends to get ignored. Ramp's skill library sidesteps that trap by making customization a first-class feature rather than an afterthought. The system meets users where they are.

The MCP angle he introduces near the end extends this logic further. Ramp built what Vaziri calls a "GT MCP" — essentially a window that exposes the same tools powering the background agents to any employee who wants to build their own automations. The compounding effect: when employees connect to the MCP and start building things, they're revealing their unsolved problems explicitly. The team can watch what people are trying to do, productionize the patterns that generalize, and distribute them back. User adoption generates the product roadmap.

---

Back to the golf balls

By the time Vaziri returns to the Pro V1 example, it lands differently. The point was never that golf-ball incentives are clever. The point is that the idea — any idea, however specific or wacky — should be able to travel from a sentence of intent to a live, multi-channel campaign without requiring months of data wrangling, enablement writing, and organizational persuasion.

For SDRs: an audience of golfers at East Coast construction companies, generated from the CDP. Personalized outbound sequences, written by agents. Landing pages and paid creative spun up. In-app nudges for existing customers. Guardrails to prevent the same person from getting hit across every channel simultaneously. A multi-armed bandit approach to balancing experiment exploration against known-return campaigns.

All triggered by describing the intent.

The question someone asked at the end of the talk — how does a smaller team approach this? — got a characteristically grounded answer: "You can't spend a year going and building some really complicated system architecture that is perfect. So you have to piece together the vertical solutions and then stick them together." Three years ago, Vaziri says, there were two people on the team running GPT-3.5 to drop personalized copy into outbound sequences. That was the first vertical slice. Everything else was built on top of understanding that one thing well.

The ambition of the full system is real. So is the humility of the starting point. The question for any team watching this is which of those two facts is more useful to them right now.

---

By Alex Volkov, Startup Ecosystem & Venture Capital Reporter, Buzzrag