Your GTM belongs in gitRegister
Blog

Agentic Email Conversations With Leads From a Mailbox You Own

16 Oct
6min read

To let an agent hold email conversations with leads, give it one mailbox your workspace owns, lock every send to that mailbox, and wake the same chat when the lead replies or unsubscribes, plus once a day to check a quiet thread: it answers on the thread, sends at most one follow-up to silence, and stops on a no. The agentic engagement cookbook declares that for a go-to-market team on Cargo: a sending domain, a mailbox, and one agent with a native email trigger and a heartbeat.

Be clear about what this is. It is the loop after a first email, for leads who are already in a conversation with you. It is not a sequencer, it does not blast a list, and it will not send a second unanswered email. If you need cadences across a list, keep the sequencer you have; Cargo connects to it.

How it works, end to end #

  1. A domain and a mailbox. defineDomain adopts a sending domain the workspace already bought in the Cargo app (adopt: true). defineMailbox creates the From inbox on it, under a real person’s name. Domain, username and type are create-only: changing one destroys the inbox and starts a new one at the bottom of the ramp.
  2. The first send is yours. A person asks the agent to start a thread in a chat, or a play calls the agent with a lead. The agent sends with the native sendEmail action, whose mailboxUuid is locked in the action config, so every send comes from that inbox.
  3. Replies wake the same chat. A native email trigger with kinds: ["replied", "unsubscribed"] starts a new turn in the chat that sent the email. Opens and clicks are left out on purpose: a tracking pixel is not a reason to write. Inbound mail from someone the agent never emailed does not open a chat.
  4. Silence gets one status check a day. A heartbeat (intervalMinutes: 1440, at most 16 messages per chat) re-wakes a thread still at sent. The agent calls listEmailEvents to read the thread’s real status, sends at most one follow-up, and after that the conversation is over.
  5. Each wake sends at most once. Before writing, the agent reads the workspace context so it only claims what you have written down, and checks status, basis, suppression and relevance. A reply carries inReplyTo and the full references chain, oldest first, so mail clients keep it in one thread. An unsubscribe, a bounce, “not interested” or a request for a human ends the loop.

The mailbox: cost, ramp and the gates in the send path #

These are the numbers in Cargo’s code as of October 2026.

ItemValue
Google mailbox125 credits a month, for as long as it exists
Shared or private SMTP mailbox100 credits a month
Each send (sendEmail)0.1 credits
Send ramp5 a day at the start, rising linearly to 40 a day over 45 days of warm-up
Allowance windowRolling 24 hours, counting delivered mail only

A mailbox bills monthly until you remove it; there is no pause. Registering a new domain instead of adopting one is a separate, non-refundable charge. Read the live figures before you deploy: cargo-ai mailboxManagement pricing get.

The ramp only climbs once warm-up starts, which is a CLI call after deploy: cargo-ai mailboxManagement mailbox start-warmup <uuid>. A mailbox that never starts warm-up stays at 5 real sends a day. mailbox get-send-allowance <uuid> reports dailyLimit, sentCount and remainingCount; a send past the limit is refused with dailyLimitReached, not queued. The ramp is a ceiling, not a target.

What the send path enforces, in code:

  • Suppression is checked on every send. Addresses are normalized, matched against the workspace-wide suppression list, and a match is refused as recipientSuppressed.
  • Every email carries a signed List-Unsubscribe link. Using it writes a suppression row, so the next send to that address is refused. There is no command to remove a suppression.
  • An inactive mailbox does not send (mailboxNotActive).

What the code does not decide for you is your basis for writing to someone. The agent’s prompt requires one (they replied, they asked, a person asked it to start the thread), but a lawful basis and a relevant reason are yours to have before the first send.

Run it #

shellscript
npm install -g @cargo-ai/cli
cargo-ai login --email you@company.com      # emailed code, no browser, 100 free credits, no card

cargo-ai project cookbook view agentic-engagement
cargo-ai project add cookbook/agentic-engagement    # from your Cargo project's root

Set the sending domain (infra/domains/outreach.ts), the mailbox’s real first name, last name and username (infra/mailboxes/rep.ts) and the agent’s languageModel. Then:

shellscript
cargo-ai mailboxManagement pricing get        # say the monthly figure out loud before the next step
cargo-ai project plan                          # a "+ create mailbox" line is that monthly charge
cargo-ai project deploy
cargo-ai mailboxManagement mailbox refresh-status <uuid>     # until "active"
cargo-ai mailboxManagement mailbox start-warmup <uuid>

Then send one thread to yourself, reply to it, and check that the agent answers on the same thread without being prompted. Treat every send as live, which is why the first one goes to you.

What it will not do #

  • It does not send a list, run a cadence or send a second unanswered follow-up.
  • It does not start a first send from a trigger or a heartbeat.
  • It does not start warm-up, write to a CRM or manage DNS by default.
  • It does not send from any mailbox but the one locked on the action, or to a suppressed address.
  • It does not use Outlook mailboxes: that transport has not shipped.

The cookbook is marked to-be-approved: not yet deploy-verified against a live workspace. Treat its acceptance list as the test, starting with the test thread to yourself. If you would rather a person approves every reply, answering positive replies with agents describes that loop, and AI SDR alternatives compares the products that send for you.

Frequently asked questions #

AurelienOct 16, 2026

Give your agents a runtime

Bring the agents you have.Start free, deploy in one command.