Concepts

The mental model behind Sales as Code. Read this once and the rest of the docs make sense without backtracking.

The unit is a job, not a tool

A founder still doing their own selling is not short of tools. They are short of people: prospecting, deals, technical proof, customers, partners, support, enablement and the numbers are all owed work every week, by one person. So the unit here is the job. Each of the 9 roles is a package of skills and scheduled tasks for one of those jobs, and each one runs whether or not you open anything.

• gtmcron (Founder / GTM operator): Your go-to-market, on cron.
• salescron (Enterprise account executive): Your sales day, on cron.
• leadercron (Sales leader): Your sales org, on cron.
• secronjob (Sales engineer): The SE’s day, on cron.
• partnercron (Partner / channel manager): Your partner motion, on cron.
• bdrcron (BDR / inside sales rep): Your pipeline day, on cron.
• crocronjob (Chief revenue officer): The revenue org, on cron.
• cscron (Customer success manager): Your post-sale motion, on cron.
• supportcron (Customer support lead): Your support queue, on cron.

One account holds whichever roles you have. Hold all 9 and they feed each other: what one role learns about an account is what the next one reads. A sales leader running a team instead takes leadercron for themselves and seats for their people through Team on Cron, on one login.

How it runs

There is nothing to install and no laptop to leave open. The work happens on our servers on the schedule you set, and the site you are reading is where you watch it and approve what leaves.

• On a clock. Each role you hold takes its own scheduled pass. The dispatcher fires at fixed times and nothing else, so a run happening is not a thing you trigger.
• Reading what you connected. You authorize a CRM, an inbox, a calendar once. We custody each token encrypted and read it only on your schedule.
• Writing drafts, not messages. Every result is draft-first, and lands where you chose: the in-app queue, a Drive folder, or a mailbox draft.
• Recorded. What each run did, what it produced and what it cost is on Activity, per role and week over week.

One page, 4 blocks

9 roles running daily checks produce far more than any one person can act on. If each reported into its own console you would have 9 places to look and no answer to the only question you wake up with, which is what to do first. Home answers it: every role reports in, and the page ranks across all of them.

• Waiting on you. Commitments you owe, aged. Never capped.
• The line. Ranked by what moves revenue, capped at what fits before your first call.
• The standup. One sentence per role, including the quiet ones.
• Close the day. An end, so tomorrow’s order learns from today’s.

The order is arithmetic you can read and disagree with, not a model: how close an item sits to a real conversation with a person, whether the role raised it today or this week, how long it has waited, and how quick it is to clear. Deal size nudges, capped. Each standup row also says how much that role held back, because restraint you cannot see reads as a role that did nothing. How to read it: Home.

The gate

Nothing reaches a customer without you. A draft is refused at the send layer until a signed-in person approves that exact draft, and no scheduled path, agent or automation in the product can do the approving. That is a check in the code, not a setting to remember.

Sending is off on a new account and stays off until you turn it on. With it off, an approved draft is recorded as held rather than sent, so you can run the whole thing for a month and read what it would have said. The drafts waiting on you sit in the dispatch queue.

gtmcron's plugins

One thing on this page is not about the 9 roles. gtmcron also sells as eight separate plugins, which is how the whole product was sold before the roles were. Nothing was withdrawn: what people bought, they keep, and the plugins remain purchasable at /plugins. If you arrived after 2026, you can skip this section; a gtmcron subscription and the Founder plan both include all eight.

Each plugin is one company function. Their internal labels (Operator, Closer, Writer, Researcher, Event) are gtmcron's own axis and a narrower one than the 9 roles above, which are the jobs a company has. Company OS Core is required when buying plugins singly, because every other plugin reads your company, offer, ICP and voice from it.

• Company OS Core (Operator): the front door. Scaffolds your Company OS, decision log, role map, and weekly operating review. Required by all others.
• GTM Engine (Closer): trigger-driven prospecting, daily standup, a self-tuning funnel, and deal-closing help. Drafts only; never sends on its own.
• Content Engine (Writer): the 10-agent Content Studio: research, draft in your voice, publish across channels, measure signups.
• Founder Chief-of-Staff (Operator): morning brief, meeting prep, monthly investor/board update from your calendar, inbox, and business.
• Launch Readiness Audit (Operator): a complete pre-launch audit of your repo and site (code, payments, security, SEO/GEO/AEO, ops) with a prioritized fix list and a remediation prompt. Read-only.
• Inbound & Lifecycle (Closer): triage replies, route hot interest, nurture signups through lifecycle stages. Pairs with GTM Engine.
• Market Intelligence (Researcher): weekly competitive sweep, daily community scan, drafted replies where it helps.
• Launch Kit (Event): launch prep and launch-day ops (assets, positioning, timeline, comment templates).

Each has its own feature doc, and the set is listed together on the gtmcron page. Every other role licenses as one thing, with no per-plugin picker.

Plans & entitlements

Two ways to buy, and one mechanism underneath. What you buy grants an entitlement, a permission each skill checks before it runs, so an unlicensed role stops and points you at /pricing rather than half-running.

