Test evidence — multi-mailbox provenance

How it was tested — per-worktree venv pinned to this branch's code (verified gaia_agent_email.__file__ resolves into the branch worktree, not the shared stale install):

• pytest tests/unit/agents/email/ tests/unit/email/ → 453 passed
• New tests/unit/agents/email/test_multimailbox_provenance.py (13 tests): list/search tag + remember provenance; summarize_message / summarize_thread / archive_message_batch route by recorded provenance with no mailbox=; unknown id + 2 mailboxes still fails loud.

Proof of implementation — driving the real branch code with two spy backends (OAuth boundary faked, routing logic real):

=== search_messages across BOTH connected mailboxes — each result tagged ===
  id=g1   mailbox='google'     subject='msg-g1'
  id=m1   mailbox='microsoft'  subject='msg-m1'
=== provenance recorded in agent (id -> mailbox) ===
   {'g1': 'google', 'm1': 'microsoft'}
=== summarize_message('m1') WITH NO mailbox= : routes to the microsoft backend ===
  google backend get_message calls  : []
  microsoft backend get_message calls: ['m1']

Before this PR, acting on an id surfaced by search/list raised Cannot determine which mailbox message '<id>' belongs to ... multiple mailboxes are connected.

Summary

This closes a real multi-mailbox gap: with Gmail + Outlook both connected, ids returned by list_inbox/search_messages arrived without their source provider, so any follow-up action (summarize_message, summarize_thread, batch archive) hit the "Cannot determine which mailbox …" wall. The fix scans every connected mailbox, tags each result with its mailbox provider, records provenance, and points summarize_message at _backend_for_message — exactly mirroring the established _triage_all_backends / _pre_scan_all_backends pattern (agent.py:460, :565). It's a tight, well-scoped change with strong test coverage including the fail-loud negative case. No blocking issues; a few minor points below.

One note on verification: I couldn't run the suite or formatters in the review sandbox (pytest/black/isort unavailable, read-only FS), so the findings are from static review against the author's reported 453 passed.

Issues Found

🟢 Budget under-fills when mailboxes are uneven (read_tools.py:756, :872)
per_backend = max_results // len(backends) is computed once and never redistributed. With two mailboxes and max_results=25, each gets 12; if Gmail only has 3 INBOX messages, the result caps at ~15 even when Outlook has plenty more to give. This matches the triage/pre-scan helpers, so it's consistent — but those carry a TOTAL-budget cap specifically because local inference is slow (~9–31 s/email). list_inbox/search_messages are cheap API reads with no such cost, so here the under-fill is a pure UX loss with no compensating benefit. Worth a follow-up to redistribute leftover budget to remaining backends.

🟢 next_page_token is now always dropped (read_tools.py:770, :885)
list_inbox hardcodes "next_page_token": None and search_messages omits it entirely, where the old single-backend path forwarded the impl's real token. Neither tool exposes a page_token argument today, so this is likely a no-op in practice — but if pagination was ever intended to be wired up, the merge makes it harder. Confirm this is intentional (cross-mailbox pagination genuinely is awkward to merge).

🟢 A weak test assertion can pass without verifying anything (test_multimailbox_provenance.py:355)
test_search_tags_per_source_mailbox guards its asserts with if "g1" in by_id: / if "m1" in by_id:. With the default budget both ids are always present, so the guards never trip — but that means if a regression dropped one of them, the test would silently pass instead of failing. Consider asserting both ids are present first, then asserting their tags.

🟢 Loop logic is now duplicated a fourth time (read_tools.py:755, :871)
The "split budget → call backend → tag mailbox → remember provenance → merge" loop now exists inline in both tool closures plus _triage_all_backends and _pre_scan_all_backends. The triage/pre-scan variants live as agent methods; these two are inlined. A small shared helper on the agent (e.g. _merge_across_backends(impl, **kwargs)) would keep the budget semantics in one place and match where the other two already live. Not blocking — just flagging before a fifth copy appears.

Strengths

• Pattern fidelity. The new loops match _triage_all_backends exactly (total-budget split, mailbox tag, dual id+thread_id provenance), so the multi-mailbox behavior is uniform across list/search/triage/pre-scan.
• Fails loud, per GAIA convention. summarize_message routes through _backend_for_message, which raises an actionable error for an untagged id with two mailboxes rather than guessing — and there's an explicit test (test_summarize_message_unknown_id_two_backends_fails_loud) pinning that behavior.
• Test coverage maps directly to the bug. 13 tests cover both directions (Gmail and Outlook routing), explicit mailbox=, thread routing, batch archive, and the no-silent-guess negative case. The _Recorder shim in test_summarize_tools.py was correctly extended with _backends + _backend_for_message so the single-backend tests stay green.

Verdict

Approve with suggestions. No blocking issues — correctness and the fail-loud contract are sound, and coverage is genuinely good. The four 🟢 items (budget redistribution, dropped page token, the weak conditional assert, and the loop duplication) are all safe to address in this PR or a quick follow-up.

Live real-world evidence — real Gmail + Outlook (connected Mac, Lemonade Gemma-4-E4B)

Agent built from the real connectors (no injected backends); ids hashed and subjects/senders redacted (not posting mailbox content to a public PR):

connected backends: ['google', 'microsoft']
live list_inbox       → 12 messages  {'google': 6, 'microsoft': 6}   (each result tagged with its mailbox)
provenance recorded   → 15 entries (message + thread ids)
summarize_message(real Outlook id, NO mailbox=) → ok=True
summarize_message(real Gmail   id, NO mailbox=) → ok=True     (real Gemma-4-E4B summary)

Real OAuth + real Gmail/Graph APIs + real inference + real branch code. Pre-fix, the cross-mailbox id raised Cannot determine which mailbox '<id>' belongs to … multiple mailboxes are connected.