How AI Agents Let GTM Teams Scale — Justin Joyce, Cloudflare

Every week, operations teams rebuild analyses in Excel or Sheets. More projects mean more recurring work. Dashboards make information easier to distribute, but a standard view still leaves some teams waiting for answers to questions it does not cover. This is the practical problem behind Justin Joyce’s diagnosis that traditional go-to-market operations do not scale.

Joyce is Cloudflare’s principal sales operations and strategy manager, supporting lead-producing teams and the customer experience after a sale. After seven years working on machine learning, he returned to sales operations to combine business knowledge with prescriptive analysis: helping teams decide what to do next. His opening joke about the conference’s AGI pills gives way to a concrete concern—making the whole operation more efficient, from back-office analysis to customer conversations.

Customer-facing work adds two distinct gaps:

• Context gap: A representative moves from a prospect call to an existing-customer conversation and then to an adoption discussion. Each requires different information. The preparation is necessary; repeatedly gathering it between calls consumes time.
• Expert gap: An experienced representative and someone still ramping up may handle the same rejection, adoption problem, or customer satisfaction issue differently. Shared information must also help people assess the situation and choose a useful response.

These problems compound. An overloaded analytical team cannot answer every request, while representatives spend time assembling context and still lack the judgment embedded in an expert’s approach. Improving only the dashboard would leave much of that chain intact.

The response has three pillars, each addressing a different moment in the work:

• Scale analysis: Help operations answer data questions and build applications using business context.
• Scale insight: Deliver recurring performance stories across management levels, with customer-level insight as a further ambition.
• Provide self-service: Give representatives data and expert guidance when a particular customer situation arises.

The first pillar changes what operations can spend its time on. Joyce frames the ambition as reducing two hours of work to five minutes. After building skills in January, he could ask questions directly of the data and receive answers while doing other tasks. Faster answers create room for the strategy part of sales operations: deciding what the business should do with the information.

Role-specific skill files connect business context to the underlying data. A technical user may already know SQL and data engineering; someone closer to sales may understand the business question without knowing how to write its query. The skill files carry the logic those users would otherwise have to obtain from a data specialist.

Opportunity changes provide a concrete example. The business wants to examine changes in close dates or opportunity amounts. Previously, a user who did not know SQL would send that request to someone who understood the data and could write a complex query. Through testing, the team added these familiar question types and their relevant logic to the skills. The user can then ask the question directly and receive an answer rather than wait in the specialist’s queue. The observable change is who can obtain the analysis; the enabling step is packaging the business-to-data knowledge beforehand.

Joyce estimates that the skills answer 80% or more of these questions, with the remaining 20% potentially involving more complex strategic analysis. That estimate concerns coverage of familiar business requests, rather than an accuracy score or a claim that every strategic question has become routine.

The same knowledge also supports application building. Business semantics and information about the data columns give the team reusable context for creating tools. Joyce reports that his team built multiple applications this way, reducing dependence on an IT queue. One investment in explaining the data can therefore support direct questions, new applications, and the customer-facing skills used later in Cloudflare OS.

The second pillar produces a weekly summary of business performance: progress toward goals, trends, standouts, and areas to watch. The presentation’s example uses synthetic data. The intended experience is a briefing people can receive and act on during their day, with reports and dashboards available when they want to investigate further. 8:57

Pushing the summary addresses uneven adoption of key performance indicators. Some people love dashboards; others will rarely open them. A common performance story can reach both groups, while the dashboard remains useful for drilling into details. Generating an answer and getting someone to encounter it are separate jobs.

Consistent reporting starts before the language model sees the data. The team organizes inputs by time, business slices such as manager and theater, and the metric being examined. It engineers the filtering rules and the aggregations the business wants upfront. This prevents each reporting run from having to reconstruct those same analytical choices.

The preparation uses both wide and long data layouts. Wide data spreads values across columns; long data organizes repeated observations into rows. Cloudflare’s trend information uses the long form, followed by preprocessing to highlight trends. The important decision is to give the agents a consistent business view suited to the question, with recurring calculations already prepared.

Joyce separately estimates that these prepared performance views handle 80% or more of requests because so many questions ask how teams are doing. Standardization makes common requests easier to serve, but it also selects the slices and calculations available in the summary. Deeper investigations can still go down to raw data through self-service.

