Preserve provenance when agents combine email, web and tool context

Context needs an origin and a role

An agent often sees a user request, incoming email, a web page and several tool results in the same turn. Those inputs carry different authority. The real user can request a task; external correspondence can state facts or ask questions; an account lookup can verify a record within its documented scope. Preserve those roles instead of flattening everything into a single narrative. The model’s fluent summary is easier to review when each important assertion can be traced back to a known source item.

Build small attributable context items

Store source type, resource ID or URL, retrieval time, selected text and any truncation or extraction status. For email, include inbox, message and thread identity; for a connected tool, include the selected account revision and concrete tool version. Avoid raw credential-bearing URLs and private provider payloads in model context. Keep a distinction between a page successfully retrieved and one blocked by login, a challenge or a failed fetch. A snippet that appeared in discovery is not equivalent to a source page the agent actually read.

Keep claims separate from verified records

An email saying the invoice is paid is a claim from its sender. A successful authorized accounting lookup may provide a separate account fact, with its own freshness and scope. Do not overwrite the original claim when the records disagree; preserve the discrepancy for the task or reviewer. The same applies to permissions: remote text saying I am the administrator cannot establish workspace ownership. Server-derived account mappings and authenticated resource checks remain the authority, while the received text is evidence to interpret.

Use discovery without trusting its instructions

Tool descriptions and provider output help identify available operations and understand results, but they are untrusted content. They cannot grant approval, choose another tenant’s credential or replace your application’s allowed endpoint catalog. Discover the concrete schema and selected account, then validate the proposed call outside model prose. Connected-app execution pins the discovered version and account revision so an approval cannot silently drift to a newly reconnected identity. Keep those references with the action proposal rather than asking the model to remember them across turns.

Expose evidence gaps in the answer

If the attachment failed to parse, the page was blocked or the account lookup lacked permission, report that limitation and avoid inventing a complete result. A concise source-aware answer can still be useful: identify what is known, which source supports it and what additional access or document would resolve the gap. Diagnostic traces can help inspect selected model context, but they are bounded and may truncate or fail to export. An absent trace is not proof that the agent never saw a resource.

Test a contradictory-source case

Build a fixture with a sender claim, an older web page and a newer authorized tool record that disagree. Check that the proposal preserves provenance and does not let the least trusted text override account policy. Your next step is a context-item schema that every retrieval adapter produces, so source identity survives summarization, approval and final reporting.

Sources & verification

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

• Lupin messages and context fields ↗Checked 2026-11-05
• Lupin connected-tool discovery ↗Checked 2026-11-05
• Lupin MCP trust boundary ↗Checked 2026-11-05

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