Capture Every Sales Call into Your Go-to-Market Repo

To capture every sales call into your go-to-market repo, deploy Cargo’s call-capture cookbook: one Claude Code agent that, every morning at 07:00 UTC, collects your recorded calls, writes one log entry per call, and promotes a claim into context/ only once two independent calls back it. It all lands as one pull request a human reviews. The agent never merges it, emails anyone or writes to a CRM.

What the cookbook deploys, from its code in getcargohq/gtm-skills on 2026-10-16: 4 resources (one agent, two connectors, one folder) plus a collector script with 9 call recorder adapters, one daily cron, and a cap of 12 calls written up per run.

The problem, and the answer #

What a team learns on calls usually stays in a recording nobody reopens, so the same objection gets relearned every quarter. The answer is to treat calls as a sensor: a fixed script pulls the transcripts, an agent writes them up as markdown in the repository every other agent already reads, and a claim only becomes company knowledge when it repeats.

How it works, end to end #

1. The cron fires at 07:00 UTC (0 7 * * *), after the recorder has finished processing yesterday’s calls.
2. The agent clones your repository. It is a Claude Code harness agent, so its working tree is the go-to-market repo itself. Which repository it clones is resolved from your checkout’s git origin at deploy.
3. It runs the collector, scripts/call-capture/collect/calls.ts. The script pulls every call in a three-day rolling window whose transcript is ready, drops calls with only internal attendees, and writes one raw file per call into cadence/log/raw/calls/. No language model is involved in this step, and the agent is told not to fetch calls itself or edit the script.
4. It writes up each pending call as cadence/log/calls/<date>-<account>.md: what was said, then Objections, Competitors mentioned, Buying or expansion signals and Product asks, then the actions as checkboxes. A call is pending when its recorder id appears in no entry yet, so one call gets one entry, ever.
5. It caps the run at 12 calls: every pending call from the last 30 days first, newest first, then the oldest pending calls, so a backlog drains without delaying this week’s follow-ups. An action older than 30 days is prefixed STALE-CHECK, because a backfilled commitment is a question, not a task.
6. It promotes what repeats. A claim reaches context/ only on its second independent occurrence (two accounts, or one account on two calls), and the context file cites both log entries.
7. It opens one pull request, titled [call-capture] scribe <date>, whose body states four numbers: calls captured, written up fresh, written up from the backlog, and still pending. If nothing was captured and nothing was pending, it opens nothing.

After a human merges, the next cargo-ai project deploy syncs context/ into the workspace, where your other agents read it.

The recorders it reads #

Nine recorder adapters ship, and you pick one with a typed constant, RECORDER in scripts/call-capture/collect/config.ts. A name that is not one of the nine fails the typecheck.

The eight unverified adapters say so on every run. Check yours before deploying: running the collector script with --recorder=<slug> --dry-run lists the calls it would capture and writes nothing. A recorder that does not ship is one new adapter file plus one entry in the registry.

What it needs and what it costs #

• A go-to-market repository with context/ and cadence/ at its root, the shape cargo-ai project init scaffolds.
• A GitHub connector, the agent’s only write path: clone, branch, push, pull request.
• An Anthropic connector, the model the agent runs on.
• Your recorder’s API key as a workspace environment variable, not a file: cargo-ai workspaceManagement envVar create --key CALL_RECORDER_API_KEY --secret. With no --value, the CLI reads it from the environment variable of the same name.
• Your email domain in INTERNAL_DOMAIN, or every internal standup is captured as a customer call.
• @cargo-ai/cli 1.0.89 or later and @cargo-ai/cdk 1.0.67 or later.

The cookbook calls no connector action, so it spends no per-record credits. The recurring cost is the daily agent run, billed as language model tokens through your Anthropic connector, and the 12-call cap is the cost control as much as the review control. The collector talks to your recorder directly, so your recorder plan’s API limits apply.

What it will not do #

• Contact a customer, send email or Slack messages, or write to a CRM.
• Merge its own pull request or push to the default branch.
• Edit or delete a raw capture or an existing log entry.
• Touch plan/ or infra/.
• Write a one-off claim into context/.
• Summarize one call right now. That is a read against your recorder’s own API and needs nothing deployed.

The cookbook is marked to-be-approved: its acceptance test has not yet been run end to end against a live workspace, so review cargo-ai project plan before you deploy.

Deploy it #

npm install -g @cargo-ai/cli
cargo-ai login --email you@company.com
cargo-ai project add cookbook/call-capture
cargo-ai project plan
cargo-ai project deploy

Signing up from the CLI needs no browser and no card, and comes with 100 free credits. Run project add inside your go-to-market project; with no project yet, cargo-ai project init <dir> --cookbook call-capture scaffolds one with the cookbook in it. The call-capture cookbook page has the full file list and the placeholders to edit before deploying.

Once calls land in the log, track the next steps promised on them, and prep the next meeting from the calendar with what the last one said.

Frequently asked questions #