How we would build safe email follow-up agents in Matrix
A product and technical architecture for connecting Outlook and Gmail, detecting follow-up opportunities, drafting replies, and keeping people in control.
Part of the Matrix company OS series.
Email looks like an obvious agent workflow: read a thread, decide whether it needs attention, draft a response, and send it.
The difficult part is everything hidden inside “read a thread.” Mailboxes mix clients, colleagues, personal information, confidential attachments, automated notifications, and messages unrelated to the workflow. Sending is also unusually consequential: a polished mistake leaves the company immediately.
We think email agents should begin as attention and drafting systems, not autonomous senders.
This is the architecture we would use to build them in Matrix OS. It is a roadmap design, not an announcement that these integrations are available today.
Connect the employee, not a shadow inbox
The default connection should use the employee's identity and delegated access.
Microsoft Graph distinguishes delegated permissions, where an app acts for a signed-in user, from application permissions that operate without a user. Google similarly exposes separate Gmail scopes for metadata, reading, composing, and sending, and recommends choosing the narrowest scope possible.
Matrix should make those distinctions visible during setup:
- what mailbox is connected,
- which folders or labels are in scope,
- whether message bodies or only metadata are read,
- whether Matrix can create drafts,
- whether it can send,
- who granted access,
- when the connection expires or is revoked.
An organization-wide service connection may eventually support shared mailboxes or controlled processes, but it should be an administrator decision with a separate policy—not a shortcut around employee consent.
Watch narrowly, reconcile reliably
Both Microsoft and Google support event-driven mailbox updates, but neither should be treated as a perfect event log.
Microsoft Graph supports change notifications for Outlook messages and incremental change tracking. Subscriptions expire and require renewal. Gmail delivers mailbox notifications through Cloud Pub/Sub; its watch must be renewed, and Google documents that notifications can occasionally be delayed or dropped. Gmail clients retrieve the actual changes using history.list from a stored history ID.
The Matrix connector should:
- Watch only configured folders or labels where possible.
- Persist the provider cursor or history ID.
- Treat a notification as a wake-up signal.
- Retrieve authoritative changes after the cursor.
- Deduplicate provider events.
- Periodically reconcile if notifications are missed.
- stop safely when authorization changes.
This is the same durable trigger pattern described in Matrix agent workflows.
Associate threads with work explicitly
The system needs to know which workspace owns a conversation.
Useful association signals include:
- a user explicitly attaches the thread,
- participants match known project contacts,
- a project-specific mailbox folder or label is used,
- a stable reference appears in the subject or message,
- the relationship owner confirms a suggestion.
Participant overlap alone is not enough. The same adviser may appear across several mandates, and a person can discuss unrelated matters in one email chain.
Matrix should store the provider thread ID and a source link, not silently copy every historical message into the project. The workspace index can materialize only the relevant content authorized for that task.
Detect follow-up conditions, not just elapsed time
“No reply for two days” is a weak automation rule.
A useful follow-up detector considers:
- who owes the next action,
- whether the last message asks a question or promises a deliverable,
- the project stage and urgency,
- business days and local holidays,
- out-of-office responses,
- whether a colleague replied elsewhere,
- recent meetings or calls,
- whether the owner dismissed an earlier reminder.
The output should be a proposed task with evidence:
Suggested follow-up
Reason: client requested revised figures; owner promised delivery Tuesday
Last relevant message: source link
Project status: figures approved, not yet sent
Suggested owner: relationship ownerThe agent can rank attention without pretending that every silent thread is overdue.
Draft first, send later
Outlook supports creating a message or reply as a draft and sending it in a later operation. Gmail exposes composing and sending through authorization scopes. Matrix should exploit that separation.
The initial action ladder can be:
| Level | Capability |
|---|---|
| 0 | Read approved metadata |
| 1 | Read approved thread content |
| 2 | Suggest a follow-up task |
| 3 | Generate a Matrix draft |
| 4 | Create a provider draft after review |
| 5 | Send after explicit approval |
| 6 | Policy-approved automatic sending for narrow cases |
Most client-facing workflows should stop at level 4 or 5. Automatic sending belongs only to tightly bounded scenarios with tested templates, controlled recipients, clear opt-outs, and monitoring.
The reviewer needs a communication brief
The review screen should show more than the generated body:
- intended recipients and CC list,
- the exact thread being answered,
- project and relationship owner,
- facts and attachments referenced,
- promises or deadlines introduced by the draft,
- tone or language instructions,
- differences from the approved template,
- whether approval creates a draft or sends immediately.
Recipients deserve special treatment. An agent should not add a new external recipient based only on text found in a message. Attachments should be checked against workspace and destination policy before they leave the organization.
Keep sensitive content out of unnecessary memory
The email integration should separate:
- provider message and thread identifiers,
- minimal searchable metadata,
- encrypted or ephemeral working content,
- durable project facts explicitly accepted by a person,
- generated drafts and approval history.
Not every email body should become permanent company memory. Retention should follow the workflow purpose and company policy. When a source permission disappears, derived indexes should be invalidated and active workflows should lose access.
This follows the same bounded-memory model we propose for OneDrive and Google Drive.
Evaluate the assistant before expanding its authority
Useful metrics include:
- precision of “needs follow-up” suggestions,
- dismissal and snooze rate,
- percentage of drafts accepted with minor, major, or no edits,
- recipient corrections,
- factual correction rate,
- time saved per accepted draft,
- near misses caught during review,
- messages sent without the required evidence or policy checks.
The key progression is earned authority. A workflow should receive more automation only after its bounded use case performs reliably and its failure modes are understood.
Email is not just another integration. It is where the company speaks. In a shared Matrix workspace, agents can help colleagues notice and prepare communication while people retain authorship, judgment, and accountability.