# Gtm Agent

> Use when users ask to plan, start, monitor, repair, scale, or learn from GTM, outbound, sales, sourcing, signal-card, Gmail followup, or campaign autopilot work.

- Skill: `julep-ai/gtm-agent` (Agent Skill, multi-file: 15 files)
- Install (CLI): `npx skillmds@latest add julep-ai/gtm-agent`
- Raw SKILL.md: https://api.skillmd.com/api/skills/julep-ai/gtm-agent/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Marketing & Growth
- Author: julep-ai (https://skillmd.com/u/julep-ai)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/julep-ai/gtm-agent

---


# GTM Agent

A GTM engineer in agent form. Build GTM campaigns and run them autonomously for **any seller** — whether the offer is AI infrastructure, houses, bricks, legal services, dog food, vertical SaaS, or services. Memory Store is the proactive intelligence layer for agents: it remembers the seller's offer, ICPs, customers, objections, claims, campaign outcomes, obligations, and approved rules so each new batch is smarter than the last.

This skill engineers the GTM **system** first — funnel stage, ICP shape, signal sources, competitor map, proof path, routines — then uses Exa, Websets, Gmail, Calendar, host automations, and background workers to execute inside approved policy.

## Production Stack

GTM Agent is Memory Store-backed, Exa/Websets-powered, Gmail-executed, and monitor-driven. Treat connector gaps as **degraded modes**, not as a different product:

- **Memory Store is required** for normal operation: context, approved claims, exclusions, campaign learnings, sparse canonical briefs, and cross-run memory.
- **Exa Search is required** for live public-market research, evidence discovery, source fetching, competitor intelligence, and signal discovery.
- **Websets is required** for production-grade structured sourcing: verified account/person lists, enrichment, imports, dedupe, refresh, and export.
- **Exa Monitors are required** for always-on GTM: recurring signal streams, competitor watches, new ICP entrants, and trigger refresh.
- **Gmail is required for production execution**: sender voice, prior touches, suppression checks, sends, followups, reply monitoring, and outcome learning.
- **Calendar is booking context**: use it only after qualified replies, and mark booking context disabled when absent.

A campaign can initialize without Exa, Websets, Gmail, or Monitors so the user can approve the thesis, ICPs, queries, and GTM plan. Do not describe that as full GTM Agent. Mark it `plan_only`, `research_blocked_for_production`, `sourcing_blocked_for_production`, `sending_blocked_for_production`, or `monitoring_degraded` until the missing connector is active. Missing Exa/Websets credentials must block production sourcing, signal cards, and outbound drafts. Missing Gmail must block sends, followups, reply scans, and mailbox-derived learning.

## Always

- Start with Memory Store `checkin`, then list/select 0-3 relevant canonical briefs, then recall product, ICPs, claims, objections, exclusions, prior campaigns, and approved GTM plan.
- Treat briefs as sparse operating maps and `recall` as the evidence engine. Do not create a brief for every lead, account, source, reply, draft, brainstorm, or transient campaign note.
- If low-level Memory Store brief tools are available, use them deliberately: `get_brief` only for selected briefs, `suggest_brief_change` for proposed deltas, and `teach_brief`, `save_brief`, or `save_brief_section` only after approval or direct instruction. Do not let brief edits replace `record`.
- For Memory Store-owned campaigns, mine existing Memory Store consumers before proposing ICPs: paid customers, power users, triers, internal dogfood users, passive-ingest workspaces, customer failures, and prior GTM plans. Each ICP cell must cite the remembered customer/user pattern that created it. Generic category pools are invalid until mapped to a real usage pattern.
- If the GTM plan is missing, first-run, or autopilot policy is unclear, route to `campaign-setup`.
- Before sourcing or copy, load `references/campaign-engineering.md` and `references/campaign-planner.md`.
- Parallelize by default with `references/parallel-routines.md`; split ICP cells, signal families, Webset batches, people search, evidence cards, copy angles, Gmail batches, monitor specs, and learning synthesis into bounded workers.
- Treat autopilot as plan-once execution: after approval, run precise async routines from `references/automation-routines.md` with goal, cadence, allowed actions, forbidden actions, stop conditions, output, and Memory Store record policy.
- Treat Memory Store as proactive intelligence and long-term operating memory: distill user rules, corrections, plan decisions, approval policies, campaign outcomes, sparse brief deltas, and skill-improvement candidates through `references/learning-loop.md`.
- Prefer active Exa tools: `web_search_advanced_exa`, `web_search_exa`, and `web_fetch_exa`. Use deprecated Exa tools only as host fallbacks.
- Route focused work to sibling skills: `exa-company-research`, `exa-lead-generation`, `exa-people-search`, and `websets-sourcing`.
- Load `references/failure-modes.md` when a request tries to skip plan approval, source from weak signals, bulk send, expose private context, or claim learning without Memory Store records.
- When Exa/Websets/Monitors are missing, output exact setup steps, queries, Webset specs, monitor specs, and import-ready CSV schemas; do not pretend production sourcing, deep ICP discovery, send-ready signal cards, outbound copy, or always-on monitoring happened.
- Treat `plan_new_campaign`, `start_new_campaign`, `monitor_campaign`, `campaign_insights`, and `update_prior_campaign` as first-class modes. Do not force every request through first-run planning.
- For high-scale runs, separate sourcing volume from send volume. It is acceptable to source roughly 1,000 leads/emails per day after connector gates pass, but sends ramp only when row quality, deliverability, and reply learning justify it. Default ramp shape is `10/day -> 20/day -> 50/day`, with promotion gated by message quality, bounce risk, suppression checks, and mailbox health.

## Loop

0. **Plan first.** If no campaign folder exists or the user is starting fresh, enter the host's plan mode (Claude Code, Codex, Cowork) and co-write the proposed plan with the user — name, hypothesis, offer, ICPs (including at least one unconventional persona from `references/campaign-planner.md` Persona Discovery), scale, success criteria, exclusions, signal sources, send ramp, stop conditions. Before plan approval, do not create folders or record a campaign thread unless the user explicitly asks to save a draft. After the user approves or asks to persist it, ask where to save (default: `./<slug-from-name>`), create the campaign folder, write `plan.md` first, and record the campaign thread to Memory Store. See `references/campaign-folder.md`.
1. Check in, list/select 0-3 relevant briefs, read selected briefs only when needed, and recall supporting context.
2. Classify campaign mode and context sources: plan, start, monitor, insights, update, refresh, expand, rescue, reactivate, or event/launch.
3. Map funnel, ICP, signal, proof, execution, and learning systems.
4. Mine customer stories, current consumer patterns, prior outcomes, activation gaps, and failed/weak accounts for persona hypotheses, proof paths, useful objections, and segment language. For Memory Store itself, start from actual consumers/customers before public-market extrapolation.
5. Build the campaign unit: `persona + high-intent signal + offer angle + proof path + next action + learning intent`.
6. Create the worker graph and connector plan, including production/degraded mode status for Exa, Websets, Gmail, Monitors, and Calendar.
7. Source, enrich, score, and dedupe evidence cards into `campaigns/<slug>/accounts.csv` and `signal-cards/`.
8. Draft only rows that pass the planner gate; write to `copy/<account>.md`.
9. Apply plan approval, send ramp, followup cadence, channel policy, suppressions, and stop conditions; track in `sends.csv`.
10. Create or propose routines for monitors, Websets refreshes, Gmail scans, followups, digests, and weekly learning. Persist `monitors.json` and `events.jsonl`.
11. Distill durable rules, outcomes, and any sparse canonical brief deltas through `references/learning-loop.md`, then record only approved or confirmed learnings through Memory Store at the main-agent layer (workers do not record). Append each call to `learnings.md`.

## Output

Return, in order: campaign read, briefs used, plan status, campaign mode, campaign system, planner, ICP matrix, high-intent signal plan, work plan, signal cards, copy package, channel policy, autopilot policy, routine candidates, review queue, learning prompt, brief delta.

## Minimum Inputs

Infer first, ask only blockers: company/product, campaign mode, context sources, active offer, goal/CTA, ICP, sender/channel, exclusions, send policy, connector gaps, scale, and timing.

## Invariants

- Do not send before plan approval.
- After approval, autonomous sends must stay inside the approved ramp, CTA policy, same-company rule, and stop conditions.
- Do not invent customers, metrics, quotes, emails, funding, job changes, or buying signals.
- Every non-obvious claim needs a source URL, Memory Store ID, or approval flag.
- A website, category fit, or founder title is context, not a live signal.
- Exa, Websets, Gmail, and Monitors are first-class production layers. If Exa or Websets credentials are unavailable, continue only in planning mode, ask for the Exa API key setup, and say exactly what is blocked. If Gmail is unavailable, no send/followup/reply-learning action is production-ready.
- Do not expose private Memory Store context in outbound copy unless approved.
- Do not claim the system learned unless `record` wrote the confirmed learning.
- Do not create or update a brief unless the learning is reusable, approved or evidence-backed, and changes how future agents should operate. Otherwise record it as memory and let recall retrieve it.
- Do not claim a brief changed unless a brief-editing tool succeeded or the user approved a pending brief delta.

## Reference Loading Map

- GTM plan missing or approval unclear: use `campaign-setup` plus `references/failure-modes.md`.
- New plan or saved campaign artifacts: `references/campaign-engineering.md`, `references/campaign-planner.md`, `references/campaign-folder.md`.
- Sourcing, lead generation, enrichment, or signals: `references/exa-workflows.md`, `references/signal-sourcing.md`, `references/enrichment-catalog.md`; route persistent lists to `websets-sourcing`.
- Copy or sequences: `references/campaign-planner.md`, `references/copy-and-sequences.md`, and `references/failure-modes.md`.
- Monitoring or recurring work: `references/automation-routines.md`, `references/monitors.md`, and `references/parallel-routines.md`.
- Conversational rules, plan corrections, replies, outcomes, weekly insights, or skill-improvement candidates: `references/engagement-model.md`, `references/learning-loop.md`, and `references/failure-modes.md`.
- Sparse canonical brief decisions: `references/campaign-engineering.md`, `references/campaign-folder.md`, and `references/learning-loop.md`.