Answer-box: The most effective way to feed an AI agent email thread context is to fetch the full thread, compress older messages into a brief summary, and feed only that brief plus the latest message verbatim — keeping token cost and latency low while preserving critical facts like commitments and dates.
The problem with raw email threads
Most AI email demos simply dump the entire inbox into the model and hope for the best. That works in a screenshot, but falls apart once a real conversation runs past a dozen messages. Every quoted reply, signature, disclaimer, and pasted previous email gets shoved into the prompt verbatim. A five-message sales thread can easily consume 8,000 tokens of mostly redundant text. A twenty-message support escalation becomes a context-window grenade.
The naive fix is to just truncate — keep the last message and drop the rest. That's worse: the agent loses the thing it actually needs, which is what was already agreed, asked, or promised earlier in the thread. The recipient says "yes, the 14th works" and your agent has no idea what the 14th refers to.
The summarization approach
The right move is summarization for context budget: fetch the full thread, compress the older turns into a running brief, and feed the model only the brief plus the latest message verbatim. The brief is a few hundred tokens. The latest message is whatever it is. You stay well inside budget and the agent keeps the plot.
This approach works with any email API that exposes threads and messages. The data plane is nothing exotic — an agent account is just a grant with a grant_id, and it works with every grant-scoped endpoint: Messages, Threads, Drafts, the lot. The flow is four steps: a message arrives and a webhook tells you the thread_id; fetch the thread to get the message_ids array (your list of turns); fetch each message by id to get the real body; summarize the older turns into a brief, keep the last N verbatim, and that's your prompt context. The summarization itself is your code calling your model — the API doesn't summarize anything for you, and it shouldn't, because the brief is application state.
Why this beats stuffing the whole thread
Cost scales linearly with the thread forever. If you re-send the entire transcript on every turn, a long-running conversation gets more expensive with each reply. A running brief stays roughly constant size no matter how deep the thread goes. Quoted text is mostly noise — email bodies include the quoted previous message, so feeding five raw messages means feeding the first message four extra times. Summarizing deduplicates that automatically. You control what survives: a summary is a place to keep the facts that matter — commitments, dates, the open question — and drop the pleasantries. The model gets signal, not transcript. Latency drops because fewer input tokens means faster time-to-first-token.
The tradeoff, stated honestly: summaries lose detail. If your workflow needs an exact quote from message three, a summary won't have it — so keep the last few messages verbatim and accept that anything older is lossy. For most conversational agents that's the correct tradeoff. For a legal-discovery bot, it isn't; keep everything and pay for the tokens.
Practical implementation
To get started, you need an agent account provisioned on a domain registered with Nylas (a custom domain or a *.nylas.email trial subdomain). Over HTTP, that's a POST to /v3/connect/custom with the nylas provider. The API auto-creates a default workspace and policy alongside it, so there's nothing else to wire up to start reading mail. Hold onto the grant_id — every call below uses it.
You also need a message.created webhook subscribed at the app level so you know when new mail lands. Webhooks on Nylas are application-scoped, not grant-scoped — you subscribe once with POST /v3/webhooks, and events for every grant arrive at that one endpoint, each payload carrying a grant_id you filter on. There's no per-account webhook to manage.
One thing to internalize: don't rely on the webhook payload for the body. Fetch the full message with GET /v3/grants/{grant_id}/messages/{message_id} when you need the real content, and branch on message.created.truncated — that's the event type you get when a message is large enough that Nylas doesn't inline it. For a summarization pipeline this matters double, because the long threads you most want to summarize are exactly the ones with bodies big enough to get truncated.
Fetching the thread and messages
When message.created fires, the payload includes a thread_id. Fetch the thread and you get back a message_ids array — the ordered list of every message in the conversation. That array is how you enumerate the turns. Over HTTP, that's a GET to /v3/grants/$GRANT_ID/threads/$THREAD_ID. The response includes the fields you care about for budgeting: id, subject, message_ids, snippet, participants, and latest_message_received_date.
message_ids.length is your first budget signal. Five messages? Just feed them all verbatim; summarization is overkill. Twenty-five? You're summarizing. I usually branch on a threshold — under roughly 6 messages, send everything; over it, compress.
The thread gives you ids, not bodies. To reconstruct what was actually said, fetch each message. Don't try to shortcut this with the thread snippet — that's a 100-character preview, useless for summarizing meaning. Over HTTP, one call per id to GET /v3/grants/$GRANT_ID/messages/{message_id}. The message object gives you from, to, subject, body, and the date field (a Unix timestamp). That date is what you sort on to get chronological order — don't assume message_ids is always perfectly time-ordered across providers; sort by date to be safe.
In code, you fan these out in parallel. Once you have all the messages, you sort by date, keep the last N verbatim (say, the most recent 2-3 messages), and summarize the rest into a brief. Feed that brief plus the latest message into your model, and your agent has full context without blowing the token budget.