# Build a self-improving GTM system This is the agent-readable version of the GrowthOS deck. Use it with Claude Code, Codex, or another coding agent when you want to build the system described in the presentation. Links: - View the deck page: https://omarismail.com/projects/growth-os/deck - Share the email unlock page: https://omarismail.com/projects/growth-os - Download the PDF: https://omarismail.com/projects/growth-os/growth-os.pdf - Open the prompt pack: https://omarismail.com/prompts/growth-os - Download the prompt pack markdown: https://omarismail.com/skills/growth-os-prompt-pack.md The prompt pack contains the implementation instructions. This file is the deck text, extracted from the final PDF so agents can read the material without parsing slides. ## Deck Text ```text growthos 01 Build a self-improving GTM system. A guide to building a GTM system for Claude Code, Codex, and other agents. context + workflows + guardrails + learning gtm-system.md 01:01 growthos introduction 02 Why read this deck? This deck explains how to build a GTM system that agents can use to run real sales and marketing work. 01 Understand the system 02 Build your own how to give agents the customer create the directory structure and market context they need how to turn repeated GTM work write the first context pages into workflows feed reviewed learning back into create your first workflows the next run orientation 02:01 growthos introduction 03 What is a GTM system? A GTM system lets Claude Code and Codex orchestrate sales and marketing work. 1 2 3 4 context workflows guardrails learning What the system knows about The repeatable GTM jobs the Rules that stop the system from What gets saved after each run your customers, market, offer, system can run, such as sending, spending, publishing, so the next run starts from proof, and voice. researching accounts, building or changing records without better information. campaigns, or reporting approval. performance. gtm definition 03:01 growthos problem 04 Problem 01: Most teams lose what they learn. Customer calls, ad playbooks, campaign metrics, and landing page tests create useful context. This is gold dust… but often stays scattered and unused. customer calls ad playbooks campaign metrics problem quotes, pains, objections angles, spend, winners conversion, CAC, signal quality The next task starts with someone piecing the story back together: finding notes, remembering decisions, and positioning notes landing page tests working out which evidence still matters. ICP, proof, message claims, layouts, changes objections memory leak 04:01 growthos solution 05 Solution 01: Build the context layer first. Before touching any tools or automation, the system needs a clear picture of who the customer is, what they care about, what has worked, and how the company should speak. collect distil link context layer calls, CRM, reports, docs ICP, personas, proof, claims back to evidence voice The context layer is the base of the system. You will create a ‘GTM wiki’: short, readable read update pages with clear names and links back to the evidence. agents start from context reviewed learning returns context solution 05:01 growthos problem 06 Problem 02: GTM work is manual. Most GTM jobs are manual, time consuming (and painful)… leaving little room for creative thinking. ICP analysis account enrichment campaign planning problem same question, new creating infinite CSVs long briefs written by spreadsheet hand Agents help most when the same task happens often enough to become a reusable workflow. outbound reporting same segment logic, new digging through thread campaign managers workflow problem 06:01 growthos solution 07 Solution 02: Package tasks into workflows. A workflow should show how the work starts, what instructions it follows, what context it reads, which tools it can use, and where the output is saved. command skill context workflow rule human entry point saved procedure important information A skill is the instruction file for a workflow. It tells the agent what to read, what to do, tools output review which tools it can call, and where to save the result. which apis or services reviewable files approve and learn workflow solution 07:01 growthos problem 08 Problem 03: Agents need boundaries. GTM agents can touch budgets, outbound messages, CRM records, public pages, and customer-facing claims. Approval needs to be built into the system from the start. ad spend CRM writes problem budgets, bids, launches stages, owners, notes When approval is unclear, people either block the agent or let it take risks they cannot audit. outbound sends public claims emails, LinkedIn, sequences ads, pages, social posts guardrail problem 08:01 growthos solution 09 Solution 03: Put guardrails around live work. Guardrails make the safe path explicit. The agent can read and draft freely, then ask before anything touches spend, customers, or production systems. read freely draft safely prepare carefully approve explicitly approval rule metrics ads CRM updates send transcripts emails campaign changes spend Draft first. Review before live. files campaign specs publish Any change to spend, customers, CRM, or public pages needs a clear human approval step. guardrails solution 09:01 growthos problem 10 Problem 04: Agents stop working… A useful agent can work well for one use case, then struggle when the ICP, channel, offer, tool, or success metric changes. new use case new evidence new channel rule problem the old workflow misses the context stays stale the guardrail is steps incomplete When learning only lives in chat history, the next run starts from old assumptions. new metric new positioning success is measured old language keeps differently returning learning problem 10:01 growthos solution 11 Solution 04: Create a learning loop. Create a ‘recursive loop’ where results and feedback auto-updates the context, workflow, guardrails, or checks. Each finished run can improve the next one. 1 2 3 learning rule run work save output review result Self-improving means the system has a place to save what it learned. 6 5 4 next run update context write learning closed loop 11:01 growthos system 12 The whole system is one learning loop. Evidence becomes context. Workflows use that context. Guardrails control live actions. Reviewed outputs create learning. sources context workflows guardrails the spine calls, CRM, reports, ICP, personas, proof, repeatable GTM jobs approval, risk, rate docs channels limits This loop is the spine of the deck. Every file and workflow should make the next pass easier. learning outputs reviewed updates for campaigns, reports, the next run lists, briefs system loop 12:01 growthos part 1 13 part 1 Map the system architecture. Turn the model into a folder of plain files: sources, context, workflows, tools, outputs, checks, guardrails, and learning. part 1 architecture section part 1 architecture 13:01 growthos architecture 14 The system has six core parts. A folder can hold the system when each part has a clear job. sources context skills raw calls, CRM exports, reports, current ICP, personas, voice, repeatable workflows agents can docs proof, channels run tools outputs evals APIs, scripts, services, and local the work produced by each run checks for quality, facts, voice, adapters and risk architecture parts 14:01 growthos architecture 15 Part 01: sources. Sources are the raw material: calls, CRM exports, campaign reports, docs, research notes, and anything the system should be able to check. sources context skills tools outputs evals raw evidence wiki pages saved workflows safe access saved work quality checks source folder use sources to sources/ Check quotes, claims, and numbers. calls/ crm-exports/ See where a belief came from. campaign-reports/ support-threads/ research-notes/ Rebuild context when the market changes. Keep useful evidence close to the work. sources 15:01 growthos architecture 16 Part 02: context. Context is what agents read before they act. It works best as short, named pages with clear links back to evidence. sources context skills tools outputs evals raw evidence wiki pages saved workflows safe access saved work quality checks context pages context should contain context/icp.md The current ICP and account logic. context/personas.md context/positioning.md Personas, pains, objections, and proof. context/proof.md context/channel-linkedin.md runner-instructions.md -> read order Voice, positioning, and channel rules. Enough source links to check important claims. context wiki 16:01 growthos architecture 17 Part 03: skills. A skill is a saved set of instructions for a repeated job. It says when to use it, which context to read, which tools are allowed, and what output to save. sources context skills tools outputs evals raw evidence wiki pages saved workflows safe access saved work quality checks skill shape use a skill when persona-extraction/SKILL.md The same task repeats. read: transcripts, ICP, voice The output should follow the same standard. do: pull quotes, extract jobs, write persona cards tools: transcript search, filesystem save: context/personas.md after review Agents need clear boundaries before using tools. skills architecture 17:01 growthos architecture 18 Part 04: tools. Tools are the connectors agents use to work with services and files: scripts, API wrappers, CLI commands, MCP servers, browser actions, or local adapters. sources context skills tools outputs evals raw evidence wiki pages saved workflows safe access saved work quality checks example tools approval rule hubspot.readAccounts Read-only tools can run freely. clay.enrichCompanies apollo.findContacts Drafting tools can write local files. linkedin.readBenchmarks filesystem.writeFile Publishing, spend, and CRM writes need approval. tools architecture 18:01 growthos architecture 19 Part 05: outputs. Outputs are the files created by each run. They make the work reviewable, reusable, and easier to compare with the next version. sources context skills tools outputs evals raw evidence wiki pages saved workflows safe access saved work quality checks output folder good outputs include outputs/ The finished asset or recommendation. campaigns/ reports/ The assumptions and source evidence. personas/ account-notes/ decisions/ Open questions and approval notes. A short learning update when something changes. outputs 19:01 growthos architecture 20 Part 06: evals. Evals are repeatable checks for quality, facts, voice, risk, and performance. They help decide whether the result should change context. sources context skills tools outputs evals raw evidence wiki pages saved workflows safe access saved work quality checks eval files evals help you evals/claims.md Catch weak claims before they ship. evals/voice.md evals/channel-rules.md Keep tone and proof standards consistent. evals/risk.md evals/performance.md Review risky actions before they affect customers. Decide what should change before the next run. evals 20:01 growthos architecture 21 Each workflow names what it needs. Each workflow should name what to read, which tools it can use, what output to save, and which checks to run. 01 command Names the job and the output required. where to write it 02 skill Defines the workflow, read order, tool permissions, and output shape. The read order should be visible in the file your agent 03 context reads first, such as Loads the ICP, persona, voice, proof, and channel files for this job. CLAUDE.md, AGENTS.md, or runner instructions. 04 sources Checks raw evidence before making claims or changing beliefs. 05 evals Runs the quality, voice, fact, and risk checks before review. workflow read order 21:01 growthos part 2 22 part 2 Build the context layer. Turn customer evidence into the context pages agents read before doing GTM work. part 2 context section part 2 context 22:01 growthos context 23 Build 01: identify your ICP. Pull revenue, margin, retention, expansion, and deal data before choosing the ICP the system should focus on. value enrich language angles revenue + retention accounts + signals calls + threads voice + proof inputs output bookings.csv Rank the best customers by value. deals.csv revenue-by-account.csv Cluster them by role, industry, size, and use case. retention.csv expansion.csv margin.csv Choose a primary and secondary ICP. Save the decision in context/icp.md. icp analysis 23:01 growthos context 24 Build 02: enrich top accounts. Customer data shows which customers create the most value. Enrichment explains what those accounts have in common and which signals predict fit. value enrich language angles revenue + retention accounts + signals calls + threads voice + proof tools and fields output Clay -> company size, industry, tech A richer account profile. Apollo -> roles and contacts LinkedIn -> buyer profiles Signals that predict fit. Firecrawl -> website signals AI research -> triggers and context Sharper personas and objections. A better target account list. enrichment 24:01 growthos context 25 Build 03: pull language from transcripts. Sales calls, support threads, interviews, and lost-deal notes show the jobs, anxieties, objections, and exact words customers already use. value enrich language angles revenue + retention accounts + signals calls + threads voice + proof inputs extract sales transcripts Jobs to Be Done and Four Forces patterns. support threads customer interviews Exact quotes customers use. lost-deal notes call summaries Objections, anxieties, and pull factors. Disqualifying jobs and poor-fit signals. persona extraction 25:01 growthos context 26 Build 04: turn this information into ‘personas’. The voice and messaging pages should turn customer evidence into reusable decisions: voice traits, proof standards, and angle ideas for ads, emails, and landing pages. value enrich language angles revenue + retention accounts + signals calls + threads voice + proof angle matrix save into context persona | pain | proof | next angle context/voice.md CFO | margin risk | saved hours | audit trail context/proof.md Ops | manual handoff | faster flow | workflow context/personas.md context/angles.md angle matrix 26:01 growthos part 3 27 part 3 Build the workflows. Turn the context layer into repeatable GTM flows. part 3 workflows section part 3 workflows 27:01 growthos workflows 28 Start with the GTM stack. A workflow is one repeatable job inside the wider GTM system. The same architecture can support research, acquisition, conversion, measurement, and orchestration. job what it does example tools system output find and understand accounts Clay, Apollo, Fireflies, web ICP, account notes, signals 01 Research research reach people and create demand Meta, LinkedIn, outbound, partners campaigns, lists, replies 02 Acquire turn interest into pipeline and revenue HubSpot, CRM, calendar, call notes pipeline, revenue, attribution 03 Convert read performance and decide what HubSpot, GA4, ad platforms, scorecards, learnings, evals 04 Measure changed reports coordinate humans, agents, and tools agent runners, approvals, logs runs, approvals, learnings 05 Orchestrate gtm stack 28:01 growthos workflow example 29 Run path 01: command. The command is how a person starts the run. It names the GTM job and gives the agent a predictable route through the system. command skill context tool calls output review /new-linkedin linkedin-campaign ICP, personas, LinkedIn, HubSpot, campaign pack approve spend campaign SKILL.md channel rules Clay, Apollo + learning file and publish command what happens next The runner loads the LinkedIn campaign skill. /new-linkedin-campaign The skill tells the agent which context to read. Run this when you want the system to draft a LinkedIn Tools enrich accounts and check channel details. campaign from the current ICP, account list, positioning, proof, and channel rules. The result is saved as a campaign pack for review. workflow command 29:01 growthos workflow example 30 Run path 02: skill. The skill is the instruction file for the workflow. It keeps the campaign task consistent: what to read, what to do, which tools are allowed, and when to ask. command skill context tool calls output review /new-linkedin linkedin-campaign ICP, personas, LinkedIn, HubSpot, campaign pack approve spend campaign SKILL.md channel rules Clay, Apollo + learning file and publish skill file why it matters linkedin-campaign/SKILL.md The workflow lives in a file the team can reuse. read: ICP, personas, target accounts, LinkedIn rules The same campaign job can run again next week. do: choose segment, draft angle, write campaign pack tools: HubSpot, Clay, Apollo, LinkedIn, filesystem approval: draft freely; ask before spend or publish Live changes stay behind explicit approval. skill anatomy 30:01 growthos workflow example 31 Run path 03: context. The agent should know the customer, the segment, the proof, and the channel before it calls tools or drafts copy. command skill context tool calls output review /new-linkedin linkedin-campaign ICP, personas, LinkedIn, HubSpot, campaign pack approve spend campaign SKILL.md channel rules Clay, Apollo + learning file and publish context read order what this gives the agent context/icp.md Who the campaign is for. context/personas.md context/positioning.md Which pains, objections, and proof matter. context/proof.md context/channel-linkedin.md data/target-accounts.csv What a good LinkedIn campaign should do and avoid. Which accounts or segments are worth targeting first. workflow context 31:01 growthos workflow example 32 Run path 04: tool calls. Tools are the connectors agents use to work with services and files: scripts, API wrappers, CLI commands, MCP servers, browser actions, or local adapters. command skill context tool calls output review /new-linkedin linkedin-campaign ICP, personas, LinkedIn, HubSpot, campaign pack approve spend campaign SKILL.md channel rules Clay, Apollo + learning file and publish tool calls approval rule hubspot.readAccounts Read-only calls can run freely. clay.enrichCompanies apollo.findContacts Drafts can be written locally. linkedin.readBenchmarks linkedin.createDraftCampaign # after approval filesystem.writeCampaignPack Spend, publishing, and CRM writes need approval. workflow tools 32:01 growthos workflow example 33 Run path 05: output and review. The workflow ends with files the team can inspect: the campaign spec, the audience, the creative brief, the approval questions, and the learning update. command skill context tool calls output review /new-linkedin linkedin-campaign ICP, personas, LinkedIn, HubSpot, campaign pack approve spend campaign SKILL.md channel rules Clay, Apollo + learning file and publish saved output review outputs/campaigns/linkedin/.../spec.md Check the audience, claims, proof, offer, and spend. audience.csv creative-brief.md Approve publishing only when the risks are clear. approval-checklist.md learning/channel-linkedin.md Save useful learning after review so the next run starts from better context. workflow output review 33:01 growthos part 4 34 part 4 Guard live actions. Put boundaries around the parts of the system that can spend money, send messages, publish campaigns, or change customer records. part 4 guardrails section part 4 guardrails 34:01 growthos guardrails 35 Guardrail 01: approval rules. GTM work touches live budgets, CRM records, outbound messages, and brand reputation. The approval rules should be clear from the start. read freely draft safely prepare carefully approve explicitly principle metrics ads CRM updates send transcripts emails campaign changes spend Draft first. Review before live. files campaign specs publish Any change to spend, customers, CRM, or public pages needs a clear human approval step. guardrails approval 35:01 growthos guardrails 36 Guardrail 02: label what each tool can change. Tools should say what kind of action they take. Reading a report is different from changing CRM data, sending outbound, or publishing ads. read draft prepare write launch audit no approval local files staged API approval explicit logs tool changes guardrail works when file_write Each skill says what it can read, draft, or change. crm_write email_send Risky workflows do not run without a review step. external_post ad_publish llm_spend Live changes route through approval. git_push The person reviewing the run can see what changed and why. guardrails tool changes 36:01 growthos guardrails 37 Guardrail 03: respect rate limits. External APIs have quotas and platform rules. The system should throttle requests, retry cleanly, stop on rate-limit errors such as 429s, and write logs to understand what happened. read draft prepare write launch audit no approval local files staged API approval explicit logs rate-limit plan guardrail works when per app Read each platform's current API limits. per account per user or member Batch and cache where the API supports it. retry-after handling backoff and batching request IDs in logs Stop and ask if a live channel starts failing. Log 429s, request IDs, and retry decisions. guardrails rate limits 37:01 growthos guardrails 38 Guardrail 04: stage writes before launch. Paid channels should create drafts or paused campaigns first. Turning something live should be a separate approved step, with IDs and request logs saved after the run. read draft prepare write launch audit no approval local files staged API approval explicit logs staged launch guardrail works when .growthOS/approvals.jsonl Approval payload is visible before execution. status: PAUSED or DRAFT activation: separate approval Create calls cannot start spend by accident. outputs/launches/.../id-map.md logs/adapter-events.jsonl The ID map is saved for audit and rollback. Sandbox tests prove the live path is gated. guardrails staging 38:01 growthos part 5 39 part 5 Make the system learn. Turn reviewed outputs into better context, examples, rules, and evals. part 5 learning section part 5 learning 39:01 growthos learning 40 Reviewed outputs improve the next run. A run produces output. A human reviews what changed. The approved learning updates context, examples, rules, or evals. 1 2 3 what improves run work save output review result Small, sourced changes make the system better without making it hard to audit. 6 5 4 next run update context write learning recursive loop 40:01 growthos learning 41 The learning lives in files. Each useful run should leave a small, reviewable update. The update should say what changed, why it changed, and which evidence supports it. outputs//report.md what happened in the run outputs//learning.md what the system should remember context/.md approved updates to ICP, proof, voice, or channel logic evals/.md new checks for quality, facts, risk, or performance skills//SKILL.md workflow changes only when the process itself improves learning files 41:01 growthos learning 42 Use the loop to improve workflows. Use the Karpathy wiki pattern to keep context readable: update the page that would have changed the result, then rerun the workflow. 1 2 3 keep it small read context run workflow review output Change one thing at a time: context, skill instructions, tool behavior, or eval criteria. 6 5 4 rerun update file find failure workflow improvement loop 42:01 growthos learning 43 Checks decide what should change. Checks help decide whether the result was good, whether the context was wrong, and what should change before the next run. output review eval learning context skill campaign pack human notes quality checks approved update better next run only if needed eval questions good learning updates Is the claim supported? Name the source. Does this match our voice? Did the workflow use the right context? Explain the reason. Was the result useful? What should change before the next run? Update the smallest file possible. Leave the next run easier to audit. learning evals 43:01 growthos part 6 44 part 6 Getting started. Build the first useful version in order. Each step points to the prompt pack and ends with a review gate before you move on. getting started section getting started 44:01 growthos getting started 45 Start 01: create the folder. The folder is the system. Start by making the core parts visible, named, and easy for Claude Code, Codex, or another agent to read. folder context workflow tool measure run file system wiki pages one skill safe access scorecard audit loop prompt and output move on when link: prompt-pack.md#01-create-folder The six core folders exist. creates: runner-instructions.md The instruction file names what to read first. sources/ context/ skills/ tools/ The agent can explain what each folder is for. outputs/ evals/ Open questions are written down. start folder 45:01 growthos getting started 46 Start 02: build the context layer. Use existing evidence before asking new questions: customers, transcripts, CRM exports, support threads, campaign reports, and website copy. folder context workflow tool measure run file system wiki pages one skill safe access scorecard audit loop prompt and output move on when link: prompt-pack.md#02-build-context The best customer patterns are clear. writes: context/index.md Personas use customer language. context/icp.md context/personas.md Important claims point back to evidence. context/proof.md context/voice.md context/channel-notes.md Context is short enough to read first. start context 46:01 growthos getting started 47 Start 03: add one workflow. Pick one repeated GTM job and make it reliable before connecting more channels. The first workflow should read context, produce output, and ask before risky actions. folder context workflow tool measure run file system wiki pages one skill safe access scorecard audit loop prompt and output move on when link: prompt-pack.md#03-add-workflow The skill defines read order and output shape. writes: skills//SKILL.md The workflow runs from sample input. outputs// evals/.md The output is saved in the expected place. The review checklist catches weak work. start workflow 47:01 growthos getting started 48 Start 04: connect one safe tool. Begin with read-only access. Let the agent inspect accounts, transcripts, reports, or campaign data before you allow it to write to live systems. folder context workflow tool measure run file system wiki pages one skill safe access scorecard audit loop prompt and output move on when link: prompt-pack.md#04-connect-tool The tool has clear inputs and outputs. writes: tools/.md A read-only test run succeeds. tools/.mjs outputs/tool-test.md Errors and rate limits are logged. read first; write later Write actions are blocked until approved. start tool 48:01 growthos getting started 49 Start 05: add measurement and guardrails. The first version needs just enough structure to know whether the workflow helped and whether any risky action is still behind approval. folder context workflow tool measure run file system wiki pages one skill safe access scorecard audit loop prompt and output move on when link: prompt-pack.md#05-measure-and-guard The scorecard says what good means. writes: evals/performance.md Approval rules cover spend, sends, and CRM writes. evals/voice.md evals/risk.md The report format can be repeated. .growthOS/approvals.jsonl outputs/reports/ The system knows what requires human review. start measure 49:01 growthos getting started 50 Start 06: run one loop and audit it. The first useful version passes when one workflow runs end to end, saves a reviewable output, and leaves the next run with better context. folder context workflow tool measure run file system wiki pages one skill safe access scorecard audit loop prompt and output move on when link: prompt-pack.md#06-run-and-audit A user can inspect one real output. runs: /new-linkedin-campaign The report explains what happened. -> output saved -> report written The learning note has a source and a reason. -> learning reviewed -> context updated The audit names the smallest next tweak. start first loop 50:01 growthos outcome 51 A good system makes the next run easier. Each run leaves behind the files the next run needs: context, workflows, tools, approvals, outputs, checks, and learning. Humans can read it and understand the strategy. Agents can read it and do the next useful task. The build can be reviewed step by step before it expands. Every run leaves the system with a better starting point. outcome 51:01 growthos build your own 52 Build your own. Use the deck to understand the model, the prompt pack to create the first version, and the folder to keep improving it. omarismail.com/projects/growth-os omarismail.com 52:01 ```