Guide

Build a Returns and RMA Email Agent

An AI agent reads return requests, classifies the reason, issues an RMA number for valid ones, and routes exceptions to a human — no refund power of its own.

Written by Pouya Sanooei Software Engineer

Verified — CLI 3.1.20 · Nylas managed · last tested June 14, 2026

What is a returns and RMA agent?

A returns and RMA agent turns a customer's “I want to send this back” email into a tracked return authorization. It reads the request, works out why the item is coming back, checks whether it's eligible under your policy, and issues a return merchandise authorization (RMA) number with shipping instructions.

The slow part of returns is this triage. The agent classifies each request in roughly 1 to 2 seconds the moment the email lands, instead of two days later.

Returns flow: read the request, classify the reason and check eligibility, then issue an RMA number for valid returns or route exceptions to a humanReturn requestemail listReason +eligibilityValid: issue RMAException: route human

The agent authorizes the return; it never issues the refund. The RMA gets the item moving back to you, and a human refunds after the warehouse confirms what arrived and its condition. Keeping the refund outside the agent's tool set means a request can't talk it into paying out for an item that was never sent back.

Why run returns on an agent account?

Return requests belong in their own inbox so they don't drown in general support mail. On an agent account, returns@yourstore.nylas.email is the single channel for every request, each RMA carrying a clean audit trail from request to authorization. You can run up to 5 such inboxes on the free tier, one per store or region.

A dedicated inbox also keeps the agent's reach small. It reads only return threads, so a crafted request can't reach anything else, and the agent does nothing but process returns. A shared support mailbox would give an autonomous responder far more surface than a returns desk needs.

How does the agent classify a return request?

The agent reads each request and sorts it on two axes: the reason (defective, wrong item shipped, changed mind) and eligibility against your policy (within the 30-day window, not a final-sale item, proof of purchase present). A model maps the customer's free text to those structured fields in 1 to 2 seconds, and the policy check is plain code.

# Pull new return requests for the agent to classify
nylas email list --unread --json

Reason matters because it changes the outcome: a defective item ships back free, a changed-mind return may carry a restocking fee. Contacting the customer about the return relies on a lawful basis under the GDPR (Article 6), and the request text is untrusted input the model classifies, never an instruction it obeys.

How does it issue an RMA or escalate?

A valid, in-policy return gets an RMA number and instructions; everything else goes to a human. The nylas email send command emails the customer the RMA number, the return address, and the steps, so they can ship the item the same day. The agent generates one RMA per authorized return and records it against the order.

# Email the customer their RMA number and return instructions
nylas email send \
  --to customer@example.com \
  --subject "Your return is approved — RMA-58120" \
  --body "Ship to: Returns Dept, 1 Warehouse Way. Include RMA-58120 on the label."

Out-of-policy or ambiguous requests route to an agent, not an auto-decline. A return that's 2 days past the window, a high-value item, or a fraud-pattern match goes to a human with the full thread, because the goodwill call on an edge case is a person's to make, not the agent's.

Next steps