How Ramp Rebuilt Its GTM Orchestration System with AI Agents: From Intent to Automated Execution

At the AI Engineer conference, Arman, who leads Ramp's product and sales-driven growth engineering team, shared the complete story of how they built a Go-to-Market (GTM) orchestration system from scratch. This wasn't a conceptual talk — it was a real architecture already running in production, powering Ramp's entire sales growth engine. This article breaks down the building blocks behind it and how one company turned the vision of "describe your intent and let the system execute" into reality.

What Is GTM Orchestration: Automation from Intent to Execution

Arman got straight to the point, defining "GTM orchestration": the team wanted to be able to simply describe an intent — whether it's a playbook, an experiment, or an evergreen marketing campaign — and have those actions automatically distributed across execution channels (outbound, ads, website, in-app notifications, etc.).

Go-to-Market (GTM) orchestration is a systematic methodology that has emerged in the B2B SaaS space in recent years. In traditional GTM workflows, marketing, sales development (SDR), and customer success teams each use separate tools — Salesforce for CRM, Outreach for outbound sequences, Google Ads for advertising — with data siloed between them and coordination done manually. The core idea behind GTM orchestration is to unify these scattered execution channels under a single intelligent scheduling layer, achieving cross-channel consistency through data-driven automation. As an enterprise spend management platform (offering corporate cards, expense management, procurement, and more), Ramp's potential customer base covers virtually every U.S. business, which means its GTM system must be capable of operating at massive scale.

Arman used a highly specific example throughout the talk: suppose Ramp wants to offer an incentive to "golfers at East Coast construction companies" — say, a few boxes of Pro-V1 golf balls — to entice them to try Ramp or engage in a sales conversation. Ideally, the operator simply describes this intent, and the system automatically:

• Builds the target audience profile
• Generates the incentive offer
• Creates outbound sequences with tailored copy
• Produces creative assets for paid ads and the website
• Pushes in-app notifications to existing customers

All of this happens seamlessly by simply "describing the intent." And notably, Arman revealed that the Pro-V1 experiment for golf enthusiasts "actually worked really well."

Three Fundamental Challenges

Several years ago, the team identified the core pain points facing this kind of system:

1. Messy and inconsistent data: Data was scattered across systems, with each team operating from a different "source of truth," making coordinated cross-team, cross-channel actions nearly impossible.
2. Sales reps drowning in busywork: Even with the best campaign ideas, sales teams spent their days in back-to-back meetings, outbound calls, and deal-closing — the operational overhead was enormous, making it difficult to run experiments and creative initiatives at scale.
3. High coordination and distribution costs: Writing a proposal, creating enablement materials, and convincing a group of people to adopt a particular strategy often took months to push through.

Building Block One: A Unified Customer Data Platform (CDP)

Arman admitted that the starting point of the solution "looks like a CDP" — because it is one. Ramp built its own Customer Data Platform in-house, integrating CRM data, product data, enrichment data, web data, and buying signals.

A CDP (Customer Data Platform) is a system that unifies customer data from multiple sources into persistent, addressable customer profiles. Ramp chose to build its own CDP rather than adopt third-party solutions like Segment or mParticle, primarily because of the complexity of its data model — they needed to link CRM transaction data, product usage telemetry, third-party enrichment data (such as Clearbit company info and PitchBook funding data), and behavioral data (web visits, email interactions) all to the same account entity.

These signals include internally modeled judgments (e.g., "this customer has a high propensity to attach to the procurement or treasury module"), external signals (such as funding announcements), and interaction data (emails, meetings, calls, page views).

On the technical architecture side, the system consists of several key layers:

• Real-time event streaming: Real-time events like emails are consumed via Kafka topics and flow back into the system. Kafka is Apache's distributed event streaming platform, known for its high throughput, low latency, and strong durability. It can handle millions of messages per second and is the industry-standard choice for real-time data pipelines.
• Postgres transactional layer: Maintains transactional guarantees and referential integrity between entities, attributes CRM, product, and third-party data to the correct granularity levels, and retains complete metadata (data source, ingestion time, etc.). Postgres's ACID transaction properties ensure data consistency when converging multiple data sources.
• Unstructured data embeddings: A large portion of sales data is unstructured — call transcripts, emails, notes. Converting this content into high-dimensional vector representations via embedding models and storing them in a vector database enables semantic-level retrieval, which is extremely valuable.
• Offline batch processing: Using DBT (Data Build Tool, a SQL-first data transformation tool) with Snowflake cloud data warehouse to pull data into the warehouse for offline computation, then flowing results back through Reverse ETL (the process of writing analytical results from a data warehouse back to operational systems) into the same layer, so analytical insights can directly drive business actions.

