Four layers that make a GTM agent actually work in production

The Claude Code GTM Agent Starter Pack has a four-layer architecture. You can grab the base template from /bites/. Each layer has a specific job. Understanding the layers is the difference between running a system and running a chatbot that forgets everything between sessions.

This is the internal view: how each layer works, why it’s separate, and what breaks if you skip one.

Layer 1: CLAUDE.md: operator identity

CLAUDE.md is the first file Claude Code reads when it starts a session. It defines who the agent is, not what it can do.

For a GTM agent, CLAUDE.md contains:

The key design principle: the identity is persistent. Claude Code reads CLAUDE.md at session start, which means the agent has the same operating constraints every time. You’re not re-explaining the context each session.

Layer 2: MCP tools: real capabilities

MCP (Model Context Protocol) tools give the agent the ability to act on external systems, not just generate text.

The GTM stack uses:

• Brave Search MCP: web research without hallucination risk (reads real pages)
• HubSpot MCP (or Clay webhook): CRM read/write
• Gmail MCP: draft creation (never send, only draft, per the rules in CLAUDE.md)
• Notion MCP: log completed research briefs to the shared workspace

Without MCP tools, you have a language model. With them, you have an agent that can look up a company, check if they’re in the CRM, draft a personalized email, and log the work: in a single session.

Layer 3: Client memory files: persistent context

The /memory/ directory holds everything the agent needs to know about the client that doesn’t change session-to-session:

/memory/
  icp.md         : ICP definition: industry, size, roles, disqualifiers
  sequences/     : email templates per vertical, per stage
  accounts/      : per-account research briefs (auto-generated, human-reviewed)
  activity-log.md: completed actions log
  objections.md  : common objections and approved responses

This is what makes the agent compoundable. The research from Tuesday’s session is available on Thursday. The objection handling approved last month is in every subsequent session. The agent doesn’t need to be re-briefed; it reads the memory files.

Layer 4: Operator skills: reusable prompt programs

Skills are defined prompt programs that do a specific GTM job. The starter pack includes five:

research: Given a company name, produces a structured research brief: company overview, recent signals, likely pain points, ICP fit score.

enrich: Given a contact name and company, finds LinkedIn profile, role, likely priorities, and adds to the accounts memory file.

draft: Given a contact and their account brief, produces a personalized first-touch email using the appropriate sequence template.

update: Given a completed action, logs it to the activity log and updates the relevant account file in CRM.

score: Given a batch of leads, scores each against the ICP definition and returns a prioritized list.

Each skill is a structured prompt with defined inputs, outputs, and rules. You invoke a skill by name: /research Acme Corp. The agent reads the skill definition, executes it, and returns structured output.

Why the layers matter

Most prompt-based GTM setups collapse because they’re stateless. Each conversation starts from zero. The four-layer architecture solves this:

The gap isn’t capability. It’s the operating model.

Related: How to Build a GTM AI Agent for Outbound Research and CRM Enrichment · GTM Tools: Build vs Buy Decision Framework for Operators