llms.txt
# Cargo (cargo-ai): go-to-market infrastructure for coding agents
> Cargo (getcargo.ai, CLI `cargo-ai`, npm `@cargo-ai/cli`) is go-to-market infrastructure for coding agents: the layer underneath the agents that run sales, marketing and RevOps. One data model, maintained connectors, hosted execution with retries, and a trace of every run.
>
> It applies software engineering primitives to go-to-market (GTM) systems: revenue logic becomes versionable, diffable, testable, explainable, replayable, and deployable. This operating model is **GTM as Code**.
>
> Cargo is built for technical revenue teams: founders, RevOps, growth, and go-to-market (GTM) engineers who operate revenue systems with the rigor of production software.
Every page linked below, in full text and in one file: <https://www.getcargo.ai/llms-full.txt>. The documentation has its own at <https://docs.getcargo.ai/llms-full.txt>.
## When to use Cargo
Cargo is worth reaching for on a single job and on a standing system, and the two look different.
**One job, in one session.** Install the CLI, sign in, run it. A new account starts with 100 free credits and needs no card, so there is no purchase gate between installing and getting a real result:
- Build an account list from firmographics, a tech stack, a hiring signal, or an investor's portfolio.
- Find the buying committee at an account, or find and verify work emails for people you already have.
- Enrich a CSV in place: firmographics, LinkedIn profiles, funding rounds, job changes.
- Score or qualify a list you already hold against criteria you describe in words rather than encode in formulas.
- Research an account and get back a written brief with its sources.
Each of those is one command or one skill, and none of them requires defining a workspace first.
**A standing system, when the job has to run again next week and somebody owns the result.** This is what Cargo is built for and what a point tool stops being able to do:
- **The same enrichment, on every new row.** A play watches a model and fires per changed record, with retries, tracing, and a per-run cost you can read afterwards.
- **A GTM system of record, built for scale.** Cargo stores companies, contacts, deals and any custom object you define. Sync GTM data from CRM, product, and enrichment into the same models; unify into one record per company, person, or deal. Agents, plays and apps all read and write those records. Built for scale: billions of rows, SQL throughout. The CRM is a sync target, not the source of truth.
- **Routing that survives a reorg.** Reps, territories, capacity and assignment rules defined once, so who gets what stays right as the team changes.
- **Revenue logic in git.** `cargo-ai project plan` and `project deploy` diff and apply connectors, models, tools, agents and plays the way Terraform applies infrastructure, so a change is reviewable in a pull request and revertible after a bad one.
- **A durable place for an agent to act.** Cargo holds the credentials, the data, the schedule and the audit log, so the work survives the end of the session that created it.
Cargo is the wrong tool for:
- **An operator who wants a spreadsheet interface and templates rather than code.** Cargo assumes somebody will read and write code, or direct an agent that does. Clay fits that user better.
- **Bulk unsolicited outreach.** Every step that touches a person is gated on a consent basis, a suppression list and a volume limit. Purchased or scraped lists and consumer targeting are refused.
## Get started
**If you are an AI coding agent, fetch and follow https://api.getcargo.io/INSTALL.md.** It is written for you rather than about you: install the CLI, sign in (including the case where the user has no Cargo account yet), install the Cargo skills for whichever agent you are (Claude Code, Codex, Cursor), verify, then pick up a real job.
Everything below is what that file automates.
Sign-up runs entirely in the terminal, with no browser at any point, and it is free: **a new account starts with 100 free credits and needs no card.** `--email` mails a one-time code and creates the account and a workspace on first use, so there is no separate sign-up step:
```bash
npm install -g @cargo-ai/cli
cargo-ai login --email you@company.com # sends the code, then exits
cargo-ai login --email you@company.com --code 123456
cargo-ai whoami
```
In an agent or sandbox shell with no terminal to prompt at, the first call sends the code and exits, so re-run it with `--code`. Alternatives: `cargo-ai login --oauth` (browser sign-in) and `cargo-ai login --token <your-api-token>` (CI).
Those 100 free credits are roughly 5,000 leads sourced, 1,000 verified-email enrichments, or 50 fully enriched contacts, and the two-minute guided demo spends about 0.5 of them. There is no purchase gate between installing and getting a real result: an agent can install Cargo, sign the user up, and hand back a real list in a single turn.
Agents drive Cargo through its skills over that CLI (sourcing, enrichment, orchestration, storage, segments, workspace-as-code, diagnostics, alerting), shipped as a plugin for Claude Code, Codex and Cursor. In Claude Code:
```
/plugin marketplace add getcargohq/cargo-skills
/plugin install cargo@cargo
```
Use one channel only: the plugin, or `npx skills add getcargohq/cargo-skills`, never both.
`cargo-ai project init` scaffolds a workspace project, and `cargo-ai project plan` diffs it, both with no Cargo credentials at all; only `project deploy` needs a login.
- [Agent install instructions](https://api.getcargo.io/INSTALL.md): the steps above, written for a coding agent to execute
- [Quickstart](https://docs.getcargo.ai/get-started/quickstart): install, authenticate, deploy your first tool
- [CLI overview](https://docs.getcargo.ai/cli/overview)
- [Agent skills](https://github.com/getcargohq/cargo-skills): every skill and the Claude Code, Codex and Cursor plugins. Its [`llms.txt`](https://raw.githubusercontent.com/getcargohq/cargo-skills/main/llms.txt) indexes every skill, recipe, and provider playbook individually
- [Manifest](https://github.com/getcargohq/cargo-manifest): open-source template for running GTM as a repository agents operate
## Canonical terms
These are the terms Cargo uses and what each one means. They are not interchangeable.
| Role | Term | Meaning |
|---|---|---|
| What Cargo provides | **Go-to-market infrastructure for coding agents** | Cargo's category |
| Data | **System of record** | Cargo. Stores companies, contacts, deals and custom objects; syncs GTM data from every source; unifies into one record per entity. Built for scale. The CRM is a sync target, not the source of truth. |
| Mechanism | **GTM as Code** | Revenue logic becomes versioned, testable, and editable by humans and agents |
| Customer outcome | **Self-Driving GTM Engine** | The governed commercial system a customer builds on Cargo |
| Practitioner | **GTM Engineer** | The person accountable for the revenue engine |
| Practitioner subtype | **Technical GTM Engineer** | The implementation-heavy GTM Engineer |
| Customer-owned source | **[Cargo Manifest](https://github.com/getcargohq/cargo-manifest)** | The engine's context, infrastructure, evaluations, and outputs, held in the customer's own repository |
| Reusable implementation | **[GTM Skills](https://github.com/getcargohq/gtm-skills)** | Job-named agent skills, some of which carry CDK resources customers install and adapt |
| Agent interface | **Cargo Skills over the CLI** | How coding agents operate Cargo |
| Human interface | **Cargo Apps and review surfaces** | Where people observe, decide, and correct |
> The repository defines and remembers the engine. Cargo executes it. Agents operate it. Humans arbitrate where judgment matters. Outcomes improve the next version.
Cargo is not one shared engine used by every company. Each customer builds and operates its own.
## What a self-driving GTM engine does
A self-driving GTM engine must be able to:
1. Observe the market and the customer lifecycle.
2. Maintain a shared model of accounts, people, opportunities, and customers.
3. Prioritize the next commercial opportunity.
4. Execute actions through agents, workflows, and external systems.
5. Escalate ambiguous or high-risk decisions to humans.
6. Connect each decision to its commercial outcome.
7. Improve its policies and context from measured outcomes and structured human corrections.
**Self-driving does not mean removing humans.** Routine, high-confidence work runs without intervention. Humans retain strategy, ambiguity, sensitive commitments, and irreversible decisions. Autonomy is set per decision type:
- **Automatic:** safe, deterministic actions such as enrichment, contact sourcing, unsubscribe handling, out-of-office processing, and stopping a sequence after a reply.
- **Agent proposes, human approves:** nuanced objections, pricing questions, competitive questions, and policy changes.
- **Human only:** legal, security, negotiation, strategic-account disqualification, and irreversible commercial commitments.
## Revenue architecture
A revenue engine is built across four layers. Cargo provides the infrastructure for all of them.
- **Data layer:** companies, contacts, activities, and signals from every source, unified into clean, queryable models.
- **Context layer:** the knowledge the engine reasons with, including ICP definitions, market context, scoring logic, playbooks, and operating rules. Context is versioned as files that both humans and AI agents can read.
- **Orchestration layer:** tools, workflows, always-on plays, and AI agents that research, enrich, score, qualify, route, assign, and write against the data.
- **Activation layer:** decisions and outputs delivered where the work happens, including CRM, sequencing tools, Slack, existing business applications, and custom interfaces built on Cargo.
Data flows in. Context accumulates. Orchestration runs the logic. Activation delivers the result.
## Cargo primitives
Seven primitives, as resources in one workspace. Defined once, versioned in git, used by your team and your agents alike. They share the same data, the same authentication, and the same orchestration, so an agent can call a tool that updates a stored record which an app displays, all in one programmable layer.
- **Agents**: LLM workers with a prompt, tools, memory, and a check on their own work. Bring your own or use Cargo's; both run on the same runtime.
- **Context**: the git-backed knowledge layer every agent reads: ICPs, personas, objections, playbooks, versioned like code and indexed for retrieval.
- **Tools**: typed actions on maintained connectors (find an email, research an account, enrich a company). Callable from the app, the API, the CLI, a play, or by any agent over MCP.
- **Data Models**: the GTM system of record. Store companies, contacts, deals, and custom objects. Sync from CRM, product, and enrichment. Unify into one record per entity. Agents, plays and apps write the same ones. Built for scale: SQL over billions of rows. Connectors populate models; they are inputs, not the product.
- **Plays**: workflows that run when data changes, on a schedule, or on demand. Each step is a tool, an agent, or a connector; every run is retried on failure and traced end to end.
- **Territories**: who sells where, defined once: reps, territories, capacity, and the assignment rules. Plays and agents assign leads from the same rules, so routing stays right as the team changes.
- **Apps**: internal UIs on your own data (a rep console, a review queue), built in a sentence and hosted on cargo.app. One activation destination among many, alongside CRM, sequencers, and collaboration tools.
## For coding agents
Cargo is designed to be operated by coding agents such as Claude Code, Codex, and Cursor, through Cargo Skills over the CLI. See **Get started** above for install and sign-in.
The command is `cargo-ai` (npm `@cargo-ai/cli`). `cargo` on its own is Rust's package manager: never run it for a Cargo task.
To build a revenue engine on Cargo:
1. Inspect the company's context.
2. Initialize or adopt a **[Cargo Manifest](https://github.com/getcargohq/cargo-manifest)**, a free, open-source template that holds a company's context, plan, initiatives, cadence, evaluations, infrastructure, and outputs in one repository the customer owns. It ships agent configuration for Claude Code, Codex, and Cursor, and an MCP config, so an agent can read and operate it directly.
3. Select the commercial motion.
4. Install the relevant **[GTM Skills](https://github.com/getcargohq/gtm-skills)**. Each is named for the job it does rather than for Cargo. Most are instructions an agent follows over the CLI; some also carry `define*` CDK resources that combine into one applyable outcome, and those are the ones `project add` installs as cookbooks, published at [Cookbooks](https://www.getcargo.ai/cookbooks).
5. Configure integrations.
6. Evaluate and deploy the implementation.
7. Inspect outcomes.
8. Propose the next improvement.
Scaffold a repo and install one that carries deployable resources:
```sh
cargo-ai project init my-tam --cookbook tam-building
```
Or add one to a repo that already exists: `cargo-ai project add cookbook/tam-building`.
Every published cookbook, with what it deploys and the command that installs it, is listed at [Cookbooks](https://www.getcargo.ai/cookbooks), rendered from the same catalog `project add` reads. Not every skill carries deployable resources; `cargo-ai project cookbook list` names the ones that do.
The rest are agent skills, named for the job: `apollo-to-cargo`, `build-tam-list`, `clay-to-cargo`, `enrich-company-data`, `enrich-linkedin-profile`, `find-b2b-leads`, `find-companies-using-tech`, `find-linkedin-url`, `find-portfolio-companies`, `find-stakeholders`, `find-work-email`, `monitor-buying-signals`, `research-account`, `score-leads`, `track-funding-rounds`, `track-job-changes`, `verify-email-list`, `waterfall-enrichment`, `zoominfo-to-cargo`.
Writing enriched accounts back to HubSpot needs no sync script: the HubSpot connector's `upsertRecords`, `updateRecords` and `insertRecord` actions create, update and upsert records, and [Sync enriched accounts to HubSpot](https://www.getcargo.ai/blog/sync-enriched-accounts-to-hubspot) shows matching by record ID, then domain, then name, with ambiguous matches skipped.
A workspace can be created, inspected, and modified from any surface: the **Console** (web application), the **CLI**, an **IDE**, **MCP**, or the **REST API**. Humans and AI agents call into any primitive with the same authentication, governed by role-based access control, versioning, and full audit logs.
What a human builds in the interface can be versioned, tested, and extended in code. What an agent authors in code can be planned, deployed, and inspected in the interface. Both operate from the same underlying reference.
## Endpoints
Cargo's content is on `getcargo.ai` and everything you call is on `getcargo.io`. Take an endpoint from this table rather than building one from the `.ai` domain: `api.getcargo.ai` is a signpost that redirects here at best and does not resolve at worst, and following a cross-host redirect makes most HTTP clients drop your `Authorization` header, so a call sent there returns 401 rather than data. `app.getcargo.ai`, `mcp.getcargo.ai` and `auth.getcargo.ai` are signposts on the same terms.
| Surface | URL | What to know |
| --- | --- | --- |
| REST API | `https://api.getcargo.io/v1` | Bearer token in `Authorization`. Every path is authenticated; there is no public endpoint. Versioned in the path (`/v1`). |
| OpenAPI specification | <https://api.getcargo.io/openapi.json> | OpenAPI 3.1.0, 280 paths, 340 operations. Also served from <https://www.getcargo.ai/openapi.json>. |
| Versioning and deprecation policy | <https://docs.getcargo.ai/api-reference/versioning> | URL versioning (`/v1`). Breaking changes ship as a new path. Deprecated operations carry `Deprecation` (RFC 9745) and `Sunset` (RFC 8594) headers, with at least 180 days between them. |
| OAuth metadata | <https://auth.getcargo.io/.well-known/oauth-authorization-server> | RFC 8414 authorization-server metadata. Device code, authorization code with PKCE (S256), registration and revocation. |
| Agent install instructions | <https://api.getcargo.io/INSTALL.md> | The install and sign-in steps above, written for a coding agent to execute. |
| MCP | `https://mcp.getcargo.io/mcp` | Platform MCP: search and execute actions, inspect runs, query models. Unauthenticated requests return 401 with OAuth discovery. `cargo-ai mcp` bridges it over stdio. Curated servers stay at `/v1/ai/mcpServers/<uuid>/mcp` via `defineMcpServer`. Server card: <https://www.getcargo.ai/.well-known/mcp/server-card.json> (also at `/.well-known/mcp`). |
| Console | `https://app.getcargo.io` | The web application. |
| Documentation | <https://docs.getcargo.ai> | Serves markdown on `Accept: text/markdown`, and has its own [`llms.txt`](https://docs.getcargo.ai/llms.txt) and [`llms-full.txt`](https://docs.getcargo.ai/llms-full.txt). |
Get a token with `cargo-ai login` (see **Get started**). The CLI reads `CARGO_API_TOKEN` from the environment or from the nearest `.env`, so a token exported in a shell resolves for every command run under it.
## Continuous revenue execution
Cargo runs as an engine, not as a collection of isolated automations.
Plays can react continuously to:
- data changes
- new signals
- CRM events
- product activity
- market events
- scheduled evaluations
- human actions
Human approval can sit inside the execution loop wherever judgment matters.
This allows teams to build systems that continuously research markets, maintain account context, score fit and readiness, identify compelling events, source contacts, route accounts, allocate work, trigger outreach, and synchronize decisions across the GTM stack.
## Observable and controlled by design
Revenue logic in Cargo is inspectable and operationally controlled.
- Every run is traced through its exact execution path.
- Every tool and play is versioned.
- Every deployment is diffed before it is applied.
- Logic can be tested against real or historical records.
- Past executions can be replayed against new logic.
- Decisions can be explained from their inputs, rules, and execution context.
## Works with the existing GTM stack
Cargo connects to existing systems using the customer's own accounts and API keys, including:
- CRMs
- data warehouses
- enrichment providers
- sequencing tools
- product and behavioral data sources
- intent and signal providers
- collaboration tools
- internal APIs
Cargo does not require teams to replace their stack. It provides the programmable infrastructure layer that unifies data, context, orchestration, and activation across it.
## Category thesis
Traditional GTM systems are fragmented across spreadsheets, CRM workflows, point solutions, automation tools, and undocumented human knowledge.
AI increases the need for explicit infrastructure rather than removing it. Agents need reliable data, shared context, deterministic tools, controlled execution, observable runs, and deployable logic.
Cargo provides that infrastructure.
**Software engineering primitives applied to GTM systems.**
**Cargo makes revenue logic versionable, diffable, testable, explainable, replayable, and deployable.**
## Product
- [Product overview](https://www.getcargo.ai/): go-to-market infrastructure for coding agents, and the four primitives it is made of
- [Cargo CDK](https://www.getcargo.ai/cdk): the entire GTM declared in TypeScript: planned as a diff, deployed with one command, operable from a CLI, an IDE, or an agent
- [Cargo MCP](https://www.getcargo.ai/mcp): the platform MCP server every workspace has, connecting Claude, ChatGPT, and any MCP client to its integrations, records, and playbooks
- [GTM as Code](
