Skip to Content
CoursesAI-Powered GTMReusable GTM agents

From Prompt to Reusable GTM Agent

Outcome: one chain you have run successfully, saved as a parameterized skill with caps and guardrails, tested by someone other than you.

Surface
MCP server
Level
Intermediate
Uses
Any chain from this course
Credits
~10 for a capped test run
Prerequisite
Lesson 04, and one chain that works

Why a chain becomes a skill

A prompt that works is a prompt you will retype badly next month. The parts that made it work — the exact tool names, the filters, the caps, the output format — are precisely the parts people drop when reconstructing from memory.

A skill file freezes them. It also makes the chain shareable: a colleague triggers it without needing to know which of 50 tools to call or in what order.

The library of ready-made ones lives at syncgtm.com/gtm-agents . This lesson is about writing your own.

What goes in

The goal, in one line

What the chain produces. “A verified, sequenced list of people who engaged with a competitor’s post.”

The prerequisites

Which tools, which integrations, which credentials. A skill that assumes a CRM connection should say so rather than failing halfway.

The steps, named explicitly

Tool by tool, in order, with the tool names spelled out. “Use linkedin_post_commenters” fires reliably; “find the people who commented” does not.

The filters, spelled out

Where the qualification happens, and what it excludes. This is the part that keeps the run cheap.

The caps

A hard row limit at every step that generates rows. Non-negotiable — see below.

The output format

What comes back and in what shape. A table with named columns, not prose.

The guardrails

What the chain must never do: write to the CRM without confirmation, contact suppressed accounts, exceed a credit budget.

Parameterize the variable parts

The difference between a note-to-self and a reusable skill is that the variable parts are named inputs.

Inputs:
  POST_URL       — the LinkedIn post to pull engagers from
  TITLE_FILTER   — seniority/function to keep
  MAX_LEADS      — hard cap on rows enriched (default 25)
  CAMPAIGN_ID    — destination campaign

Steps:
  1. Call linkedin_post_commenters on {POST_URL}. Cap at 200 commenters.
  2. Keep only people whose title matches {TITLE_FILTER}. This filter is free —
     apply it before any enrichment.
  3. Take the first {MAX_LEADS} survivors.
  4. find_work_email on those rows only.
  5. verify_email. Keep status = valid.
  6. Return a table: name, title, company, email, post URL.
  7. Do NOT push to {CAMPAIGN_ID} until I confirm the table.

Three things to notice: the free filter runs before the paid step, the cap is explicit at two points, and the write action requires confirmation.

Caps are the guardrail that matters

An agent that misreads a filter and enriches 2,000 rows instead of 25 has spent your budget before you notice. Every skill needs:

  • A cap on rows returned from any sourcing step
  • A cap on rows enriched, separately — the two are different numbers
  • A credit ceiling stated in the skill, so the model can refuse to exceed it
  • A confirmation gate before anything that writes outward: CRM, sequencer, email

Never ship a skill that writes to a sequencer or CRM without a confirmation step. An agent that misreads a filter and pushes the wrong 400 people into a live campaign cannot be undone by editing the prompt. The confirmation costs you one message and removes the entire class of failure.

Test before you share

Run it yourself with a cap of 5

Read every row. Confirm each step fired the tool you intended.

Run it on a different input

A second post, a second segment. Skills that work on one input and break on another usually have a hidden assumption in a filter.

Hand it to a colleague

Watch them run it without explaining anything. Whatever they ask you is what the skill is missing.

Check the credit consumption

Against what the skill claims it costs. Update the claim if it is wrong.

Do this now

  1. Take the chain from lesson 04 that produced a result you were happy with.
  2. Write it out in the seven-part structure above.
  3. Name every variable and give each a default.
  4. Add caps at both sourcing and enrichment, and a confirmation gate before any write.
  5. Run it with a cap of 5 and read every row.
  6. Have someone else run it cold.
  7. Note the credit cost in the skill itself.

Check your work

  • Every tool is named explicitly, not described
  • Free filters run before paid steps in the written order
  • Caps exist at sourcing and at enrichment, separately
  • Any outward write requires confirmation
  • Someone else ran it successfully without help

Where this breaks

A skill that names no tools is the failure that looks fine and behaves randomly. “Find people who engaged with this post and get their emails” leaves the model to choose among several plausible tools, and it may choose differently on different days — different coverage, different cost, different results, with nothing to point at when the output changes. Name the tool every time.

Further automation

Keep skills in one place with their cost and their last-tested date. A skill nobody has run in six months is a liability: tool parameters change, integrations expire, and the failure surfaces when someone is in a hurry. Re-run each one quarterly with a cap of 5.

Next lesson

06 — Describing your ICP to a model, where the Find module starts.

Reference for this lesson: MCP prompting guide, MCP tools, MCP setup, AI agents.

Thinking with MCPResearch