A forty-message thread is one read, not forty scrolls. An agent pulls every message in order, reduces the exchange to what was decided and what is still open, and caches the result so it only reworks a thread when someone actually replies.
Long threads do not fail because the writing is hard. They fail because the thing you need is buried in the middle, and there is no way to get to it without reading what came before it.
Nobody writes the decision in message thirty-one. They write the problem in the first three, the argument in the next twenty, and then the decision, followed by six messages of logistics about who is sending which file. Reading from the top is the only correct method and also the only expensive one, which is why people skim and then re-read the same thread twice.
The instinct is to scroll to the last message and read backwards. That works right up until the thread turns out to be two conversations braided together — a scheduling thread that became a pricing thread that became a contract thread — and the reply you needed was in the braid. The hours people say they lose to email are mostly this: reading, realising, re-reading.
Native summaries in most mail clients compress the message you have open. Useful, occasionally, and not the same job. A client that shows you a tidy version of the last reply tells you nothing about what the first eleven replies established, which is usually the part you cannot reconstruct from memory.
Copy it once, paste it into Zaira, and it does four things: finds the thread, reads every message in it, reduces the exchange to decisions and open loops, and caches the result against the thread so the next run only pays for what is new.
The summary is written once and reused until someone replies. That is the whole difference from asking every time — a thread you read forty messages to catch up on costs one read, and costs nothing more to catch up on again tomorrow.
The agent pulls every message in the thread and works through them in order, so the part you would have scrolled back for is in the answer. You are reading a reduction of the exchange, not your own memory of the bottom third of it.
Decisions are reported with the message they came from, and anything unresolved is listed as unresolved. The failure mode of summarising email is a confident summary that quietly invents agreement where there was none — this one is built to refuse that.
The summary is stored against the thread. Ask again tomorrow and it reads the handful of messages that arrived overnight rather than re-reducing forty. The threads that change constantly are the ones you revisit, so that is where the saving compounds.
The questions people ask before letting an agent read a thread they were dreading.
A client-side summary compresses the message currently open. This reduces the entire thread — every message, in order — which is a different input and answers a different question: not what did this one person just write, but what did this whole exchange establish. For a thread you have not read at all, the second question is the one you actually have.
The prompt reduces it in batches rather than truncating. Each batch is summarised on its own, then those summaries are reduced into the final one, and the agent tells you it did this. The reason it matters: a thread quietly cut off at message twenty produces a summary that reads as complete and is missing the part that changed the answer. The most valuable note in the output is often the oldest message.
No. Step 2 requires get_thread over the whole thread and reports the message count, and Step 5 repeats that count back to you so you can sanity-check it against what Gmail shows. If the count looks wrong, the run failed and you should treat the summary as absent rather than incomplete — that is the failure mode worth catching, because a short summary is indistinguishable from a complete one at a glance.
Yes, and it is cheaper than the first pass. Once the summary is stored against the thread, a question about it is answered from the stored version plus whatever arrived since. That is the reason the prompt caches in Step 4 rather than just printing a summary — without a stored version, every question re-reads the whole thread and the economics stop working after the second or third question.
It reads the thread as stored, which includes every message addressed to the mailbox — including replies you were copied on and never opened. That is often where the useful context is, because a thread you were cc'd on is frequently one where somebody else made the decision. Where the thread contains confidential material you want kept out of the summary, say so in the prompt and it will report that part as excluded rather than paraphrasing around it.
Long enough that it is worth running once by hand before scheduling it. The work is a handful of tool calls plus the reduction itself, and the token cost scales with the thread length rather than with your mailbox — you are paying for the one thread you asked about, not for everything that arrived this week. That is the difference from a client that summarises everything on open.