The CRM engine you can
trust an AI agent with

Install and verify

# Node 20+, zero runtime dependencies
npm install -g fullstackgtm
fullstackgtm doctor --json        # expect node.ok: true

# prove the whole pipeline with zero credentials (deterministic per --seed)
fullstackgtm audit --demo --json

# zero-setup connect: hosted browser OAuth — a human approves in the browser,
# provider tokens are minted server-side; no app secret ships in the package
fullstackgtm login hubspot        # or: fullstackgtm login salesforce

# sandboxed / BYO: credentials from env — never echo tokens into argv;
# BYO login reads stdin only
HUBSPOT_ACCESS_TOKEN=... fullstackgtm audit --provider hubspot --save

Machine-readable docs: INSTALL_FOR_AGENTS.md (deterministic install-and-verify with expected outputs), skill.md (the compact agent operating guide), and the package llms.txt documentation map. Headless? FSGTM_NO_BROWSER=1 makes login flows print verification URLs instead of opening a browser.

Full functionality inventory

The core loop

snapshot (versioned canonical export, --since, --archive) · audit (12 built-in deterministic rules, plus custom rules, --rules, --fail-on) · suggest (derive values for requires_human_* placeholders from snapshot evidence, with confidence + reasons) · plans list/show/approve/reject · apply (writes only explicitly approved operation ids; consecutive same-shaped updates and archives batch through provider bulk endpoints — 100 records per call on HubSpot, 200 on Salesforce — with compare-and-set preserved per record and per-operation applied/skipped/conflict/failed results) · report (client-ready markdown/HTML deliverable) · diff (snapshot drift, --fail-on-new-findings) · merge (combine snapshots across systems) · bulk-update (governed generic writes: filtered dry-run plans, filters re-verified per record at apply time, cross-record guards) · dedupe (one merge operation per duplicate group, deterministic survivor selection) · reassign (governed ownership handoffs; --assign-unowned claims ownerless records) · fix (one-shot plan from a single audit rule) · rules · doctor

Calls → evidence

