# The Building Blocks of GTM Orchestration — Arman Vaziri, Ramp AI Engineer · 2026-08-26 Arman Vaziri, who leads product and sales led growth engineering at Ramp, details go-to-market orchestration: an intent — offering Pro V1 golf balls to golfers at East Coast construction companies — becomes targeted outbound, paid creative, landing page and in-app nudges. He argues the bottleneck was never ideas but messy data, rep busy work, and coordination cost; Ramp's answer was an internal CDP on Kafka and Postgres, plus embedded unstructured data for search. Pre-meeting briefs for account managers map attendee emails to accounts and run as durable Temporal threads; a skill library for custom brief formats drove adoption. For smaller teams, build narrow automations first — three years ago two people used GPT-3.5 for outbound — because nobody gets a year to design a perfect architecture. ## Questions this episode answers ### What does Arman Vaziri mean by go-to-market orchestration? Arman Vaziri, Ramp's head of product and sales-led growth engineering, defines it as describing a go-to-market motion—playbooks, experiments, or evergreen campaigns—and automatically distributing it across channels like outbound, ads, and web. He says the bottleneck is not ideas but everything after: pulling an audience, convincing people to adopt playbooks, and reducing coordination cost. [0:28](https://aiengineer.podhood.com/b0537a87-de9f-43fd-b5d9-e98337f4db42?t=28000) ### How did Ramp build an internal customer data platform? Arman says they started with a consistent data foundation, effectively an internal customer data platform. It combines CRM, product, enrichment, web, buying signals, and interaction data; real-time events are piped onto Kafka and consumed into Postgres to maintain transactional guarantees and referential integrity, while unstructured data is embedded for search, and DBT and Snowflake offline batch compute is piped back via River CTL. [5:33](https://aiengineer.podhood.com/b0537a87-de9f-43fd-b5d9-e98337f4db42?t=333000) ### How does Ramp use Temporal for its go-to-market agents? Arman says they built a durable execution system around Temporal, where each tool call and model call is an activity. If a worker goes down, execution resumes from accumulated state instead of reprocessing from the beginning. Temporal also offers scoped tool access for different agents and human-in-the-loop tooling to pause, get input, and resume. [10:12](https://aiengineer.podhood.com/b0537a87-de9f-43fd-b5d9-e98337f4db42?t=612000) ### What advice does Arman Vaziri give smaller companies building GTM automation? Arman advises finding very specific use cases you can build automation around and solving real problems first. He says three years ago there were two of them, building automated outbound with GPT-3.5 to pull data and generate personalized copy. You cannot spend a year designing perfect architecture; piece together vertical solutions and stick them together. [18:42](https://aiengineer.podhood.com/b0537a87-de9f-43fd-b5d9-e98337f4db42?t=1122000) ## Key moments - **[0:00] Intro** - [0:28] Arman Vaziri defines go-to-market orchestration as describing a motion and automatically distributing it across outbound, ads, web and in-app - **[1:59] Golf example** - [1:59] Arman Vaziri's running example: offer Pro V1 golf balls to golfers at East Coast construction companies to try Ramp - **[2:37] Challenges** - **[3:53] Approach** - **[5:33] Data foundation** - [5:34] Ramp built an internal customer data platform that unifies CRM, product, enrichment, web and buying-signal data - **[8:08] One team** - [8:08] Arman Vaziri advises solving go-to-market automation for one team first, then scaling it horizontally to other teams - [8:35] Ramp's pre-meeting briefs pull product usage, account vitals, open tickets and agenda into one view for account managers - [9:55] Mapping attendee emails to accounts is a sneaky hard problem at Ramp because one email can represent multiple businesses - **[10:12] Execution** - [10:24] Every Ramp go-to-market run is a durable Temporal thread, so a dead worker resumes from accumulated state instead of reprocessing - [10:49] “Unstructured information is probably the most valuable thing you're sitting on,” says Arman Vaziri on Ramp's data stack - [12:12] Ramp's skill library lets employees define their own meeting-brief format in text, which drove adoption - **[13:03] Extending** - **[15:31] Orchestration** - [15:31] Arman Vaziri says offering Pro V1 golf balls to East Coast construction company golfers 'works really well' - [16:28] Describing one intent generates the Pro V1 campaign's audience, outbound sequences, paid creative, landing page and in-app nudges, says Arman Vaziri - **[18:32] Smaller companies** - [18:32] Q: How should a smaller company build go-to-market orchestration? A: Build narrow automations for specific problems first, then piece them together ## Speakers - **Arman Vaziri** (guest) ## Topics AI Strategy, Enterprise AI Solutions ## Mentioned RAMP (company), GPT-3.5 (product), Kafka (product), Postgres (product), River CTL (product), Snowflake (product), Temporal (product), TurboPuffer (product), dbt (product) ## Transcript ### Intro **Arman Vaziri** [0:13] Yeah, I really appreciate everybody showing up. Uh, as Mada mentioned, my name's Arman, I lead our product and sales led growth engineering teams at Ramp. Um, and today I'm going to talk to you about, uh, the building blocks of go-to-market orchestration. And, um, to kick it off, like, what do I mean by go-to-market orchestration? Effectively, like, what we're building towards is the ability to just describe a motion,right? Whether it's like playbooks, or experiments, or like evergreen campaigns that you want to run, and how those get, like, distributed across the channels through which you actually execute your go-to-market,right? Whether it's outbound, or ads, or web, or whatever. Um, we want the ability to kind of describe this and automate that output. And this really started a few years ago, where we kind of noticed that, uh, there's a ton of great ideas. You know, like, everybody across product, and data, and engineering, and go-to-market have, like, really good ideas for things that they want to do. And the bottleneck is kind of like everything after that,right? How do you go pull an audience to go and target? How do you go and convince a bunch of people to, like, um, abide by whatever strategy that you've come up with, or playbooks, or enablement materials? Um, and we wanted to try to aim to, uh, reduce that coordination cost. So there's parts of this where we could see it as, like, an engineering problem. Even, like, a few years ago, just go and create, like, a consistent data substrate, go and, like, federate that across the different systems through which you, uh, run your go-to-market. And obviously, in the last few years, agents have really, like, deepened our ability to go and, like, push the level of automation that you can do on behalf of operators, like, as close as possible to those points of execution. ### Golf example **Arman Vaziri** [1:59] Um, so, like, really specifically, uh, I'm a golfer. Suppose I want to offer golfers at, uh, East Coast construction companies an incentive to, like, try Ramp, talk to sales, whatever. Uh, and we want to be able to go and spin up an audience of, uh, golfers at East Coast construction companies, spin up, like, an incentive. Let's go offer, like, some Pro V1 golf balls to, uh, these people, go create, like, outbound sequences, generate the copy, generate, uh, creative for paid ads and for web, maybe show some in-app notifications for your customers, and do all of that seamlessly by just describing the intent,right? ### Challenges **Arman Vaziri** [2:37] And probably more than just this one sentence. Um, so a few years ago, we kind of identified, uh, a few fundamental challenges here. Um, as was previously mentioned, uh, the necessary data for this was just messy, inconsistent across systems,right? Everybody's operating off of a different, uh, source of truth. And that makes it, like, effectively impossible to go and distribute some coordinated action across these different go-to-market teams and channels. Uh, the next is that, like, reps were just buried in busy work,right? Even if, like, you have the best intentions, I want to go and, like, run this campaign, uh, I want your help doing it. The reality is that, like, uh, our sales teams are in back-to-back-to-back-to-back meetings all day. They're outbounding, they're selling. And, um, the operational burden of, like, doing everything in between sales was just really high, uh, which made kind of, like, really scaling out experimentation and creativity challenging. Uh, and similar to that, just the coordination and distribution are expensive,right? If you're like, I have this idea, I'm going to go write this, like, proposal, this enablement material, I'm going to go try to, like, convince a bunch of people to go and use all of this. That's just, like, a really challenging thing to do on any, like, pace that's not on the order of, like, months. Uh, so, um, over the last few years, we've been trying to solve this problem from the ground up,right? How can we start with that, uh, ingestion and consistency problem, uh, and data quality, which is just, like, you know, on the roadmap every quarter? ### Approach **Arman Vaziri** [4:09] Um, how can we then go build those vertical efficiency and growth levers, uh, saving people time, uh, in, like, managing operations and execution, uh, as well as, like, how can we improve conversion rates, make people more performant by being able to kind of scale some of these more, like, uh, informed and personalized and creative strategies? And then how can we extend this horizontally,right? Teams have very common workflows at some level,right? Everybody wants to outbound, everybody has meetings. Uh, how can we go take the patterns that we build for one team and start to just mirror it to others? Uh, and now kind of where we're at is, like, this distribution and coordination problem,right? How can you go and execute across multiple channels simultaneously through just, like, the description of intent? So, yeah, I'll get into the building blocks, um, really broadly. Uh, go-to-market agents are complicated. Um, in order to do this effectively,right, your agents have to understand pretty much the entirety of your company, how you go to market, why products are useful, uh, how to kind of, like, segment your buyers, your prospects, your customers, uh, from people who have, like, never heard about you, and you have, like, no information on them, and they have no information on you, all the way to, like, customers who are actively using your products, who have, like, a totally different set of, um, you know, problems that you have to work with. Um, and to just start to get a little technical here, um, we started with, like, this consistent data foundation, uh, problem. And if you're looking at this and you're like, that looks like a CVP, uh, yeah, you're, you'reright. ### Data foundation **Arman Vaziri** [5:50] Uh, we effectively went and built, um, an internal customer data platform at Ramp, uh, where we're effectively doing your very traditional things. We're going to take CRM data, product data, uh, enrichment data, um, web data, buying signals, you know, whether it's things that are internally modeled, like, um, I don't know, we think that this customer has a high propensity to attach to procurement or treasury, uh, all the way to things that are, like, external signals, like funding announcements, um, as well as, like, interaction data,right? Emails, meetings, calls, uh, page views. Um, and on the signal side of this,right, we have some set of real-time events that are coming in, uh, things like emails. You can go and pipe them onto a Kafka topic, consume them, uh, and then funnel them back into, uh, both, like, we have, like, a Postgres database that backs all of this. It enables us to maintain, like, transactional guarantees, referential integrity between the entities that exist and the different entities that exist,right, between your CRM, between your product, between third parties, um, and attribute everything to theright level of detail, which we found to be, like, a pretty important problem, as well as all the associated metadata around capturing, like, where did this come from, when did it, you know, come in, um, as well as starting to embed a lot of this data,right? So much sales data is just inherently, um, unstructured,right? You have, like, call transcripts, you have emails, you have notes, and the ability to kind of search across that is really valuable. Uh, we have a set of online batch jobs, which are really just calling a lot of APIs, uh, for the most part. Uh, Ramp's addressable market is pretty much like the entire US, um, and now expanding internationally. So being able to kind of, like, precompute, preprocess, preingest, like, all this enrichment data about who we can sell to and who we're already selling to is, um, really important for us. And then, um, as previously mentioned, a ton of work has gone into the offline piece of this with, uh, DBT, Snowflake, pulling everything into our warehouse, doing a lot of offline batch compute, and then piping that in via River CTL back into the same layer. Uh, next, more tactically, the way we tend to approach these problems is solve for one team first, then s-scale horizontally. Um, as I mentioned before, you have, like, a very overlapping set of problems that exist,right? Everybody wants to do automated outbound, uh, everybody wants to prepare for meetings, uh, whereas certain teams may have, like, problems or, like, things that they do that are isolated to them, like QBR generation. ### One team **Arman Vaziri** [8:35] Um, and to get into an example, like, one of the things that we shipped is, like, pre-meeting briefs,right? Um, for AMs, AMs are, like, account managers. Uh, they kind of manage the customer relationships that exist, trying to ensure that customers are using Ramp, uh, as best as possible. And, um, there's a lot of, like, important context that goes into, like, uh, a meeting,right? It's like, what are we talking about? Who are we meeting with? Um, what is the AM trying to do? Like, what are the product usage information? What are the account vitals? What's the agenda that we want to tackle? And similarly, like, what is the customer trying to do,right? Do they have open tickets that they're trying to address? Did they, like, email us saying that there is, like, a specific thing they're trying to talk about? And how can we pull this together for AMs so that they can go in prepared, uh, and kind of manage the, uh, operational piece of just being in back-to-back-to-back meetings all day? Um, again, technically, uh, the place to start with this is obviously if we're trying to generate a pre-meeting brief, we need to know when these meetings are, uh, so we can pipe in meeting events, um, do some hydration, map, uh, things like attendee emails, meeting titles, uh, back to the accounts that we're meeting with. This is, like, a sneaky hard problem at Ramp because you have the same emails that can work on behalf of multiple businesses. So it's kind of like a fuzzy match, and we can go and persist that so that way every downstream consumer of, like, hey, I care about this meeting doesn't have to go and, like, recompute this from the ground up. ### Execution **Arman Vaziri** [10:12] And also, as mentioned in the previous talk, uh, we've also built a system around durable, uh, execution,right? That's pretty agnostic to the trigger that comes in. Everything is represented as a durable thread built around Temporal, representing each tool call and model call as an activity. That way, if, uh, you know, like, a worker goes out for some reason, it can resume, uh, execution from where it left off, uh, pulling together all the state that had accumulated at that point in time instead of starting back from, like, the beginning of the thread and trying to reprocess everything, which would be very inefficient and slow. Um, there's also, like, great out-of-the-box capabilities for things like config scope tool calls. Uh, different agents are going to have access to different, uh, sets of tools, which give them access to different information, different integrations, uh, and different skills that might be necessary to actually perform the work. And similarly, there's things like, uh, human-in-the-loop, uh, tooling to just pause execution, get input, resume. Um, and then getting to the, uh, unstructured piece of this, as I mentioned, like, unstructured information is probably, like, the most valuable thing you're sitting on, uh, within your, um, warehouse or, or your notes or wherever you store this today. Uh, so we have some set of real-time data coming in, um, meeting transcripts, emails. We have some set of, like, uh, batch jobs that are kind of pulling in, like, enablement materials, product knowledge, playbooks, um, chunking them, embedding them, putting them in TurboPuffer, and it allows you to kind of it allows agents to go and search, like, what do I care about? What am I trying to answerright now? And doing some combination of, like, uh, vector search, attribute search, keyword search in order to pull information scoped to, like, a specific account, for example, uh, without having to pull in, like, the full raw corpus into agent context, um, which would also be very inefficient, very expensive. And similarly, we've gone and built a skill library to allow people to customize their agents,right? Getting back to the, uh, meeting brief example, different people have different formats that they care about. They have different information that they care about, um, and allowing them to kind of represent that, uh, in text, giving that to the agent to pull it together, uh, has been, like, very valuable for getting adoption. And putting all this together, you get an operational background agent,right? You have, like, every night we're going to go and generate these things, fan out a set of agents that are going to go and compute, uh, per account, uh, meeting prep, uh, which gives, uh, or which use some set of tools giving them access to, like, uh, that online CDP and Postgres I had mentioned, the vector database, uh, meeting prep skills that we own at a system level, as well as, like, custom instructions that users are providing themselves. ### Extending **Arman Vaziri** [13:03] And getting into the extending the blocks, um, the goal is for these foundations to speed up the next thing,right? Meetings are super important. We want to be able to generate things like post-meeting follow-ups and things like automatic CRM updates,right, which can pull in the transcript and say, like, hey, we discussed this potential expansion opportunity. Let me go and prefill all the information needed to create that opportunity, get a thumbs-up from a rep, and just make it happen. Um, and similarly, we want to extend it horizontally to other teams,right, which is mainly an exercise of creating specific skills, data integrations, um, and, like, just data ingestion itself, where we can say, like, okay, email, call transcript embeddings, custom instructions, generalizable. But if we're building this for AEs who are hand-handling, like, pre-sales, um, opportunities, we need to go and focus more on, like, third-party data instead of a bunch of product data that we have already. And that needs to be, uh, incorporated into our customer data platform. The skills need to go and reference kind of, like, a different set of, uh, information that we have on the people that we're trying to sell to. And similarly, uh, we've built this in a way where employees have access to the same tools and skills that are being used for the background agents that we're creating,right? We set up a what we call, like, our GTM or CP, uh, and this is basically just, like, uh, a window into the same exact tools that we've set up for these background agents. So that way the things that we build are just kind of automatically federated out to people who want to go and build their own agents. They want to go chat with the information that we're setting up, uh, and build their own automations. And they're building a ton of them. Uh, this is just, like, uh, a glimpse into some of the analytics that we've, uh, done, taking the reasoning generated by, uh, the MCP, uh, tool calls, you know, that we've, uh, that are being executed, uh, remotely. And this compounds because, like, when people go and build their own thing and they go and connect to our MCP, they're basically telling us, like, here is a problem that I have. Here's how I'm trying to solve this problem. And we can go and work with them to be, like, okay, we can just go and productionize this, uh, distribute this to everybody who probably has similar problems. And they give us the prompts and the skills and the, like, you know, even applications that they're vibe coding, uh, to just, like, really simplify our ability to just go and productionize, um, like, these use cases. So now you're probably wondering, uh, what about that golf example that I had mentioned at the beginning, um, the orchestration problem. Um, the, the point that I'm trying to convey by talking about all these specific things that we're doing is that these vertical builds that we're creating are the foundation of, like, uh, multi-team, multi-channel, like, distribution. ### Orchestration **Arman Vaziri** [15:55] Um, if we want to be able to say, like, here is a playbook, here's how you sell procurement, here's how you sell to construction, or here are, like, wacky experiment ideas that we have, uh, like, offering, uh, Pro V1s to golfers, which is actually, like, uh, it works really well. Um, we need to be able to say, like, uh, take in that corpus of information of things that people are trying to do and federate that out through the background agents that are actually creating these artifacts that people are, like, using to operationalize, like, go to market and execute. So for my Pro V1 golf example, um, the goal is to funnel this into Ramp revenue, uh, the internal application that we have built, um, and go and, like, effectively, like, funnel this into some of these vertical solutions that we've created,right? So you can say, like, for SDRs, we want to go and create an audience of here are the golfers that we want to send things to. We can go and generate, like, personalized copy and sequences that they can go and send. Maybe we want to go and create web landing pages and spin up the, uh, images and the creative that we'll point these, uh, email sequences to. And we can do all of that through just, like, the description of, like, here's my intent, get the people who own these channels to review them and sign off, and really allow us to just, like, move a lot quicker in how we, uh, ship and, like, scale creatively, um, across all these different go-to-market channels. So the goal of this is to ship faster, ship safer, um, scale our teams, become more efficient. And, um, with these campaigns, we can go and execute them across, like, multiple channels with consistent audience targeting. Um, agents can go and hold context on multiple things that are, like, options,right? We can go and execute this campaign or that campaign or that experiment and balance the, like, traditional multi-arm bandit problem of, like, exploring, like, new possibilities versus, like, being safe and, like, going into just known returns. Um, and then we can build in guardrails as well to go and, um, effectively, like, manage compliance rules, rules of engagement, being context-aware, making sure we're not doing the same thing over and over again. Um, and yeah, just do this on behalf of everybody. And those are the building blocks of go-to-market orchestration. Thank you, everybody. **Host** [18:18] Excellent. We have probably time for one question. Hey, there we go. ### Smaller companies **Guest** [18:32] Hey. So just curious, um, if how would you approach building something like this for a smaller company or for a company that's, that's just getting started? **Guest 2** [18:42] Yeah. I think a few people before have, like, mentioned something similar, but I would go and, like, find the very specific use cases that you can build automation around and just, like, solve really specific problems that exist first. Um, like, three years ago, there was two of us, and we were building, like, automated outbound,right? So, like, we were just trying to figure out, like, how can we go and use GPT-3.5 and, like, put personalized copy, uh, into some sequences and go and, like, pull data from, uh, wherever to go and generate that. And by doing these things and solving these problems, you get, like, a really good understanding of how this works, how it could extend to other teams, um, and solving, like, real problems as you go. The reality is that, like, you can't spend, like, a year going and building, like, some really complicated system architecture that, like, is perfect. So you have to, like, piece together the vertical solutions, uh, and then stick them together. --- This library is powered by PodHood (https://podhood.com), the podcast website platform.