GTM Agent (Go-To-Market Agent)

Overview

GTM Agent is a Claude Code agent that takes a finished or near-finished project and writes back a concrete, prioritized plan for shipping it and getting it in front of real users. It reads the project’s own documentation (README.md, plan.md, CLAUDE.md, or any files named), classifies it by category, stack, maturity, and target user, then produces a single GTM_GUIDE.md with five sections. Every output is a Markdown document to act on — the agent never deploys, posts, publishes, or registers anything on the user’s behalf.

Key Features

• Five guide sections in one run: Positioning (namespace and competitor check, refined one-liner, defensible-vs-merely-true differentiators, “who this is not for”), Shipping (deployment options plus a presentation-readiness checklist), Distribution (rated and prioritized launch-platform list), Marketing (field strategy plus a pitch script), and Pricing & Packaging (license recommendation, free-vs-paid boundary, comparables, and the exact command to set payments up)
• Any single section can be requested on its own, and an existing guide can be refreshed against the project’s current state with a “what changed” summary
• Three sections are grounded in live web search — Positioning, Marketing, and Pricing — because namespace status, field practice, and comparable prices all go stale fast; the ref files own the method, the search owns the substance
• Two-wave orchestration: Positioning runs first and alone, then its findings feed Shipping, Distribution, Marketing, and Pricing, which run in parallel
• Failure-recovery contract: a failed specialist is retried once, then its section is produced by the orchestrator from the same ref files and disclosed in the guide footer, so a run never stalls
• Launch-platform knowledge lives in 12 YAML files carrying only launch-strategy metadata — adding a platform is a new YAML file, no code change

Technical Decisions

The agent follows an orchestrator + specialist pattern: one gtm-agent.md orchestrator plus five specialist agent definitions, with method knowledge split into eight on-demand ref files so per-run token cost stays low. The deliberate architectural departure from a purely static agent is live search in three of the five specialists — their substance is intentionally not baked into ref files, which own only the method. Specialists are model-tiered (Sonnet for structured extraction, Opus for the search-and-judgement roles), and the platform registry is guarded by a standalone Python schema validator that is a maintenance tool only, never part of an agent run.