Drafting an email through DimeBox means writing a brief, not a prompt in the usual sense — purpose, optionally tone and key_points, and nothing else. There's no system prompt to tune and no temperature to set. That's a narrower surface than working with a model directly, which means the few fields you do control matter more than they would otherwise.
purpose is required and capped at 2000 characters, which is generous for a one-line brief and tight for a full transcript. The failure mode at one extreme is a purpose so vague ("follow up") that the draft comes back generic and has to be regenerated; at the other, a purpose stuffed with everything that might be relevant, which tends to produce a draft that reads like a summary of a summary. The reliable middle is a purpose that states the single goal of the email in a sentence, and leaves supporting detail to key_points instead of burying it in the same field.
key_points is an array for a reason — each item should be one fact or instruction the draft needs to include, not a paragraph of context dumped into a single string:
{
"recipient": "[email protected]",
"purpose": "confirm the renewal date moved",
"tone": "friendly but concise",
"key_points": ["new renewal date is March 3rd", "price is unchanged", "no action needed from them"]
}Three short, distinct facts produce a more predictable draft than one long sentence trying to say the same thing. See tone, key points, and purpose for a closer look at what each field actually changes in the output, and the anatomy of a drafting call for the full request/response shape these fields sit inside.
tone is optional and freeform — there's no fixed enum of allowed values, just a short description like "friendly but concise" or "formal, no contractions". Treat it the way you'd treat any other instruction to a model: specific and short descriptions land more consistently than vague ones. "Professional" alone leaves more room for drift across calls than "direct, no small talk, one short paragraph."
If any part of a brief — especially key_points or purpose — is being constructed from content an agent read somewhere else, such as an inbound email it's replying to, that content needs the same scrutiny you'd give any other untrusted input before it goes into a prompt. Prompt injection via email covers the specific risk of a reply brief built directly from message content someone else wrote. The practical rule: extract facts, don't forward instructions.
No amount of brief-tuning substitutes for picking the right request shape in the first place. If exact wording matters — a legal notice, a price quote, anything that needs to say precisely one thing — that's a job for raw mode, not a very tightly worded purpose. See drafted vs raw email for that decision, and disabling AI drafting for enforcing it at the inbox level instead of trusting every caller to choose correctly.
Each drafting call costs money, so iterating on a brief by trial and error against the live endpoint adds up. A cheaper loop: draft against /api/emails/generate while tuning a brief template for a new use case, confirm the output is consistent across a few variations, then wire the finalized brief shape into whatever calls send in production. Doing that iteration on Base Sepolia instead of mainnet means the iteration itself costs nothing real.
purpose like "follow up" gives the draft almost nothing to work with beyond guessing at context."purpose": "politely but firmly ask for payment" mixes intent and register into one field instead of splitting purpose and tone cleanly.key_points array that just repeats the goal in different words adds no new information for the draft to include.purpose pushing toward 2000 characters is usually a sign that supporting detail belongs in key_points instead of being crammed into one field.Because /api/emails/generate is a separate, cheaper way to get the same drafting behavior without an inbox or a send attached, it doubles as a way to sanity-check a brief template in isolation — confirm the tone lands right, confirm the key points all show up, before wiring that exact brief shape into a live send call against a real inbox.
If an agent sends the same kind of email repeatedly — a weekly status update, a recurring reminder — treat the brief shape itself as a template worth versioning in your own code, the same way you'd version a prompt used elsewhere. A brief that's been tuned to reliably produce the right tone and length for one use case is worth keeping stable rather than regenerating by hand each time; see tone, key points, and purpose for the field-by-field detail behind building that template well.