• The Founder plan, $990 a year for all 9 roles. The shape for someone doing their own selling.
• A single role, its own yearly subscription. Each role page under the library carries its price.
• Team on Cron, one yearly subscription covering an owner plus seats for their people, managed in Team admin.
• The legacy gtmcron paths, still purchasable: plugins one at a time, the Full Suite, or the All-Access membership. Company OS Core is added to your cart automatically if you buy a plugin without it.

The MCP contract

Skills talk to this site through one MCP server at /api/v1/mcp. Every skill follows the same shape: verify and entitle first, report last. You never call these yourself; they are here because they explain what shows up on Activity and what does not.

• verify_session: confirm a real, licensed account. Every skill calls it first and stops if it errors.
• check_entitlement: is this account licensed for what is about to run?
• pull_config: read your plan and flags so the skill can adapt at run start.
• emit_telemetry: record the run (role, skill, counts, outcome, duration). Metadata only.
• sync_brain: push brain state for a scope. No raw contact PII by default.

The last two are what turn a scheduled run into something you can read. Driving the same endpoint from your own tooling is the optional path in API keys & MCP.

The brain, and why it compounds

The brain is the durable memory of your go-to-market, and it starts with the business record you write at setup: what you sell, who to, and how you talk. Every role reads that before it writes a word. On top of it each role keeps a scope of its own (outbound its signal weights and funnel, content its voice model and what has published, deals its qualification state) and syncs that scope on every run. Empty on day one, sharper every week, because each outcome feeds the next run.

Generic prompts don't get sharper. A brain that learns from your runs does, and because it lives in a shared scope, every role sees it.

Learning from losses

The brain learns most from losses. Mark a deal closed-lost and the GTM Engine prompts for a structured postmortem (symptom · root cause · what you'd do differently), stored as a dated entry in the sales-craft playbook. The next time an open deal shows the same early signals, that prevention rule fires. Here's a representative entry, anonymized, but the rule and the integration are exactly the shape that ships:

The playbook brain carries dated loss postmortems, win patterns, anti-patterns, and objection branches, all read by the roles that coach. Every loss adds one. Every win adds one.

Content Studio

A 10-agent pipeline: Scout, Strategist, Writer, Media, Formatter/SEO, Repurposer, Compliance, Publisher, Community/Engagement, Orchestrator. It researches trends, drafts in your voice, cuts video, checks brand safety, and stages everything for you at /studio. It then drafts replies to comments and attributes signups back to the piece that drove them.

Publishing to a channel you own is a separate lane from the gate above, and worth stating plainly because the two are easy to confuse. A message to a customer is refused at the send layer until you approve that exact draft. A post to your own channel runs at the mode you set for that channel: Draft then approve, Assisted (it prepares the link, you submit), or Automated (it publishes after the compliance check). A compliance violation holds the piece for review in every mode. Full detail on the Content Studio page.

Integrations: you connect, we custody

You connect your tools once, at Settings, Connect. We custody each token encrypted and read it on the schedule to do the work: Gmail, Google Calendar, Drive, Slack, Apollo, Attio, Clay, Zoom, and any other MCP server you configure. Tokens are encrypted at rest, never sold, never used to train, and revocable at any time.

• What to connect. A CRM, an email tool, a calendar, and whatever prospecting, enrichment or chat tool the roles you hold read. The wizard maps each category to what you authorized, and a role whose category is unconnected says so rather than running blind.
• What we process. The work runs on our servers, so we read the connected data to do it. What is stored is run metadata (which skill ran, when, counts, outcome) plus brain state. Raw contact data is not stored by default. The privacy policy is the exact contract.
• Coverage gaps. A tool with no first-party connector is still reachable through any MCP server you configure.

Supported tools: reference

The roles are tool-agnostic: each reads whatever category of tool you point it at (a CRM, a sequencer, a data warehouse). This table is the reference for the tools we have working knowledge of and the tier of each connector.

The tier column describes the connector's status:

• GA: the connector's API path is verified; it works for any account with credentials.
• Preview: the connector is built but the vendor API path is unverified. The OAuth handshake works; events may or may not flow until we confirm against a live tenant.
• Partner-gated: the vendor requires a partner-program approval step before any data flows. Connect is disabled until you're approved; the UI links the application.

How to connect, in one line: add the tool's connector in Settings and complete the OAuth handshake; the wizard maps the category to what you connected. What we process: the work runs on our servers, so we read the connected data; only run metadata and brain state are stored, never raw contact data by default.

Conversation intelligence is covered by Gong, Clari, and Zoom. Chorus and Avoma are not built as first-party connectors; use any MCP server you configure if you need them, and tell us if it's a gap worth closing.

Activity

Everything your roles report (the emit_telemetry and sync_brain calls) lands on Activity: runs and actions week over week, top outcomes, whether each thing you own is running (Healthy / Failed / Not started), the newest runs, and the latest brain state per scope. It's read-only by design: the work runs on our servers on a schedule; Activity is how you see it without leaving a tab open. Managers get the team-level version at /team-admin/rollup. How to read it: Activity.