Outlook Integration for AI Agents

The real problem

Why this is harder than it looks

On the surface, Outlook's calendar API looks approachable. You register an app in Azure, get a client ID and secret, run through an OAuth flow, and start calling Microsoft Graph. The first happy-path test works in an afternoon. Then you try to ship it to real users.

The first real problem is Azure app registration. Unlike many OAuth providers, Outlook requires you to register your own Azure AD application — there is no Scalekit-managed option. You need to decide on supported account types upfront: personal Microsoft accounts only, organizational accounts only, or both. Getting this wrong means entire categories of users cannot authorize your app, and Microsoft's error messages are not helpful. For a B2B product where your customers' employees use corporate Microsoft 365 accounts, you need multitenant mode, which can trigger additional admin-consent requirements in the customer's own Azure AD tenant.

Then there's the permissions model. Microsoft Graph uses fine-grained OAuth scopes — Calendars.Read, Calendars.ReadWrite, Mail.Read, Mail.Send are entirely separate grants. Each must be declared in your Azure app registration and requested during the OAuth flow. If your agent needs to both read and create events, you must request both scopes upfront — or force users through re-authorization later. Some enterprise tenants require an IT admin to pre-approve your app's requested permissions before any user in the org can connect. That consent-admin workflow has nothing to do with your code, but it will block your go-live.

Access tokens from Microsoft expire in one hour. Refresh token behavior differs between personal accounts and organizational accounts, and organizational refresh tokens can be revoked at the tenant level by an admin — not just by the user. If a customer's IT team revokes third-party app access across the organization, your agent starts receiving 401s with no clear signal about why. Detecting this, stopping calls, and re-prompting the right user requires infrastructure that has nothing to do with scheduling a meeting.

None of this is impossible to build. But it's weeks of plumbing before your agent can reliably say "I've scheduled that for you." Scalekit handles the Azure registration flow, token lifecycle, and multi-tenant consent complexity. Your agent names a tool and passes parameters.

Capabilities

What your agent can do with Outlook

Once connected, your agent has 5 pre-built tools covering calendar management via Microsoft Graph:

• Create calendar events with full richness: required, optional, and resource-room attendees; recurrence patterns; Teams meeting links; reminders; sensitivity and free/busy status
• List and filter events with OData: date-range queries, subject filters, field selection, sorting, and pagination across large calendars
• Retrieve any event by ID: full metadata including attendee response status and online meeting join URL
• Update any event property in place: reschedule, change attendees, convert to online meeting, or modify recurrence without recreating the event
• Delete events cleanly: by event ID, with no dangling state

Jump to tool reference

Setup context

What we're building

This guide connects a scheduling assistant agent to Outlook — helping users create meetings, check their calendar, and manage events without leaving your product.

Setup

¹ Setup: One SDK, One credential

Install the Scalekit SDK. The only credential your application manages is the Scalekit API key — no Azure secrets, no user tokens, nothing belonging to your customers.

Connected Accounts

² Per-User Auth: Creating connected accounts

Each user gets their own Connected Account, giving them a dedicated auth context. The _identifier is any unique string from your system — a UUID, email, whatever you use internally.

This call is idempotent — safe to call on every session start. Returns the existing account if one already exists.

Authorization Flow

³ The authorization flow

The user authorizes your agent once. Scalekit generates the OAuth URL with correct Microsoft Graph scopes and redirect handling pre-configured. After approval, you never see the token.

Calling Outlook

⁴ Calling Outlook: What your agent writes

With the connected account active, your agent calls Outlook actions using _{execute_tool()}. Name the tool, pass parameters. Scalekit handles token retrieval and Microsoft Graph request construction.

List upcoming calendar events

Fetch events with OData filtering. Use _filter to scope by date range, _select to limit fields, and _top for pagination.

Create a calendar event

Schedule a meeting with attendees, a Teams link, and a reminder. _subject, _{start_datetime}, _{start_timezone}, _{end_datetime}, and _{end_timezone} are required.

Update an existing event

Reschedule or modify an event by ID. Only the fields you provide are changed — everything else stays untouched.

Create a recurring event

Set up a repeating meeting — weekly standups, bi-weekly reviews — using the recurrence parameters. _{recurrence_type} sets the pattern; _{recurrence_range_type} controls when it ends.

Framework wiring

⁵ Wiring into your agent framework

Scalekit integrates directly with LangChain. The agent decides what to schedule or query; Scalekit handles auth on every invocation. No token plumbing in your agent logic.

Tool reference

All 5 Outlook tools

Calendar management via Microsoft Graph. Your agent calls tools by name — no API wrappers to write.

Connector notes

Outlook-specific behavior

Infrastructure decision

Why not build this yourself

The Microsoft Graph OAuth flow is documented. Token storage isn’t technically hard. But here’s what you’re actually signing up for:

That’s one connector. Your agent product will eventually need Salesforce, Gmail, Slack, Notion, and whatever else your customers ask for. Each has its own OAuth quirks and failure modes.

Scalekit maintains every connector. You maintain none of them.