The inbox that drafts itself

Here's the most boring, most expensive job in an ecommerce brand's day. A customer asks "where's my order?" To answer, someone opens the thread and reads the whole back-and-forth, switches to the admin or order-management tool to look up the actual status, switches back, and writes a reply. Then does it again. And again, all day. It's not hard — it's just relentless, and it eats the hours of the person who should be doing higher-value work.

So the newest slice of Jarvis takes aim at it. Not by replacing the human who hits send — by doing the reading and the drafting up to that point.

What it does

Once a day, early, it works through the support inbox and answers one question per thread: does this actually need a reply from us right now? For the ones that do, it reads enough of the history to understand the real ask, pulls the order context, and writes a clean draft for a human to glance at and send. The specification is uncompromising about the line it will not cross:

"Review real customer emails, identify which ones need a reply, read the relevant thread context, and create clean Gmail drafts for the team to review. It must never send emails automatically."

Drafts only. A person is always the one who sends. What it leaves behind each morning looks like this (illustrative):

The hard part is knowing what to ignore

Most of an inbox isn't customers waiting on you. It's newsletters, promotions, vendor and logistics noise, internal chatter, threads already resolved, and threads where the customer is the one who still owes a reply. Draft into all of that and you've made a mess, not a help. So most of the design is a skip list — the spec says, in effect, only draft "where the brand is the next responder," and then enumerates everything to leave alone.

That restraint is the whole product. A tool that drafts everything is noise; a tool that drafts only the five threads that genuinely need you is leverage.

Human-in-the-loop, by design

Two details make it safe to trust:

• Placeholders, not guesses. When a fact isn't in front of it — a date, an availability, a policy call — it writes an obvious blank like [ENTER DATE] or [CONFIRM AVAILABILITY] rather than inventing one. The draft flags its own uncertainty.
• A run summary, every time. Each pass reports how many threads it reviewed, how many drafts it created, and how many it skipped because they were waiting, already replied, or resolved. That count is the other thing the owner wanted: a read on the queue itself — how much is pending, how much got handled, how much in a week.

Still in development, and that's the point

I'll be honest about the status, because the development log is: this one isn't validated end-to-end yet. It's built to abort rather than misbehave when something isn't right, and the plan is exactly the demo-driven one — connect it to the real inbox, do a run, read the drafts by hand, and only trust it once the drafts are good enough that a human is just clicking send.

That's the same shape as the rest of Jarvis. Automate the relentless part — the reading, the lookup, the first draft — and keep the human for the one move that actually carries judgment and risk: sending. The machine clears the queue down to the few that need a person. The person stays in charge of the words that go out the door.