How does prepared data become a weekly message, and where do its checks happen? The reporting workflow runs three agents in sequence. Data retrieval and the first-pass draft involve calls to the team’s MCP connections. A reviewer then checks the factual basis of the draft. Finally, a tone agent uses a multi-shot prompt—examples of the desired message—to give risks and opportunities equal weight. 11:05

The sequence below makes the division visible: data preparation determines the business view, the drafter turns it into prose, the reviewer checks its factual basis, and the tone agent shapes the final emphasis. Factual review and editorial balance have their own stages, rather than depending entirely on the first draft.

Every run exposes the inputs and responses of individual LLM calls. The team inspected every run for two to three months to find what went wrong before settling on this architecture. That visibility makes failures easier to locate: a questionable result can be traced back through the calls that produced it. The workflow provides repeated checks and an operational basis for confidence, without establishing a numerical error rate or guaranteeing that review catches every mistake. Extending the summaries to more teams and individual customers remains a next step.

Cloudflare OS is the internal agentic workspace that supplies the third pillar. Joyce describes each user getting compute and a persistent environment using Cloudflare Workers and Durable Objects. Representatives can enter the workspace when they need information for a customer task, rather than wait for the next scheduled summary. 12:03

The workspace combines expert skills, an MCP connection, and AI Gateway. Conversations retrieve data and apply curated guidance to a job. Access to customer information addresses the context gap; guidance about how to use that information addresses the expert gap. Both are needed to support a useful customer conversation.

The tasks span several kinds of preparation:

• Business and account planning: Forecast briefs, account plans, and general data queries.
• Customer-call artifacts: QBR decks and purchase decks describing what an onboarding customer bought.
• Renewal preparation: Examining customer usage to consider an upsell or help the customer adopt more of the product.

In the daily-work example, a user asks a question and the agent begins pulling information through MCP to assemble a prescriptive plan. Another example generates a custom slide deck for a customer call. These outputs put retrieved information into a form the representative can use—a plan or deck—rather than leaving the user to assemble the artifact from separate answers.

Self-service depends on a maintained skill repository. Skills are submitted through a central alias and curated by go-to-market and operations teams. Review helps prevent uncontrolled proliferation and keeps expert knowledge available for different customer situations. Users choose when to ask for help, while the organization reviews the guidance shaping that help.

The three pillars serve complementary needs. Self-service supplies data and expertise for the situation at hand. Pushed insights establish standardized performance context. Greater analytical capacity lets operations answer questions and build applications that would otherwise remain unmet needs. The cost of an overloaded operations team reaches beyond its own backlog: customer-facing teams lose help they could have used.

Skill curation is the shared foundation. Business knowledge guides analysis and application building, while customer-task expertise guides work inside Cloudflare OS. The intended result is more predictable, consistent execution across users; curated skills do not by themselves guarantee deterministic model behavior.

Internal tools also need a product feedback loop. Teams must find out whether the outputs are useful, where people encounter problems, and what would make the work more efficient. Layering the delivery modes respects how users already work: some prefer asking operations a question, some benefit from a pushed briefing, and some want to retrieve information themselves.

Joyce reports 2× efficiency from the combined approach, alongside better access to information needed for the job. The talk does not define the efficiency measure or its baseline, so the figure is an operational result he reports rather than a reproducible benchmark.

The next integration goal removes another retrieval step. Instead of requiring a representative to pull a QBR deck or renewal-preparation artifact, the system could set up the meeting and attach the material there. The self-service portal would remain available for ad hoc needs. Capturing meeting notes across calls is another proposed extension. Both require additional system integration and security setup. 17:08

Quoting, approvals, and CRM updates are harder problems. Cloudflare uses Salesforce, and the team is building the connections that would let agentic systems update it. Joyce expects multi-agent workflows resembling the reporting pipeline to help check that the work is done correctly. This is work in progress: the talk does not establish a completed Salesforce write workflow or explain its approval controls.

That shift also changes the organizational problem. Joyce describes agent adoption as a Cambrian stage: excitement produces an explosion of skills and attempts to solve almost anything with AI. As those experiments become integrated workflows, each team needs a deliberate approach to using them so that the systems and their sources of truth stay aligned. The closing challenge is keeping shared business meaning intact as agents become involved in more of the work.