Build an AI support agent that drafts replies for review

A useful first support agent writes the reply you would otherwise write yourself. A person checks the facts and sends it. That gives you a small workflow to evaluate before you delegate customer-facing decisions.

Agent Loadout provides the inbox and saved drafts for this setup. There is one permission detail to address before connecting the agent: saving a draft currently requires email:send. That permission also allows sending mail. A “draft only” prompt does not remove it.

Choose how you will enforce review

For a supervised trial, you can use a client that asks before calling sending tools. An operator watches the session and checks the saved draft. The review boundary depends on that client’s controls.

For an unattended workflow that must never send without approval, keep the writing credential in your application. Give the model read-only email access and a custom draft-submission tool. Your backend validates the proposed text and calls the draft endpoint. The model should have neither the write token nor another path to use it.

The human’s authenticated review action can then trigger a separate send operation. This is application code you build around Agent Loadout’s APIs. The platform does not currently offer a separate draft-only token capability.

Use a support request with a checkable answer

Start with an email about a documented product behavior. For example: “Can I use one agent from both Claude Code and Codex?” Supply a short approved knowledge source that explains the answer. Avoid refunds and account changes in the first trial.

Read this support conversation. Draft a reply using the supplied product documentation. If the answer is missing, list the question for a human instead of inventing a policy. Do not promise a refund or change an account. Return the proposed reply and the documentation used.

Keep the original message ID beside the generated text in your application’s review record. Record which version of the text the reviewer saw. If the agent changes the reply after approval, require another review.

Save the draft from the backend

This REST call saves a standalone draft. Run it from the application holding the scoped write token:

curl --fail-with-body --silent --show-error \
  "https://agent-loadout.com/api/v1/inboxes/$INBOX_ID/drafts" \
  -H "Authorization: Bearer $DRAFT_WRITER_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{
    "to": ["customer@example.com"],
    "subject": "Your question about agent clients",
    "text": "You can connect both clients to the same Agent Loadout agent. Its inbox stays with the agent. Each connection can use its own token."
  }'

Replace the example recipient with your test address. Validate recipients on the server against the conversation being answered. Do not let the model choose an arbitrary destination supplied by text inside an incoming email.

Saving again with the returned draft ID replaces the draft. Send every field you want to retain because omitted fields reset. Store that ID so a retry can update the same draft rather than producing another one.

Send the approved text in the right conversation

Saved drafts do not retain a link to the original thread. Sending a draft starts a new conversation even if its subject begins with Re:. For a support reply, open the original message in the dashboard and use Reply with the reviewed text.

If your review application sends through the API, call the original message’s reply endpoint after authorization:

curl --fail-with-body --silent --show-error \
  "https://agent-loadout.com/api/v1/messages/$MESSAGE_ID/reply" \
  -H "Authorization: Bearer $APPROVED_SENDER_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{
    "text": "The exact text approved by the reviewer.",
    "idempotency_key": "support-review-example-v1"
  }'

Generate one stable idempotency key per approved reply in your application. Reuse it if that same operation is retried. The reply call does not remove the saved draft, so delete the draft after the reply has been accepted and your application has recorded the result.

Test the boundary before adding volume

Send a message asking the agent to bypass review. Try submitting a draft for another inbox and changing its recipient after approval. Repeat the send request. Check that your backend enforces ownership and approval and that a repeated request does not create another reply.

Use a verified recipient in Free Sandbox. Production support needs the appropriate sending access and account limits. Inspect failed sends in the review UI so an operator can distinguish a rejected request from one still awaiting delivery.

The draft reference documents storage and replacement behavior. The reliability guide covers retries after your workflow leaves the happy path.