# How to build self-improving GTM workflows

> Build GTM workflows that improve on their own: the five-step flywheel, a discovery example with triggered skills and evaluator prompts, automatic vs. human-reviewed loops, and why it needs shared memory.

Updated October 28, 2026

**The short answer.** A self-improving GTM workflow is a go-to-market motion that runs as a loop: reps' AI agents execute it from a shared skill that runs on its own at the moment the work is needed, every call and email is captured, an evaluator analyzes how the motion is run across the team and what leads to good outcomes, the skill is updated with what works, and the new version goes back to every rep and agent. Analysis is what turns the loop. Without continuous analysis of real customer conversations there is no flywheel, only a document. Day AI runs this loop for the whole team: skills that run on their own for every rep, one shared customer memory to analyze, and versioned skill updates pushed to every agent, as the CRM or on top of Salesforce or HubSpot.

You probably already have the first piece for each motion, the repeatable activities like discovery, outbound, demos and renewals: a discovery guide, a messaging framework or a pilot playbook. That was the right start. This guide adds the rest, using discovery as the worked example.

---

## Why playbooks go stale

The pace of change in go-to-market is faster than it has ever been. Buyers research with AI assistants before they talk to a rep, competitors can rework their positioning in weeks, and new products, segments and pricing ship constantly. A motion that worked last quarter can be out of date this quarter.

A playbook describes how a motion should be run on the day it was written. After that, what works changes and the playbook doesn't hear about it, the questions that move deals stay in your best reps' calls, and nobody can tell whether the guidance is followed.

The expertise to keep a playbook current rarely sits with one team. It is spread across subject matter experts, sales managers, sales leaders and enablement, and each of them can only listen to a few calls by hand, so the guide gets rewritten once or twice a year, far slower than the market moves. A self-improving workflow reviews every call continuously, turns what it finds into a proposed change to the skill within days, and lets those experts spend their time judging the change instead of hunting for it.

## The GTM flywheel: five steps

```
EXECUTE → CAPTURE → ANALYZE → IMPROVE → DISTRIBUTE → repeat
```

*Analysis is the engine. Customer memory is the fuel.*

| Step | What happens | What it needs |
|---|---|---|
| **1. Execute** | Agents run the motion from the current skill, triggered ahead of each call and as emails arrive | A skill that runs on its own, not a document people read or a command reps have to remember |
| **2. Capture** | Every call, email and meeting lands in one store | Automatic capture across every rep, with no manual logging |
| **3. Analyze** | An evaluator reviews how the motion was run against outcomes | Conversations connected to the accounts and deals they belong to |
| **4. Improve** | The skill is updated, automatically or after human review | Versioned edits you can see and roll back |
| **5. Distribute** | The new version reaches every rep and agent | One centrally owned skill, deployed to everyone |

---

## Worked example: discovery

Discovery is the easiest motion to start with. Every rep runs discovery calls, the calls are recorded, and you can compare how different reps approach them with what happened to the deal afterward.

### Step 1: Write the v1 discovery skill

Start from the guide you already have. Keep the substance in a Discovery Guide page: objectives, your qualification framework (MEDDPICC, BANT or your own), a question bank grouped by pain, impact, process, decision process, timeline and champion, red flags, and what a strong first call looks like. The skill tells the agent how to use it:

```markdown
Prepare me for a first discovery call.

1. Read the Discovery Guide page. Follow it over anything
   else you know about discovery.
2. Research the account and every attendee: role, tenure,
   prior conversations with us, open deals, and anything
   they've said about their priorities.
3. List which MEDDPICC elements we already know and which
   this call must uncover.
4. Pick six to eight questions from the guide's question
   bank that target the gaps. Lead with pain and impact.
   Include at least one decision-process question.
5. Flag any red flags from the guide that already apply.
6. After the call, draft the summary, the next steps, and
   the deal fields to update.
```

### Step 2: Trigger the skill so it runs in the moment

A skill a rep has to remember to kick off is a playbook with extra steps. On days with back-to-back calls, nobody stops to run a prep command, and those are the calls that need prep most. The skill has to run on its own, at the moment the work is needed, and put the output where the rep already is:

