How to Build an Outlook AI Agent

Email is the highest-volume stream most people handle and the one where a mistake is most visible: a draft sent to the wrong recipient, a confidential thread summarised into a public channel, a commitment made in the user's name. Microsoft Graph makes Outlook integration straightforward, and that ease is why the controls matter. This guide covers building an Outlook agent that helps without creating the incident, drawing on FISTA Solutions' AI agents delivery in Microsoft environments. It complements how to build an ai email triage system and how to build a microsoft teams ai agent.

Which permission model fits?

Model	Reach	Fits	Control
Delegated	Signed-in user's mailbox	Personal assistants, triage, drafting	User consent, admin allowlist
Application	Any mailbox in tenant	Shared mailbox processing, background	Application access policy required
Application with access policy	Specified mailboxes only	The only acceptable application mode	Admin-defined scope

Delegated permissions are the default for anything a user interacts with: the agent acts as that user, within that user's mailbox, and Exchange enforces what they can see.

Application permissions can read every mailbox in the tenant, which is a credential of extraordinary reach. They exist for legitimate background processing, such as a shared support mailbox, and must be constrained with application access policies limiting the app to specific mailboxes. An application permission without an access policy is a tenant-wide mail reader and should not pass security review.

What should the agent do first?

Triage. Categorise incoming mail by type and urgency, flag messages that need a reply or contain a request, extract deadlines and action items into a structured view, identify threads where the user owes a response and has gone quiet, and detect the newsletters and notifications that can be filed automatically.

All of that reads and annotates. Nothing is sent, nothing is deleted, and the worst outcome of an error is a mis-categorised message. It is high volume, useful from the first day, and builds the evidence and trust that anything more consequential requires. See how to build an ai email triage system.

How should drafting work?

As drafts for review, saved to the user's drafts folder or presented in the client, never sent autonomously. A wrong email under a person's name, to the wrong recipient, with a wrong commitment, has consequences that no time saving offsets, and the user's judgement about tone and relationship is the part the agent cannot replicate.

The draft should ground in the thread and in whatever context the agent legitimately has, and it should be clearly marked as agent-drafted so the user reviews rather than skims. Measuring draft acceptance rate and the proportion sent with material edits tells you whether drafting is helping.

Narrow autonomous sending is defensible in specific cases: acknowledgements from a shared mailbox, scheduling confirmations, or templated responses to well-classified requests, and only after draft evidence supports it and with value and scope limits.

What about calendar and scheduling?

Lower risk and genuinely valuable. The agent reads availability, proposes meeting times, drafts invitations, summarises the day's meetings with relevant context, and prepares briefing notes from prior threads with the attendees.

Creating events and sending invitations on the user's behalf is a smaller consequence than sending email and can be automated earlier, with confirmation for external attendees. Scheduling across many participants remains genuinely hard and the agent should propose rather than impose.

How should new mail be detected?

Through change notification subscriptions on the relevant mailbox or folder, which deliver notifications when messages arrive or change, combined with delta queries to fetch the changed items. Subscriptions expire and must be renewed before expiry, and the endpoint must validate notifications.

Polling mailboxes is slow, expensive against Graph throttling limits, and unreliable at any scale, and it should be avoided.

How do compliance controls apply?

Sensitivity labels, data loss prevention policies, and retention apply to mail the agent reads and to anything it produces. Practically: the agent should respect labels in what it surfaces, so a message labelled confidential does not appear in a summary sent elsewhere; it should not move protected content into unprotected outputs such as an external index without the same protections; and its access should be logged and reviewable through the tenant's compliance tooling.

Shared mailboxes with application access add another consideration: the agent's identity is the accessor, and audit logs must attribute actions to it and, where it acts for a person, to that person. Confirm the specifics with the tenant administrator and compliance.

How is it evaluated?

Triage against the user's own categorisation on a sample, measured per category, with particular attention to the urgent-and-missed rate, which is the failure that matters. Drafts by acceptance rate and edit distance. Extraction of action items and deadlines against what the user actually recorded. Scheduling proposals by acceptance.

Evaluation sets built from real mailboxes contain sensitive content and need the same protection as the mail itself.

What does the build sequence look like?

One week on permission model, admin consent, and subscription infrastructure. Two to three weeks on triage and extraction, running for a pilot group with corrections captured. Two weeks on drafting for review, measured on acceptance. Then calendar assistance. Autonomous sending, if ever, only for narrow cases with evidence.

What goes wrong?

Application permissions without access policies. Autonomous sending on day one. Summaries that ignore sensitivity labels. Polling instead of subscriptions. Drafts not marked as agent-produced, so users send without reading. Evaluation sets containing real mail stored insecurely. And triage tuned for volume rather than for the urgent message it missed.

How should shared mailboxes be handled differently?

As the one place where application permissions and narrow autonomy are both legitimate. A support, sales enquiry, or accounts payable mailbox receives high volumes of structured, repetitive mail from external parties, and the organisation rather than an individual owns the responses.

That changes the design. Application permissions constrained by an access policy to that mailbox are appropriate. Triage and routing to the right team member is the first workflow, as with personal mailboxes. Autonomous acknowledgement, telling the sender their message was received and what happens next, is defensible early because it is templated and low-consequence. Substantive replies still go through a person until draft acceptance evidence supports narrow exceptions such as answering a well-classified request from approved content.

The audit trail matters more here, because several people and the agent act in the same mailbox. Every agent action should be attributable to the agent and, where it acted on a person's instruction, to that person.

How FISTA Solutions helps

FISTA Solutions builds Outlook agents on delegated permissions for user-facing work and policy-constrained application permissions for shared mailboxes, with triage first, drafting for review, subscription-based detection, and sensitivity label and DLP compliance designed in, through AI enablement, AI agents, and forward deployed engineers working with Microsoft 365 administrators. The record behind the approach is 150+ projects for 50+ companies with 99.9% uptime.

To automate the mailbox without automating the mistake, message FISTA on WhatsApp, or read how to build an ai email triage system.