"Follow up in three days if they don't reply" is one of the most mechanical tasks in sales, and one of the most commonly dropped. An agent built for this doesn't need to be clever — it needs an inbox, a way to check whether a reply has arrived, and a way to draft and send a follow-up when one hasn't. The interesting part is less the prompt and more the loop around it.
A minimal follow-up agent looks like this, run on a schedule:
GET /api/inboxes/{slug}/messages) and check whether the prospect replied since the last outbound message.purpose: "follow up on our previous email, no response yet", with key_points pulled from whatever context the agent is tracking about that lead.Building a cron-triggered agent that checks its own inbox covers the scheduling half of this in more detail; adding email to an autonomous agent loop covers where this step fits inside a larger agent that's doing more than just email.
A follow-up brief doesn't need the entire email thread pasted into purpose — it needs the two or three facts that matter: what was originally offered, what's still outstanding, and whether anything has changed since. Stuffing a full thread history into key_points tends to produce a drafted email that reads like a transcript, not a message. See designing prompts for reliable AI-drafted email and tone, key points, and purpose for how to keep a brief tight without losing the context that actually matters.
The easiest way to build a follow-up agent that annoys people is to never give it a reason to stop. A reply from the prospect is one stopping condition; a fixed number of attempts is another. Neither requires anything beyond reading the inbox's message list and counting — there's no need to run sentiment analysis on a reply to know that a reply happened at all.
Every follow-up sent this way is a $0.01 send call, and every check of the inbox's history is free (it's a GET against the read token, no payment involved). Running this loop across a hundred leads, checked daily, costs whatever fraction of them actually need a follow-up sent that day — not a flat per-seat fee for the agent sitting idle on the days nobody needs one. Budgeting for a fleet of autonomous agents that pay their own way covers how that adds up once it's not just one sales agent but many.
If the scheduling and the reply-check ever drift apart — a cron job that fires more often than intended, or a bug that double-counts "no reply yet" — the result is a prospect getting the same follow-up twice in one day. Guard against this with an idempotency check in your own scheduling logic (has a follow-up already gone out for this lead today?) rather than assuming the send endpoint will catch a duplicate for you; it doesn't know what "duplicate" means for your sales process, only what it was told to send.
For the inbox fundamentals this pattern builds on — provisioning, read tokens, and message history — see what an agent inbox actually is and the inbox reference.
A simple cadence — day 3, day 7, day 14 — maps directly to three different purpose values against the same lead, each slightly more direct than the last:
// Day 3
{ "purpose": "gentle follow up, no response yet, keep it brief", "key_points": ["original offer still stands"] }
// Day 7
{ "purpose": "second follow up, be more direct about next steps", "key_points": ["ask if timing has changed", "offer a shorter call instead of email"] }
// Day 14
{ "purpose": "final follow up before closing this lead out", "key_points": ["make clear this is the last check-in", "leave the door open for later"] }Nothing about the API changes between these calls — it's the same send route, the same price, with a brief that reflects where the lead actually is in the cadence. The cadence logic (which touch is next, whether to skip one) belongs entirely in your own scheduling code, not in anything DimeBox tracks on your behalf.
A send that reaches failed status — checked via the message list — is a signal worth feeding back into the cadence, not retrying blindly. A fixed number of consecutive failures to the same address is a reasonable point to stop the cadence for that lead entirely rather than continuing to pay for sends that aren't landing anywhere.
None of this requires replacing a human seller — it's squarely a tool for the mechanical part of the job, the follow-up that's easy to forget precisely because it's routine. A reasonable middle ground is routing anything beyond the scripted cadence — a reply with a real question, an objection, anything that isn't silence — to a human, and keeping the agent's job strictly to "send the next scheduled touch if nothing came back." Agentic commerce 101 covers the broader shift this kind of agent is part of, where software increasingly pays its own way through a workflow instead of needing a subscription or a seat.