| Moment | Trigger | What the skill does for the rep |
|---|---|---|
| Ahead of the call | A weekday-morning schedule | Preps every first call on the day's calendar and sends the brief by email or Slack |
| Shortly after the call | The recorded call's notes are ready | Drafts the follow-up and deal updates, and checks which framework elements the call covered |
| When the prospect replies | A new email arrives | Updates the open questions and suggests the next step |
| When the deal moves | The deal changes stage | Prepares the plays for the next stage |

This matters for the loop too. A skill that runs on every call, for every rep, is used the same way across the team, so the evaluator compares like with like.

### Step 3: Tell the evaluator what to review, and when

The evaluator answers one question across many calls: what are our best reps doing differently? Point it at specific comparisons and moments, not "look at everything once a month":

- **Compare the top reps with the bottom reps.** Review calls from the top 20% and bottom 20% by conversion side by side. What top reps do shows what to add. What bottom reps do, and top reps don't, shows what isn't working.
- **Review every deal as soon as it closes.** Trigger a review the moment a deal moves to closed won or closed lost, while the outcome is fresh. Losses teach as much as wins.
- **Review deals that stall,** and ask what discovery missed.
- **Review after every change** to the skill, comparing calls before and after.

Across all of them, look at the questions asked, which framework elements get covered or missed, how reps follow up on pain, how winners handle objections, and where behavior departs from the skill. The closed-deal review can be its own skill, triggered by the stage change:

```markdown
A deal just moved to closed won or closed lost.

Read every discovery call on this deal. Note which Discovery
Guide questions were asked, which framework elements were
covered or missed, and the moments that, in hindsight,
decided the outcome.

Add a dated entry to the Discovery Findings page, marked won
or lost, with links to the calls.
```

### Step 4: Write the evaluator prompt

A weekly evaluator reads those findings and runs the comparison:

```markdown
Review all first discovery calls from the last 30 days.

Compare the questions asked by the top 20% of reps by
stage-2 conversion against the bottom 20%. Also look at
deals that closed in under 45 days, and read this week's
entries on the Discovery Findings page.

Identify:
- the 5 questions or approaches most associated with
  progression
- the 3 approaches most common in the bottom 20% and in lost
  deals
- the 3 most common gaps relative to our Discovery Skill and
  Discovery Guide

Propose specific edits to the skill and the guide: the exact
text to add, change or remove. Cite two or three example
calls for each recommendation.
```

The output is a proposed change to the skill with the evidence behind it, not a report someone has to translate into action. Applied, it becomes the next version: questions added, weak ones removed, segment variants where mid-market and enterprise calls succeed differently. The new version goes out to every rep's agent, and the next round of calls runs from it.

---

## Two ways to run the loop

| | Automatic | Human in the loop |
|---|---|---|
| **How it works** | The evaluator applies agreed categories of change to the skill itself | The evaluator proposes changes, and an owner accepts, edits or rejects each one |
| **Optimizes for** | Speed | Judgment |
| **Best for** | A well-defined motion with clear outcome signals | Regulated industries, teams mid-repositioning, orgs where enablement owns the playbook |

Both run on the same analysis. The human in the loop is whoever knows the motion best, often more than one person: a subject matter expert, a sales manager, a sales leader or an enablement owner. They can add what the data can't show yet, such as a positioning change that hasn't reached the calls, and their job changes from writing a playbook once a year to curating a living one every week. Many teams start with human review and automate the kinds of change they come to trust.

---

## Why the loop needs a shared customer memory

The flywheel depends on evaluating how a motion is run across the whole team, every day. That takes five things:

1. **Every interaction captured automatically.** Calls, emails, meetings and Slack threads from every rep, with no manual logging. If half the calls are missing, the analysis is wrong.
2. **Shared memory, not one silo per rep.** You can't compare how two reps run discovery if each rep's calls live in their own tool.
3. **Permissions built in.** The analysis has to be shared without exposing what people shouldn't see.
4. **A structure built for AI at scale.** Evaluating hundreds of calls against stage changes and win or loss needs conversations connected to the accounts, people and deals they involve.
5. **An agent control plane to act on findings,** the layer that creates, updates and deploys skills across the team. An insight that can't change the skill is a report.

