# The Building Blocks of GTM Orchestration Arman Vaziri, Ramp | AI Engineer World's Fair 2026 | 19:55 Source: https://www.youtube.com/watch?v=VjEP0xqTUI0 Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks. Page: https://aietalks.com/talks/the-building-blocks-of-gtm-orchestration Published: 2026-08-26 Tags: agent-skills, agents, data-pipelines, human-in-the-loop, workflows ## TL;DR - GTM orchestration should let a team describe an intent and distribute the resulting work across outbound, ads, web, and in-app channels. - A shared customer data platform, durable execution, searchable unstructured data, and configurable skills provide the foundation for these automations. - Smaller companies should start with narrow, useful automations and connect those vertical solutions over time instead of designing a perfect architecture first. ## Summary Arman Vaziri describes GTM orchestration as the ability to describe a playbook, experiment, or campaign and distribute its execution across channels. He argues that the hard part is usually after the idea: finding the audience, preparing the material, coordinating teams, and getting work done without waiting months. Ramp built an internal customer data platform that combines CRM, product, enrichment, buying-signal, and interaction data. Real-time events flow through Kafka, while Postgres maintains relationships across systems and unstructured content is embedded for search. Vaziri then explains how Ramp applies these foundations to pre-meeting briefs, durable Temporal workflows, configurable skills, and employee-facing tools. The same pieces can support post-meeting follow-ups, CRM updates, outbound sequences, landing pages, and paid creative. His advice to smaller teams is practical: automate a narrow problem first, learn from real use, and expand sideways rather than spending a year building an ideal architecture. ## Key ideas ### GTM orchestration turns an intent into coordinated channel work [00:31](https://www.youtube.com/watch?v=VjEP0xqTUI0&t=31s) Vaziri defines GTM orchestration as describing a motion, such as a playbook, experiment, or evergreen campaign, and distributing it across the channels used to execute go-to-market work. Those channels include outbound, ads, and web. The aim is to automate the output from that description. He says the bottleneck was not a lack of ideas across product, data, engineering, and go-to-market. The work after the idea was the problem: pulling an audience, creating enablement material, and persuading people to follow a strategy. Ramp wanted to reduce that coordination cost with a consistent data layer and automation close to the points where operators act. ### The golf-ball example shows what intent-driven execution could cover [01:56](https://www.youtube.com/watch?v=VjEP0xqTUI0&t=116s) Vaziri uses a campaign aimed at golfers at East Coast construction companies as a concrete example. A description of the intent could lead to an audience, an incentive such as Pro V1 golf balls, outbound sequences, personalized copy, paid-ad creative, web content, and in-app notifications. The campaign is not confined to one team or one channel. Later, he says the input could be a playbook for selling procurement, a construction-focused campaign, or an unusual experiment. The system would route that intent into the vertical solutions that create the artifacts people need, with channel owners reviewing and approving the work. ### Messy data, rep busywork, and coordination slow down experimentation [02:50](https://www.youtube.com/watch?v=VjEP0xqTUI0&t=170s) Ramp identified three related obstacles. Data was inconsistent across systems, so teams worked from different sources of truth and could not easily coordinate an action across channels. Sales representatives were already in back-to-back meetings, outbounding, and selling, which left little time for campaign operations. Coordination was also expensive because someone had to write a proposal or enablement material and persuade many people to use it. Vaziri says this made experimentation and creative work difficult to scale on any timescale shorter than months. Ramp approached the problem through data consistency, workflow efficiency, and horizontal reuse across teams. ### Ramp's internal customer data platform joins structured and unstructured signals [05:34](https://www.youtube.com/watch?v=VjEP0xqTUI0&t=334s) Ramp built an internal customer data platform that combines CRM, product, enrichment, web, buying-signal, and interaction data. Signals include internal predictions about product expansion and external events such as funding announcements. Interaction data includes emails, meetings, calls, and page views. Real-time events can flow through Kafka, while a Postgres database maintains transactional guarantees and referential integrity between CRM, product, and third-party entities. Ramp also stores metadata about where and when data arrived. Call transcripts, emails, and notes are embedded so agents can search them. Offline jobs use DBT and Snowflake, then send processed data back through reverse ETL. ### Ramp builds one team's workflow before reusing its foundations [08:10](https://www.youtube.com/watch?v=VjEP0xqTUI0&t=490s) Vaziri's practical implementation pattern is to solve for one team first and then scale horizontally. Many teams share workflows such as outbound and meeting preparation, while others have more specialized needs such as QBR generation. Ramp started with pre-meeting briefs for account managers. The brief gathers meeting context, attendees, account vitals, product usage, the agenda, open customer tickets, and emails about topics the customer wants to discuss. This gives account managers preparation for a day of meetings and removes some of the operational work between those meetings. ### Durable workflows prevent failed workers from restarting the whole task [10:14](https://www.youtube.com/watch?v=VjEP0xqTUI0&t=614s) Ramp represents each automation as a durable thread built around Temporal. Tool calls and model calls are individual activities. If a worker stops, execution can resume from the point where it failed, using the state accumulated so far instead of reprocessing the entire thread. Vaziri also describes configuration-scoped tool access, since agents may need different information sources and integrations. Human-in-the-loop tools can pause execution, collect input, and resume. For meeting briefs, the system receives meeting events, hydrates the data, and maps attendee emails and meeting titles to accounts. This mapping is difficult because one email address may represent multiple businesses. ### Configurable skills help users adopt agent-generated work [12:20](https://www.youtube.com/watch?v=VjEP0xqTUI0&t=740s) Ramp built a skill library so employees can define the format and information they want from an agent. Different people prefer different meeting-brief structures, and allowing those preferences to be written as text has helped adoption. The background process can run each night, fan out agents per account, and give them access to the online customer data platform, a vector database, system-level skills, and user instructions. Ramp also exposes the same tools and skills through its GT MCP interface. Employees can use them to chat with company information or build their own automations, and those experiments can later be productionized for wider use. ### The same foundations can produce multi-channel campaigns with review and guardrails [15:33](https://www.youtube.com/watch?v=VjEP0xqTUI0&t=933s) For the golf campaign, Vaziri describes a flow into Ramp's internal revenue application. The system could identify the SDR audience, generate personalized copy and sequences, create landing pages, and produce images or other paid creative. People responsible for each channel would review and approve the outputs. Vaziri says a coordinated system can keep audience targeting consistent across channels, hold context across campaign options, and balance exploration of new experiments with safer known approaches. Guardrails can manage compliance rules and rules of engagement, while context can help prevent repeating the same action unnecessarily. ### Smaller teams should automate narrow problems before assembling a larger system [18:32](https://www.youtube.com/watch?v=VjEP0xqTUI0&t=1112s) Vaziri advises smaller companies to find specific use cases and solve them with focused automation. He gives Ramp's earlier example of two people building automated outbound with GPT-3.5, personalized copy, and data pulled from available sources. Working on real problems builds an understanding of how the system works and how it might extend to other teams. He rejects spending a year designing a complicated architecture that is meant to be perfect. His recommendation is to build vertical solutions and connect them as the needs become clear. ## Notable quotes - "The bottleneck is kind of like everything after that, right? How do you go pull an audience to go and target?" (01:09) - "Everything is represented as a durable thread built around Temporal, representing each tool call and model call as an activity." (10:26) - "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." (19:18) - "You have to like piece together the vertical solutions and then stick them together." (19:36) ## Tools & references mentioned - Ramp - Kafka - Postgres - DBT - Snowflake - Temporal - GPT-3.5 - Pro V1 golf balls - Ramp revenue - GT MCP ## Who should watch - You are building internal GTM automation and need a shared data layer across CRM, product, enrichment, and interaction systems. - Your agents need to handle long-running workflows, failures, human approvals, or large amounts of unstructured sales content. - You are on a small team and need a sensible starting point that produces useful automation before a larger platform exists.