Where a draft is filed

When the Executive Assistant saves a draft in the user's Outlook (DraftMail, DraftReply), it also writes the draft's record into the mesh: an Essentials/Email node with the recipients, subject and body, status Draft, and the Outlook web link (draftLink) that opens the draft. The record is what the Mail app lists, what a counterparty's page shows, and what the message page's Save as Outlook draft / Send act on.

The order of places

The directive (maintainer, 2026-09-15) is to always look for a better place than the user's home. The tools take an optional fileUnder:

1. fileUnder given — the shared place the mail concerns: a CRM counterparty's Correspondence (Wingtip/Correspondence) or its deal (Globex/Team). The record is filed there and relatedTo points at it. The agent is told (Agent/ExecutiveAssistant) to find the counterparty first: search nodeType:Crm/Counterparty partitions:all, matching the recipient's company or domain.
2. No fileUnder — the user's own {user}/Mails. That folder is created as an Essentials/Mailbox the first time, so the fallback is still a working Mail app page, and the answer tells the model the record went there because no shared place was named.

A mailing (PrepareMailing) is the exception. It stays under its owner, because its Send is bound to the owner's partition (MailingSender.ApproverIsOwner).

Three rules the implementation holds

• The record never fails the draft. By the time the record is written, the draft is already in Outlook. A refused or faulted record write is reported, with what was not written and why, and the answer still starts DRAFT SAVED — NOT SENT. Reporting failure would invite a second draft, which the amend-never-redraft rule forbids.
• The content is the wire shape. EmailContent is compiled by the mesh from Essentials/Email/Source, so the compiled module writes it as a JSON object carrying "$type": "EmailContent" and camelCase members (DraftRecords.Content), and the owning hub types it. The Mailbox type's live test writes that exact shape against the real type and reads it back as EmailContent.
• One bridge at the mesh edge. The write is composed reactively and bridged once through ObserveCompletion, exactly like PrepareMailing.

Tests: src/MeshWeaver.Mail.MicrosoftGraph.Test/ExecutiveAssistantDraftRecordTests.cs executes each case on a real mesh: the fallback, fileUnder, a refused record, a missing hub, a create response without a link (read back by id), and a reply. Essentials/Mailbox/Test/MailboxLiveTests.cs covers the in-mesh half.

Amending a recipient is a bounded operation

Adding one person to a draft's Cc once cost about 500k input tokens (Plugins#4454). The cost of a round is the size of what the model is sent, times the number of model calls: the tool loop sends the whole conversation again on every call, and every tool result read earlier in the round rides along with it. A one-field amend therefore has to stay small in BOTH factors, and the address lookup was the step that could not:

• The address comes from FindContact. SearchMail answers with each hit's sender only, so a person who was a RECIPIENT could be found only by ReadMail, which returns the whole message body. FindContact(name) reads ONE page of message headers ($search=participants:…, $select=from,toRecipients,ccRecipients, 25 messages, no next link followed) and answers with at most ten name/address pairs whose name or address holds every word asked for, most frequent first — never a subject, a preview or a body. The other participants of a matching message are left out.
• A To/Cc/subject change patches that field alone. The agent's instructions (Agent/ExecutiveAssistant) patch the record with only the changed field and UpdateDraft the Outlook copy with the same field, so a Cc change never re-sends the body.

Proven in ExecutiveAssistantFindContactTests at the HTTP boundary: the one request it makes, the header-only projection, the bound on the answer, and that a body the mailbox serves anyway never reaches it. Not measured: the per-call input of the original round, whose thread was not readable.