Call recorders have transcripts but weak links to deal outcomes and no control over the skills agents run. Single-rep AI assistants have no shared memory to compare across reps. CRMs have outcomes but not the conversations behind them. Single-player AI makes individual reps faster. Multiplayer memory makes the whole team better.

---

## Running the loop on Day AI

Day AI provides the context graph and agent control plane to quickly and securely upgrade your company brain. It runs as the CRM, or on top of Salesforce or HubSpot. Each step of the flywheel maps to a part of the product.

### Execute: skills that run on their own

Each person has their own agent with skills. A skill runs on a schedule or the moment an event happens, does the work as the person it belongs to, and delivers the result to their email, Slack DM or a Slack channel, with no workflow tool to wire up.

Skills run daily, on weekdays or weekly, or when something happens: a recorded meeting's notes are ready, an email arrives, or a deal is created or changes stage. A skill can attach Day AI pages as reference, so the discovery skill reads the Discovery Guide live.

### Capture: the customer memory

Day AI builds it from meetings recorded by its notetaker, Gong and Granola calls imported with transcripts, each person's Gmail and Google Calendar, and Slack channels the Day AI app joins. Each person chooses what they share, and every agent sees only what the person it works for can see. The [guide to building a context graph](/guides/build-a-context-graph) explains how.

### Analyze: evaluators on a schedule and on events

The evaluator is a skill on the agent of someone who owns the motion and can see the team's shared calls. It searches transcripts, filters deals by stage and cites the calls behind each finding. Run the comparison weekly, and run the closed-deal review on the **Opportunity stage changed** event, narrowed to your closed won and closed lost stages.

### Improve: versioned skills that edit from replies

Every skill keeps an Edit History with each change, who made it and the full text, and the agent can restore an earlier version. Replying to a skill's output, in chat or to its email, edits the skill in the same turn. That gives you both modes: the evaluator on an admin's agent applies its edits directly, or it sends proposed edits with cited calls and the owner replies "apply 1 and 3, skip 2". When a rep who isn't an admin gives feedback on a managed skill, the agent tells them what an admin would need to change.

### Distribute: managed skills and workspace instructions

Make the discovery skill a managed skill: only admins edit it, every agent it's deployed to gets a synced read-only copy, and each update reaches everyone, with no drift. Deploy variants only where they belong, such as an enterprise version for enterprise AEs. Then add one line to the workspace's **Instructions** settings, which every agent follows, such as "for discovery, call prep or qualification, follow the Discovery Skill and the Discovery Guide", so reps get the current best practice without knowing the skill exists.

---

## Advanced: personalized skills with Claude Code and GTM Brain

An evaluator that compares each rep with the team finds individual gaps: one rep rarely uncovers the decision process, another doesn't quantify impact. The next loop acts on that with team variants (enterprise versus mid-market) and short coaching skills on individual reps' agents, alongside the shared managed skill.

Doing that by hand for every rep isn't realistic. From Claude Code it is. Day AI's MCP server, at `https://day.ai/api/mcp`, lets Claude Code search the team's meetings and deals, read each skill's run and edit history, and create and deploy skills on teammates' agents, with Admin or Owner access. [GTM Brain](https://github.com/day-ai/gtm-brain), Day AI's open-source Claude Code harness, packages this: it audits how well each agent's skills are working and deploys role-specific skills, previewing every change first. See [how to give Claude Code memory of every customer conversation](/guides/give-claude-code-customer-memory) to connect it.

---

## Beyond discovery: other motions

The same loop works for any motion with a skill, captured conversations and an outcome you can measure.

| Motion | What the evaluator looks at | Outcome signal |
|---|---|---|
| **Messaging and outbound email** | Which messages, angles and personas get replies and meetings | Reply rate, meetings booked, pipeline created |
| **Pilots and POCs** | Pilot designs that convert versus stall | Pilot-to-close rate, time to decision |
| **Scoping** | Patterns that lead to a clean close versus rework | Deal slippage, discounting, redlines |
| **Demos** | Which demo flows advance deals | Next-step rate, stakeholders added |
| **Renewals and expansion** | Which plays drive expansion | Net revenue retention, expansion pipeline |

