The Building Blocks of GTM Orchestration — Arman Vaziri, Ramp
Ramp’s GTM agents share a customer-data layer, durable execution, tools, and skills. The reusable pattern is to automate one narrow workflow, then extend the same substrate across teams.
Ramp built an internal customer data platform combining CRM, product, enrichment, web, buying-signal, and interaction data. Agent work runs as **durable Temporal threads**, with each model or tool call represented as an activity that can resume after failure.
For coding-agent systems, centralize entity resolution and reusable context before multiplying workflows. Expose the same **tools and skills** to background agents and employees through **GTM MCP**, and begin with one specific automation rather than a comprehensive platform.
Ramp built an internal customer data platform combining CRM, product, enrichment, web, buying-signal, and interaction data. Agent work runs as **durable Temporal threads**, with each model or tool call represented as an activity that can resume after failure. For coding-agent systems, centralize entity resolution and reusable context before multiplying workflows. Expose the same **tools and skills** to background agents and employees through **GTM MCP**, and begin with one specific automation rather than a comprehensive platform. This architecture reflects Ramp’s scale and data estate. The speaker’s advice for smaller teams is to assemble narrow vertical solutions incrementally; the talk does not quantify their reliability, cost, or business impact.
This identifies shared entity resolution, reusable context, and durable execution as prerequisites for multiplying GTM workflows. Temporal activities make model and tool calls recoverable, while a common MCP surface lets employees and background agents reuse the same capabilities. It reinforces incremental vertical adoption and narrows the platform claim because reliability, cost, and business impact are not quantified.