Since Ramp's addressable market covers virtually all of the United States and is expanding internationally, pre-computing and pre-processing all enrichment data ahead of time is critical.

Building Block Two: Solve for One Team First, Then Scale Horizontally

Arman emphasized that their core methodology was: solve one team's problem first, then replicate horizontally. Different teams have significant overlapping needs — everyone needs automated outbound, everyone needs meeting prep — while also having unique requirements (like QBR generation). QBR (Quarterly Business Review) is a formal meeting between customer success teams and clients in B2B SaaS, reviewing the past quarter's product usage, ROI outcomes, and next steps. Preparing for QBRs typically requires extensive data aggregation and slide creation.

He used the already-live pre-meeting briefs as an example. This feature was designed for AMs (Account Managers — responsible for maintaining and expanding existing customer relationships). AMs spend their days in back-to-back meetings and need to quickly grasp: the meeting topic, who's attending, product usage data, account health, the agenda, and client-side concerns (any open tickets, specific topics mentioned in emails).

A "Hidden Hard Problem"

Technically, the first step in generating pre-meeting briefs is ingesting calendar events and then performing data hydration — mapping attendee emails and meeting titles back to the corresponding accounts. Data hydration refers to the process of expanding a simple identifier (like an email address) into a complete, richly associated data object — similar to putting flesh on a skeleton. Arman noted this is a "hidden hard problem" at Ramp — the same email might represent multiple companies (for instance, a financial advisor serving several client companies), requiring fuzzy matching. Once a match is made, it's persisted so that all downstream consumers don't need to recompute from scratch.

Durable Execution and Human-in-the-Loop

The system also features a durable execution mechanism built on Temporal, independent of triggers. Temporal is an open-source durable workflow engine (originally called Cadence, developed at Uber) designed to solve reliability problems with long-running workflows in distributed systems. In traditional architectures, if a multi-step automated task (e.g., query customer data → call LLM to generate copy → send email → update CRM) fails at an intermediate step, the entire process usually needs to be rerun from the beginning or relies on complex state management logic. Temporal solves this by encapsulating each step as an Activity and defining the overall process as a Workflow, automatically persisting the execution state of each step.

Every tool call and model call is represented as an activity, forming a durable thread. If a worker unexpectedly crashes, execution can resume from the point of interruption with all previously accumulated state, rather than reprocessing the entire thread from scratch — this is critical for efficiency, since every LLM call has latency and cost. Avoiding unnecessary repeated calls saves money and improves user experience.

The system also includes configurable tool-call scopes (different agents have access to different tool sets) and Human-in-the-Loop capabilities (pause execution, collect human input, then resume). Human-in-the-Loop is an important pattern in AI system design where human review and confirmation are introduced at critical decision points in automated workflows, ensuring AI outputs meet business rules and quality standards — especially important in GTM scenarios involving customer communication and compliance requirements.

Building Block Three: Unstructured Data and the Skill Library

Arman argued that unstructured information is "probably the most valuable thing in your data warehouse." The system ingests meeting transcripts and emails in real time, while batch-processing enablement materials, product knowledge, and playbooks — chunking, embedding, and storing them in TurboPuffer.

TurboPuffer is a vector database optimized for large-scale vector retrieval. The entire pipeline is a core implementation of Retrieval-Augmented Generation (RAG) architecture. The basic idea behind RAG is: rather than stuffing all relevant documents into the LLM's context window (which is limited by token count and incurs high inference costs), first use vector similarity search to find the most relevant document chunks, then inject those chunks into the prompt for the model to reference.

Agents can combine vector search (capturing semantic similarity), attribute search (filtering by account ID, date range, etc.), and keyword search (exact matching of proper nouns) to retrieve information related to a specific account — without stuffing the entire raw corpus into the context window, which is both inefficient and expensive. This three-pronged hybrid search strategy significantly improves both retrieval precision and recall.

They also built a skill library that lets users customize how agents behave. The skill library concept draws from hierarchical task planning in game AI and robotics — decomposing complex tasks into composable, reusable atomic skill units, where each skill encapsulates a specific sequence of tool calls, prompt templates, and output format requirements. Returning to the pre-meeting brief example: different people care about different formats and information dimensions, so allowing them to describe their requirements in text and hand it to the agent is critical for driving tool adoption.