call parse (any transcript dialect → evidence-quoted insights; LLM with your own key, or --deterministic free baseline) · call classify (call type from deterministic, key-free signals — discovery, demo, negotiation, renewal… — with confidence + reason; --llm tiebreak) · call score (auto-selects the type-specific rubric so a renewal isn't graded on discovery; anchored examples, evidence-quoted per dimension, qualitative band) · call link (which deal was this call about, with confidence + reason) · call plan (next steps → the same governed plan lifecycle)

The create gate

resolve account|contact|deal — call before ANY record creation. Exit 0 = safe to create, 2 = exists or ambiguous: do not create. Identity keys match the audit/merge engines exactly; names alone are never identity.

Governed enrichment

enrich append/refresh/ingest/status — pull from Apollo or ingest Clay exports (CSV or webhook), matched deterministically to existing records. Fill-blanks-only plans: enrichment never overwrites a populated field, and every value flows through the same dry-run → approve → apply gate as any other write.

Revenue truth

backfill stripe proposes one closed-won HubSpot deal per paid Stripe invoice: amount = invoice total, close date = paid date, matched to the customer's account by billing-email domain, then exact name. It dedupes by invoice id and re-resolves at apply, so re-running never double-creates; a customer your CRM does not know becomes an explicit proposed account create in the same plan. backfill runs replays local run history and the health timeline to a paired hosted deployment, idempotently; only statuses, counts, timestamps, and scores leave the machine — never CRM field values.

Lead generation

enrich acquire + icp interview/set/show — net-new leads, ICP-targeted and dupe-safe by default. An ICP you develop by interview drives the discovery filters (Explorium, pipe0/Crustdata) and scores every prospect for fit, so only above-threshold contacts become create_record plans. You never pay to re-enrich a duplicate: anyone already in your CRM (matched on LinkedIn URL, then name + domain) or seen in a prior run is dropped before the paid email step, and every run is metered against a per-profile budget of records and spend. Every lead is assigned an owner at creation — by a fixed rule, round-robin, territory, or the matched company's owner — so prospecting never leaves records ownerless. Like every write, leads land only after you approve the plan.

Scheduled re-audits

schedule add/list/remove/enable/disable/run/install/uninstall/status — recurring runs from a read/plan-side allowlist of commands. Scheduling never auto-approves: unattended runs accumulate proposals for human review, never writes.

The market map

market init/capture/classify/worksheet/observe/fronts/axes/report/refresh — vendors × claims as reviewable config, content-addressed page captures, intensity readings with every quoted span verified character-for-character against the stored capture, deterministic front states, PCA-derived axes. Agents can classify directly: worksheet returns claims + judging rules + page texts; submit via observe.

TAM mapping

tam estimate/accounts/status/report/populate sizes the reachable market from the ICP that drives acquire: a real account count (Explorium, or TheirStack's technology install data for who actually runs a CRM) × a real annual ACV you confirm. No band defaults; it refuses to run without ACV. status classifies existing CRM accounts as in-TAM, out-of-TAM, or unknown so junk records never inflate coverage, report projects burn-up and ETA, and populate schedules plan-only enrich acquire --save runs to fill the gap. Apply stays approval-gated.

Signal-based outbound

signals fetch/list/outcome/weights — watch for the week an account changes, sorted into five weighted buckets (demand, funding, job, company, social); a reposted role outweighs a first-time post. Public ATS boards (Greenhouse, Lever, Ashby) are the free, no-auth source in the box; funding/company/social arrive via staged ingest. Detect-side — it captures triggers to a local ledger and writes nothing to your CRM. Outcomes (signals outcome) re-weight which buckets earn a touch.

The judge

icp judge + icp eval — score each account on timing × fit × memory into send/nurture/skip; every why-now must quote a real trigger verbatim (or it isn't stored), and a deterministic baseline runs key-free. icp eval grades the judge against a golden set (and hot-vs-cold outcomes), exiting 2 below the bar — the calibration gate that blocks a miscalibrated judge from reaching a live send.

Trigger-grounded drafts

draft — one opener per hot account whose first line quotes the trigger in the buyer's own words, emitted as a create_task plan through the same approve → apply gate. It has no send capability and adds none: drafts everything, transmits nothing. No-key runs produce a labeled stub, never fake copy.

MCP server

fullstackgtm-mcp exposes fullstackgtm_capabilities (the machine-readable CLI contract), fullstackgtm_audit, fullstackgtm_rules, fullstackgtm_suggest, fullstackgtm_apply (requires explicit approved ids), fullstackgtm_resolve, fullstackgtm_call_parse, fullstackgtm_market_worksheet, fullstackgtm_market_observe over stdio.

Contracts you can rely on

Exit codes 0/1/2 (success / error / gate or findings threshold) · stable hash ids for findings and operations · --demo --seed for credential-free CI · credential ladder: --token-env → ambient env → BYO stored login → hosted OAuth / broker pairing (the default login hubspot|salesforce: browser consent, provider tokens minted server-side and never shipped in the package) · --profile / FULLSTACKGTM_PROFILE multi-org isolation · BYOK LLM (ANTHROPIC_API_KEY / OPENAI_API_KEY), base-URL override (ANTHROPIC_API_BASE_URL / OPENAI_API_BASE_URL) to run on a GLM/z.ai or local Ollama endpoint, and a deterministic free mode for every LLM feature · providers: HubSpot (read/write), Salesforce (read/write across field updates, merges, tasks with BYO credentials, links, and contact/account creation), Stripe (read-only); deal creation is HubSpot-only for now

The benchmark (CRM-Ops Bench)

Open-source eval harness in the repo: mock HubSpot with REST-fidelity hazards (pagination, search-index lag, concurrent drift), deterministic graders over final state + the server mutation log, CuP and τ-bench pass^k metrics. npm run smoke needs no API keys. Latest results: no model does worse through the framework across the ten tested — nine improve on CuP, one ties — and eight of the ten reach zero unauthorized writes, including every frontier model. See caveats on reduced-protocol rows and arm definitions in the results and methodology.

Safety invariants (not beta, never change)

Audits are read-only · writes are approval-gated (--approve on specific operation ids) · human decisions are refused, not guessed (requires_human_* placeholders) · quoted evidence is verified verbatim against its source.

Add to your agent

The MCP server is plain stdio — it works in any MCP client. And because the engine is CLI-first with --json everywhere, agents without MCP support can drive it directly from a shell.

Agent skill (any skills-aware agent)

npx skills add fullstackgtm/core

Installs SKILL.md — the compact operating guide for driving the CLI safely.

Claude Code

claude mcp add fullstackgtm -e HUBSPOT_ACCESS_TOKEN=pat-... -- npx -y fullstackgtm-mcp

Codex

codex mcp add fullstackgtm --env HUBSPOT_ACCESS_TOKEN=pat-... -- npx -y fullstackgtm-mcp

opencode

// opencode.json
{
  "mcp": {
    "fullstackgtm": {
      "type": "local",
      "command": ["npx", "-y", "fullstackgtm-mcp"],
      "environment": { "HUBSPOT_ACCESS_TOKEN": "pat-..." }
    }
  }
}

pi

pi's philosophy is CLI tools over MCP — which is exactly what this is. Point pi at INSTALL_FOR_AGENTS.md and it can drive the CLI directly. Prefer MCP? The pi-mcp-adapter reads the standard mcp.json format:

// ~/.pi/agent/mcp.json (or /.pi/mcp.json)
{
  "mcpServers": {
    "fullstackgtm": {
      "command": "npx",
      "args": ["-y", "fullstackgtm-mcp"],
      "env": { "HUBSPOT_ACCESS_TOKEN": "pat-..." }
    }
  }
}

What's my first command?

Run npx fullstackgtm audit --demo — it runs the full audit on a deliberately messy demo CRM with no API keys and nothing to install. When you are ready on real data, point it at your CRM with audit (read-only, saves a baseline), then run health any time to see your 0–100 score and how it is trending.

Can an AI agent safely write to my CRM?

Not directly — and that is the point. With fullstackgtm, agents can read everything, but every proposed change becomes a typed patch operation (object, field, before, after, reason, risk) that a human approves before any write happens. Nothing is ever written without an explicit approval, and operations that require a human decision are refused outright until a person supplies the value.

Is fullstackgtm free?

Yes. The framework, CLI, and MCP server are open source under Apache-2.0 with zero runtime dependencies. The hosted Full Stack GTM application (dashboard, sync backend, team workflows) is a separate proprietary product built on top — and features never move from open to closed.

Which CRMs does it support?

HubSpot (read/write), Salesforce (read/write), and Stripe (read-only billing). Salesforce matches HubSpot across the governed write surface: field updates, merges, tasks with BYO credentials, record links, and net-new contact and account creation all work on both, verified against a live Salesforce org. One asymmetry: deal creation (used by the Stripe to closed-won backfill) is HubSpot-only for now; on Salesforce those operations are skipped and reported, never guessed. Hosted HubSpot OAuth cannot create CRM tasks; BYO private-app tokens cover that path. The audit, plan, and apply contract is identical across providers.

Does my CRM data pass through your servers?

There are three modes. Open CLI with your own private-app token or Connected App: the CLI runs on your machine, talks directly to your CRM, and nothing — not data, not tokens — touches Full Stack GTM servers. CLI with the default hosted browser login: CRM data still flows directly between your machine and your CRM; only short-lived auth tokens are minted by our broker, with org refresh tokens held encrypted server-side and revocable per CLI. Hosted app at app.fullstackgtm.com: CRM data syncs to our backend, encrypted at rest, to power the dashboard. LLM features use your own Anthropic or OpenAI key via direct fetch, with deterministic mode available.

Does it cover marketing-side hygiene, or just the sales pipeline?

Today, the package covers sales-pipeline hygiene — the built-in audit rules focus on deals, contacts, and accounts — plus governed enrichment for filling the gaps those audits surface, through the same approval gate as every other write. Marketing-hygiene rules and a marketing-spend layer are in development; when they ship, they will follow the same plan-and-approve contract.

Can it find net-new leads, or only clean the records I already have?

Both. enrich acquire generates net-new leads: an ICP you develop by interview drives the discovery filters and scores every prospect for fit, so the contacts are targeted rather than a random list. It is dupe-safe and metered by default — anyone already in your CRM (matched on LinkedIn URL, then name and domain) or seen in a prior run is dropped before any paid enrichment, every run is capped by a per-profile budget of records and spend, and, like every other write, leads land only after you approve the plan.

When acquire creates a lead, who owns it?

Whoever your assignment rule says — never no one. enrich acquire stamps an owner onto every lead at the moment it is created, so prospecting never leaves a pile of unassigned records for someone to triage later. Route by a fixed owner, round-robin across a team (distributed deterministically, so the same run always splits the same way), territory (by geography, industry, company size, or title), or inherit the owner of the matched company. On a single-owner portal it simply assigns to that person; when several owners exist and you have not set a rule, it refuses to guess — it warns and leaves the leads unassigned rather than route them wrong. To claim records that are already ownerless, "reassign --assign-unowned" hands the whole backlog to an owner through the same approval gate.

How do I know the cleanup is actually working?

Every saved audit stamps a deterministic 0–100 health score onto that org — 100 / (1 + severity-weighted findings per record), the same inputs always producing the same number. Run "fullstackgtm health" any time to see the current score, the change since the last audit, a dated trend, and which rules moved. Scope it per client, and the number climbs as you remediate — a record you can show a stakeholder instead of a vibe.

Who approves the changes — does this create a new inbox for my reps?

No. Plan approval belongs to whoever owns the CRM — usually one RevOps or ops person reviewing a batch, the same way they would review a pull request. Reps only ever see one thing: a proposed next step extracted from their own call, confirmed in one click. No new fields, no queue of patches to triage.

How is this different from CRM cleanup tools like Insycle or DemandTools?

Those are GUI-first apps a human operates. fullstackgtm is CLI- and MCP-first: it is built to sit between AI agents and your CRM, turning anything an agent wants to change into a reviewable, approval-gated plan. It is also the only open-source option in the category.

How does it know the right week to reach out?

Signals. fullstackgtm watches for the week an account changes — a budget-owning hire, a funding round, a reposted role (the first hire fell through) — sorted into weighted buckets, with public job boards (Greenhouse, Lever, Ashby) as the free, no-auth source in the box and funding/company/social brought in by staged ingest. It then scores each account on timing, ICP fit, and whether you have touched it recently, returning a short send / nurture / skip list where every "why now" quotes the real trigger verbatim. Signal capture is read-only — it never writes to your CRM.

Does it send outbound emails or LinkedIn messages?

No. draft writes one opener per high-priority account, grounded in the trigger, but it has no send capability and adds none — the opener becomes a task you approve, then send from your own tool. Like every write, nothing leaves the building until you approve the plan; and before any send the judge can grade itself, checking whether its own "hot" scores actually book more than cold ones. Every LLM step runs on your own key — Anthropic, OpenAI, or any compatible endpoint like a GLM or local Ollama via one base-URL env var.