After discovery, messaging is the easiest loop to run, because emails get fast, measurable feedback: replies and meetings booked. To check how the system around your agents measures up, see [how to grade your company's AI agent setup](/guides/grade-your-ai-agent-setup).

## Frequently asked questions

### What is a self-improving GTM workflow?

A self-improving GTM workflow is a sales or go-to-market motion, such as discovery, outbound messaging or pilots, whose instructions get updated from evidence of what works. It runs as a loop with five steps: AI agents execute the motion from a shared skill that runs automatically at the right moment, every call and email is captured, an evaluator analyzes how the motion is run across the team against outcomes, the skill is updated with what works, and the new version is distributed to every rep and agent. Analysis is the step that makes it improve. Without it, the skill is a static playbook.

### Why do GTM playbooks need to update continuously?

Because the market changes faster than an annual rewrite. Buyers research with AI assistants before they talk to a rep, competitors can change their positioning in weeks, and new products, segments and pricing ship constantly, so a discovery guide or messaging framework written last quarter may already be wrong. A self-improving workflow reviews real calls every week and as each deal closes, then updates the skill reps and their agents run, so the motion keeps pace with the market.

### What is a GTM flywheel?

In this guide, a GTM flywheel is the loop of execute, capture, analyze, improve and distribute that keeps a go-to-market motion current. Each turn adds evidence from real customer conversations, so the skill reps and agents follow gets better the more the team uses it. It differs from a marketing flywheel diagram in that each step is a concrete system: a skill, a store of conversations, an evaluator, an edit history and a way to deploy the change.

### How do you scale what your best sales reps do in discovery?

Find out what they do differently from evidence, not interviews. Capture every discovery call across the team, then have an evaluator compare the questions your top reps ask with what your bottom reps ask, and review every deal the moment it closes won or lost. Turn the findings into edits to one shared discovery skill, cite example calls for each edit, and deploy the skill so every rep's AI agent uses it for call prep and follow-up. Repeat weekly. In Day AI, the evaluator is a skill that runs on a schedule and whenever a deal closes, and the discovery skill is a managed skill that updates on every rep's agent at once.

### Should AI sales skills run automatically or on demand?

Automatically, for anything that happens on every deal. A skill a rep has to remember to start gets skipped on the busiest days, which are the days it's needed most. Trigger it instead: a weekday-morning schedule that preps every call on the day's calendar, an event that drafts the follow-up once a recorded call's notes are ready, another that suggests a next step when a prospect's email arrives, and one that reviews a deal when it closes. Keep on-demand runs for one-off requests. Day AI skills run this way out of the box: on a schedule or when a recorded meeting's notes are ready, an email arrives or a deal changes, with the result sent to the rep's email or Slack.

### Why do AI sales agents need a shared customer memory?

Because an agent can only learn from what it can see. To compare how different reps run a motion and which approaches lead to good outcomes, the evaluator needs every rep's calls and emails in one place, connected to the accounts and deals they belong to, with each person's permissions respected. An assistant that only sees one rep's data can make that rep faster, but it can't find what the best reps do differently or improve the team. Day AI gives every agent on the team one shared customer memory, and each agent sees only what the person it works for can see.

### Can Day AI run a self-improving discovery workflow?

Yes. A discovery skill on each rep's agent preps every call before it happens and drafts the follow-up after it, an evaluator skill compares top and bottom reps' calls and reviews every deal as it closes, and the proposed edits go to the skill's owner or apply directly. Every change is versioned with its author, and a managed skill pushes the new version to every rep's agent at once.

### What is Day AI?

Day AI is the customer memory and agent platform for go-to-market teams. Even the best CRM only holds a fraction of what actually happened with your customers. Day AI is what comes after CRM. It builds a self-updating customer record from every meeting, email, and call, and runs governed agents that create finished work on top of it, with every fact and every action traced to source conversations. It does everything teams use a CRM for, without the data entry, and does what a CRM never could. Agents prospect, prep every meeting, draft follow-ups, keep the pipeline clean, and much more, giving every rep added selling capacity that used to require hiring additional people. It runs in place of Salesforce or HubSpot or as a layer on top of them.

Canonical: https://day.ai/guides/self-improving-gtm-workflows