Ultimately, these modules combine into operational backend agents: each night, a batch of agents fans out, computing meeting preparation for each account one by one. "Fan out" is a classic distributed computing pattern where a single task is split into multiple parallel sub-tasks executed simultaneously, dramatically increasing throughput. These agents can access the online CDP, Postgres, the vector database, system-level meeting prep skills, and user-defined instructions.

Building Block Four: Horizontal Federation and GTM MCP

The goal of this infrastructure is to make the next thing faster to build. Since meetings matter, the system naturally extends to post-meeting follow-ups, automatic CRM updates — extracting "we discussed a specific expansion opportunity" from call transcripts, pre-filling the information needed to create an opportunity, and letting the sales rep confirm with a single click.

Scaling horizontally to other teams primarily involves creating specific skills, data integrations, and data ingestion workflows. For example, when building for AEs (Account Executives — responsible for advancing and closing sales deals) handling pre-sale opportunities, the emphasis shifts toward third-party data (company size, industry, tech stack information) rather than existing product usage data.

Even more compelling, Ramp exposed these tools and skills to employees through what they call the GTM MCP. MCP (Model Context Protocol) is an open protocol released by Anthropic in late 2024, designed to standardize how AI models connect to external tools and data sources. It's analogous to a USB-C port for the AI world — defining a unified specification that allows any MCP-compatible AI client (such as Claude Desktop, Cursor, etc.) to connect to any MCP-compatible server. Ramp packaged its internal GTM tool ecosystem as an MCP service, enabling employees to access the same set of tools as the backend agents, chat with the data, and build their own automation workflows — without needing to learn the internal system's APIs.

This creates a powerful compounding effect: when employees connect to MCP and build their own solutions, they're essentially telling the team "I have this problem, and here's how I solved it." The team can then productize the solution and distribute it to everyone facing a similar problem. The prompts, skills, and even vibe coding outputs (a development approach where you describe requirements in natural language and let AI generate the code) that employees contribute dramatically simplify the process of productizing use cases.

Back to Golf: The Endgame of Orchestration

After walking through all these building blocks, Arman revealed their significance: these vertical builds are the foundation for multi-team, multi-channel distribution.

When executing an experiment like "send Pro-V1s to golf enthusiasts," the system feeds the intent into Ramp's internal application "Ramp Revenue," which then distributes to each vertical solution: generating a target golf audience for SDRs (Sales Development Representatives — responsible for initial prospect outreach and qualification), creating personalized copy and sequences, building a website landing page and generating creative assets — all done by describing the intent, then reviewed and signed off by each channel owner.

The value this delivers: faster launches, safer launches, team scalability, and improved efficiency. Multi-channel campaigns can maintain consistent audience targeting, and agents can simultaneously hold context across multiple options, balancing the classic Multi-Armed Bandit problem — the trade-off between exploring new possibilities and exploiting known returns. The Multi-Armed Bandit is a classic reinforcement learning framework. In the GTM context, it manifests as: when the system simultaneously runs multiple marketing experiments (different audience segments, different copy, different incentive offers), it needs to intelligently allocate traffic and resources — without over-concentrating on historically best-performing options (potentially missing better new approaches) or endlessly exploring (wasting resources on ineffective experiments). Classic solutions include ε-greedy, UCB (Upper Confidence Bound), and Thompson Sampling algorithms. The system also includes built-in guardrails to manage compliance rules and rules of engagement (such as preventing the same customer from being contacted by multiple channels in a short time period), avoiding duplicate actions.

Advice for Small Companies: Solve Specific Problems First

When asked "how should small companies or early-stage teams build a similar system," Arman gave a pragmatic answer: find a very specific use case and solve a real, concrete problem first.

He recalled that three years ago, the team was just two people, using GPT-3.5 to inject personalized copy into sequences, pulling data from various sources to generate content. GPT-3.5 was the large language model released by OpenAI in late 2022, also the model behind the initial version of ChatGPT. While its capabilities were far from today's GPT-4o or Claude 3.5 Sonnet, it was already sufficient for relatively straightforward NLP tasks like personalized copy generation. It was through solving these real problems that they truly understood how the system works and how to extend it to other teams.

"The reality is you can't spend a year building a perfect system architecture," Arman concluded. "You have to piece together vertical solutions first, then stitch them together." This is the core methodology behind how Ramp built GTM orchestration from the ground up — bottom-up, vertical-first, horizontal compounding.

Key Takeaways