Talk by Arman Vaziri (leads product and sales-led growth engineering at Ramp) on go-to-market orchestration. Using a running example of offering golf balls to golfers at East Coast construction companies, he describes turning a single intent statement into targeted audiences, outbound sequences, paid creative, landing pages, and in-app nudges. He identifies bottlenecks beyond ideation: data, busy work, and coordination across product, data, and go-to-market teams. Technical foundations covered include an internal customer data platform (CRM, product, enrichment and buying signals, interaction data, real-time events on Kafka, a Postgres store maintaining referential integrity across systems, with unstructured data embedded for search), a strategy of solving for one team then scaling sideways, pre-meeting briefs for account managers, durable Temporal threads where each tool or model call is a resumable activity, a skill library letting users define their own brief formats to drive adoption, and advice for smaller teams to build narrow automations first. # Observation Document: "The Building Blocks of GTM Orchestration — Arman Vaziri, Ramp" ## Speaker Self-Identification (Explicit) - The speaker introduces himself as **Arman** (title metadata: Arman Vaziri) and states his role directly: > "my name's Armon. I lead our product and sales-led growth engineering teams at Ramp." - He positions the talk as a practitioner's walkthrough: > "today I'm going to talk to you about, uh, the building blocks of go-to-market orchestration." ## Observed Intended Audience - The talk is addressed to an **in-person or streamed audience** at what appears to be a multi-speaker event: "I really appreciate everybody showing up," a reference to a moderator ("as Madhu mentioned"), and "We have probably time for one question" with audience Q&A. - Content is aimed at a **technical GTM/engineering audience**: discussion of Kafka topics, Postgres, Temporal, DBT, Snowflake, reverse ETL, embeddings, vector search, and MCP assumes listener familiarity with these systems. - The closing question indicates the audience includes people at **smaller or early-stage companies** considering similar builds ("how would you approach building something like this for a smaller company..."). ## Claimed Scope and Self-Description of Work - **Claimed internal scope**: The speaker describes Ramp's internal GTM engineering program, including: - An **internal customer data platform (CDP)**: "we effectively went and built um an internal customer data platform at Ramp." - An **internal application** called "Ramp Revenue." - An internal **MCP layer** ("our GT MCP") exposing agent tools to employees: "employees have access to the same tools and skills that are being used for the background agents." - **Claimed history and team context**: "like 3 years ago, there was two of us and we were building like automated outbound." - **Claimed outcomes** (creator claims, not independently verifiable here): - Adoption and employee-built automations: "they're building a ton of them." - Campaign efficacy anecdote: the Pro V1 golf-ball offer "works really well." ## Demonstrated Presentation Patterns - **Concrete-example-driven structure**: Opens with a vivid scenario (golfers at East Coast construction companies offered Pro V1 golf balls) and returns to it as a closing throughline. - **Problem → architecture → extension narrative**: frames challenges (messy data, rep busywork, coordination cost), then presents technical building blocks (durable execution on Temporal, embedding pipelines into "Turbo Buffer," skill libraries, nightly background agents for pre-meeting briefs). - **Honest hedging language**: The speaker qualifies claims conversationally — "probably more than just this one sentence," "a sneaky hard problem" — rather than presenting polished marketing language. - **Practical, incrementalist advice** in Q&A: "find the very specific use cases that you can build automation around... you can't spend like a year going and building like some really complicated system architecture." ## Notes on Evidence Boundaries - No curated metadata was supplied beyond the title; all identity evidence comes from the transcript itself. - Statements about Ramp's internal systems, scale ("Ramp's addressable market is pretty much like the entire US"), and results are **creator claims about his company**, presented from his perspective; the material demonstrates only that the speaker describes these systems, not that they function as described. # Delivery Observations — Arman Vaziri, "The Building Blocks of GTM Orchestration" ## Overall Tone and Register - **Conversational, informal engineering-talk style** throughout, marked by frequent filler and hedges: - "Um", "uh", "like", "kind of", "you know" appear constantly. - > "So, like really specifically, uh I'm a golfer." - **Candid, slightly self-deprecating humor**, e.g.: > "offering Pro V1s to golfers, which is actually like uh it works really well." ## Vocabulary and Register Mixing - Blends **technical infrastructure vocabulary** (Kafka, Postgres, DBT, Snowflake, reverse ETL, Temporal, embeddings, vector search) with **go-to-market/sales vocabulary** (playbooks, outbound, SDRs, AMs, AEs, QBR, enablement). - Uses casual terms for internal tooling: > "we set up a what we call like our GT MCP" - Defines acronyms for the audience when first used: > "AMs are like count account account managers. Uh they kind of manage the customer relationships" ## Recurring Phrases and Verbal Tics - **"like"** as an all-purpose connector — one of the most frequent words in the transcript. - **"go and"** as a habitual verb phrase: "go and pull an audience", "go and convince a bunch of people", "go and productionize this", "we can go and execute". - **"right?"** as a recurring check-in tag: > "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?" (pattern appears throughout: "the bottleneck is kind of like everything after that, right?") - **"kind of"** as a hedge: "kind of noticed", "kind of like fuzzy match", "kind of automatically federated". ## Teaching Habits and Structure - **Opens with a framing question**, then answers it: > "to kick it off, like, what do I mean by go-to-market orchestration? Effectively, like, what we're building towards is..." - **Uses a running concrete example** (the golf/Pro V1 scenario) introduced early and explicitly returned to near the end: > "So now you're probably wondering uh what about that golf example that I had mentioned at the beginning?" - **Problem → approach pattern**: lists challenges first ("the necessary data for this was just messy", "reps were just buried in busywork", "coordination and distribution are expensive"), then presents solutions in the same order. - **Anticipates audience objections**: > "if you're looking at this and you're like, that looks like a CDP.' Uh yeah, you're you're right." - **Cites prior talks** to stitch continuity: "as was previously mentioned", "as mentioned in the previous talk". - **Layered abstraction with "broadly → specifically"**: "Really broadly, uh go-to-market agents are complicated" followed by "to just start to get a little technical here". ## Communication Patterns - **Long, run-on sentences** stacking multiple clauses with "and"/"as well as", especially in technical passages (e.g., the CDP architecture passage). - **Emphasis through repetition**: > "back-to-back-to-back-to-back meetings" > "pre-compute, pre-process, pre-ingest" > "ship faster, ship safer" - **Direct advice in Q&A**, concise relative to the talk, with a concrete origin story: > "like 3 years ago, there was two of us and we were building like automated outbound" > "you can't spend like a year going and building like some really complicated system architecture that like is perfect." ## Stable Patterns vs. Isolated Moments - **Stable (high repetition)**: "like"/"um"/"uh" fillers, "go and [verb]" construction, "right?" tag, problem-then-solution structure, informal register in technical content. - **Isolated / lower confidence**: The self-deprecating humor ("it works really well") and the explicit callback structure to the golf example each appear once or twice — observable but not clearly habitual. Filler density makes exact frequency claims hard without audio; this analysis is transcript-only. ## Uncertainty Notes - Timestamps in the transcript are coarse segment markers, not precise; no timing-based observations are claimed. - Delivery qualities like pace, pauses, and audience laughter (beyond the noted applause) are not reliably observable from the transcript alone. # Observation Record: The Building Blocks of GTM Orchestration — Arman Vaziri, Ramp ## Speaker - **Arman ("Armon") Vaziri**, leads product and sales-led growth engineering teams at Ramp. (Curated metadata identifies him as Arman Vaziri; transcript self-identification is "Armon".) ## Core Thesis - **GTM orchestration** = the ability to *describe a motion* (playbooks, experiments, evergreen campaigns) and have it automatically distributed across execution channels (outbound, ads, web, etc.). - Motivation: ideas are abundant across product/data/engineering/GTM teams; **the bottleneck is everything after the idea** — pulling audiences, convincing people to follow playbooks, enablement. Goal: **reduce coordination cost**. ## Illustrative Example: Golfers at East Coast Construction Companies - Stated intent: offer golfers at East Coast construction companies an incentive (e.g., **Pro V1 golf balls**) to try Ramp / talk to sales. - Desired output from intent alone: audience creation, outbound sequences with generated copy, paid ad and web creative, in-app notifications. - Later claim: the Pro V1 experiment "actually... works really well." ## Identified Fundamental Challenges (from a few years ago) - **Messy, inconsistent data** across systems; no shared source of truth → coordinated cross-channel action effectively impossible. - **Reps buried in busywork** — back-to-back meetings; operational burden between sales activities was high, limiting experimentation/creativity. - **Coordination and distribution are expensive** — writing proposals/enablement and convincing people is hard on any pace faster than "months." ## Solution Approach (Stated Sequence) 1. **Ingestion/consistency/data quality** (a recurring roadmap item). 2. **Vertical efficiency levers** — save time in operations/execution; improve conversion via personalized, scaled strategies. 3. **Horizontal extension** — common workflows (outbound, meetings) let patterns built for one team be mirrored to others. 4. **Current stage: distribution/coordination** — multi-channel execution from described intent. ## Technical Building Blocks ### Internal Customer Data Platform (CDP) - Ramp built an internal CDP; speaker acknowledges "if you're looking at this and you're like, 'that looks like a CDP'... you're right." - Ingests: CRM data, product data, enrichment data, web data, buying signals (internal propensity models, e.g., attach to procurement/treasury; external signals like funding announcements), interaction data (emails, meetings, calls, page views). - **Postgres backing store** for transactional guarantees and referential integrity; attribution to right level of detail; capture of provenance metadata. - Real-time events (e.g., emails) piped via **Kafka**. - **Embeddings** of unstructured sales data (call transcripts, emails, notes) for search. - Online batch jobs calling enrichment APIs — justified by Ramp's addressable market being "pretty much the entire US" and expanding internationally. - Offline pipeline: **DBT, Snowflake, reverse ETL** back into the same layer. ### Vertical-First Strategy - Approach: "solve for one team first, then scale horizontally." - Example: **pre-meeting briefs for AMs** (account managers) — context including product usage, account vitals, agenda, customer's open tickets/emails; addresses AMs' back-to-back meeting burden. - Technical notes: - Meeting-event hydration; mapping attendee emails/titles to accounts — described as "a sneaky hard problem" because the same email can work on behalf of multiple businesses (fuzzy matching). - **Durable execution via Temporal** — durable threads; each tool/model call an activity; resumable after worker failure; config-scoped tool calls per agent; human-in-the-loop pause/resume. - **Retrieval**: enablement materials, product knowledge, playbooks chunked and embedded into **Turbo Buffer**; hybrid vector/attribute/keyword search scoped to, e.g., an account, avoiding pulling the full raw corpus into agent context (efficiency/cost rationale). - **Skill library** for user-customizable agent output formats/information — described as very valuable for adoption. - Nightly fan-out of per-account background agents using tools: Postgres CDP, vector DB, system-level meeting-prep skills, custom user instructions. ### Extension & Federation - Next steps: post-meeting follow-ups, automatic CRM updates (pre-fill expansion opportunities from transcripts, rep thumbs-up, then execute). - Horizontal extension (e.g., to AEs): mainly new skills, data integrations, ingestion — AEs need more third-party data vs. product data. - **GT MCP**: employees access the same tools/skills as background agents; automatically federated so employees build their own agents/automations. - Compounding loop: employee MCP usage reveals problems and prompts/skills, which Ramp productionizes and distributes; users contribute "even applications that they're vibe coding." ### Orchestration Layer (the golf example revisited) - Vertical builds are the **foundation** for multi-team, multi-channel distribution; playbooks/experiments federate through background agents producing operational artifacts. - Via internal app **Ramp Revenue**: SDR audiences, personalized sequences, web landing pages, ad creative — all from described intent, with **channel owners reviewing and signing off**. - Goals: ship faster/safer, scale teams, consistent audience targeting, agents holding context across campaign options, **multi-armed bandit** explore/exploit balance, and **guardrails** for compliance, rules of engagement, context awareness (avoiding repetition). ## Q&A: Advice for Smaller Companies - Question (unidentified audience member): how to build this at a smaller/just-starting company? - Vaziri's answer: - Find **specific use cases** and solve real problems first; three years ago his team of two built automated outbound with **GPT 3.5**, personalized copy, and data pulled from various sources. - Solving real problems builds understanding of extensibility. - Explicit caution: "you can't spend like a year going and building some really complicated system architecture that... is perfect" — instead, **piece together vertical solutions and stick them together**. ## Qualifications & Unresolved Points - Intent description is "probably more than just this one sentence" — a qualification on the golf example. - Data quality is "on the road map every quarter" — ongoing, not solved. - Attribution/fuzzy matching described as persistently hard ("sneaky hard problem"). - The Pro V1 campaign's efficacy is stated anecdotally ("it works really well") without supporting data offered. # Video Attribution Record ## Video Overview - **Title:** The Building Blocks of GTM Orchestration — Arman Vaziri, Ramp - **Format:** Conference/talk presentation with audience Q&A (applause and audience music cues in transcript) ## Speakers and Roles ### Primary Speaker - **Arman ("Armon") Vaziri** — **Presenter / Creator** - Self-identified: leads **product and sales-led growth engineering teams at Ramp** - Delivers the full talk on go-to-market orchestration building blocks ### Secondary / Referenced Speakers - **Madhu** — **Referenced introducer** (not a direct speaker; mentioned by Arman as having introduced him) - **Audience Q&A questioner** — **Unidentified guest/questioner** - Asks how to approach building similar systems at a smaller or early-stage company - Receives answer from Arman ## Provenance and Referenced Sources ### Technologies / Systems Cited (by Arman) - **Kafka** — real-time event streaming (emails piped onto topics) - **PostgreSQL** — transactional backing store for internal CDP - **DBT / Snowflake** — offline batch compute, warehouse, reverse ETL - **Temporal** — durable execution framework for agent threads - **Turbo Buffer** — embedding/vector storage for unstructured data - **GPT 3.5** — mentioned in Q&A re: early automated outbound copy generation - **Internal Ramp systems:** internal CDP, "Ramp Revenue" internal app, "GT MCP" (MCP tool window) ### Third-Party Claims - None attributed to external parties; all claims are first-person accounts of Ramp's internal engineering work. ### Promotional Segments - **No explicit promotional segments detected.** The talk is technical/architectural in nature; mention of Ramp's internal products (Ramp Revenue, GT MCP) is descriptive, not a flagged promotion. ## Availability and Uncertainty - **Comment availability:** Not indicated in the provided material. - **Curated metadata:** None supplied beyond title and transcript. - **Uncertainty:** Audience questioner is unnamed; "Madhu" appears only via reference, role inferred as host/introducer. \>\> Yeah, I really appreciate everybody showing up. Uh, as Madhu mentioned, my name's Armon. 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. 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? 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 busywork, 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. Um 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 road map every quarter. 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. 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 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 CDP." Uh yeah, you're you're right. 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 the right 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 pre-compute, pre-process, pre-ingest 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 reverse ETL back into the same layer. Uh next, more tactically, the way we tend to approach these problems is solve for one team first, then 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. 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 count account 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 what these meetings are, uh so we can pipe in meeting events, uh 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. And also, as mentioned in the previous talk, uh we've also built a system around durable 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-scoped 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 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 sort 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 Turbo Buffer, and allows you to kind of or allows agents to go and search like what do I care about? What am I trying to answer right 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 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 in Postgres I mentioned, the vector database, uh, meeting prep skills that we own at the system level, as well as like custom instructions that users are providing themselves. 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 pre-fill all the information needed to create that opportunity, get a thumbs up from my 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, we're 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 GT MCP, 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. 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 like wacky experiment ideas that we have uh like offering 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 will 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-armed 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, and 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. \>\> \[applause\] \>\> We have probably time for one question. Hey, there we go. \>\> Hey. \>\> \[clears throat\] \>\> 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? \>\> 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 3 years ago, there was two of us and we were building like automated outbound, right? So, like we're 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 and then stick them together. \>\> \[music\]