Extract useful context from inbound email without losing evidence

Begin with the task, not the mailbox

An agent asked to summarize a renewal request needs the relevant conversation and supporting document, not every message in the inbox. Define the work item before selecting context: requested outcome, current source message and allowed next actions. This keeps private data exposure and model input size bounded while making missing evidence easier to notice. Save the source inbox and message IDs with the job. A context selection process should be reproducible enough that an operator can explain why the agent saw one attachment and omitted another.

Use extracted text with its limitations

Message objects expose preview and extracted_text alongside text, headers and attachment metadata. extracted_text strips quoted replies and can reduce repeated content, but it is a convenience representation rather than proof that all meaningful text survived extraction. Use the preview for triage and selected message or thread detail for deeper work. If a decision depends on an exact quotation, retrieve the source text or raw message. Keep the extraction status and any truncation visible rather than asking the model to fill a missing paragraph from the subject line.

Represent provenance as structured data

Build context items containing the message ID, sender, recipients, timestamp, source field and selected content. Keep retrieved account facts in separate items from sender claims. A sentence in an email saying our invoice was paid remains a sender assertion until an authorized system lookup verifies it. Do not flatten every input into one instruction paragraph, which hides which statements came from a human request and which came from external correspondence. The model can summarize uncertain claims, but the application should preserve their origin for review.

Include attachments only when needed

Inspect attachment metadata before downloading, then parse only the document types relevant to the task through a bounded processor. Keep binary and base64 data outside ordinary model context. Store a reference to the file revision and extraction result rather than embedding every byte in the prompt. If parsing fails, expose that gap in the answer. A model that saw only an attachment filename cannot accurately say it reviewed the attachment. Likewise, a forwarded summary is not a substitute for the original document when the task requires exact figures or terms.

Separate content from authority

Inbound text is evidence to interpret, even when the sender appears familiar or the delivery webhook is validly signed. It cannot change the model’s trusted rules, select a broader credential or grant approval for a tool action. Return proposed replies as drafts and route account changes through the application’s explicit authorization path. Your next step is a context fixture with a quoted chain, a document reference and a hostile instruction, then verify the selected context stays attributable and the proposed action uses only the authority supplied by the real user.

Measure the useful omissions

Log bounded metadata about selected messages, extraction success and truncation without copying private bodies into routine logs. When the answer lacks enough evidence, say which source was unavailable. That gives operators a concrete remedy, such as providing the missing document, instead of encouraging another larger and less targeted mailbox read.

Sources & verification

Reviewed against checked-in Lupin API handlers and documentation. Example requests were not executed against live providers.

• Lupin message representations ↗Checked 2026-11-05
• Lupin threads ↗Checked 2026-11-05
• Lupin attachment metadata ↗Checked 2026-11-05

Prepared with AI assistance by Lupin editorial. How we research and maintain these guides.