Email Actions: Let Declarative Agents Manage the Inbox

Your agent can find the email. It can summarize the thread, quote the important line, and tell you who to reply to. Then it stops. It cannot archive that message, flag it, move it out of your inbox, or send the reply it just drafted for you. Reading is half a job. The EmailActions capability, new in the declarative agent manifest v1.8, gives your agent the other half: write access to the mailbox.

Until now, email in a declarative agent meant one thing: search. The Email capability grounds your agent in mailbox content so it can retrieve and cite real messages. Useful, but read-only. EmailActions is the write counterpart, and it turns an agent that talks about your inbox into one that actually cleans it up.

What Is the EmailActions Capability?

EmailActions is a declarative agent capability that lets the agent perform write operations on email in the mailboxes the user can access. Where the Email capability is search-only, EmailActions is the verbs: it can triage, send, delete, manage rules, set auto-replies, and organize folders on the user’s behalf.

Here is the full menu of what it unlocks:

Category	Operations
Triage	archive, flag, mark read, pin, move, copy, report junk
Send	supervised send (with the user in the loop)
Delete	delete messages
Inbox rules	create and get rules
Auto-reply	manage automatic replies
Folders	create and list folders

That “supervised send” line matters. The agent does not fire off email into the void. Send stays a human-in-the-loop action, so the person chatting with the agent stays in control of what actually leaves the mailbox.

Enabling EmailActions

This is the entire configuration. No properties, no scoping, no URLs:

{
  "capabilities": [
    {
      "name": "EmailActions"
    }
  ]
}

That is it. The name is the only property, and it must be set to EmailActions. Once declared, your agent can act on the signed-in user’s mailbox within the permissions that user already has.

Read and Write, Together

Most useful email agents want both: find the message, then do something with it. You declare the two capabilities side by side. Email handles the search and citation, EmailActions handles the follow-through.

Here is an inbox concierge for Zava Insurance that grounds in the shared support mailbox and can also triage it:

{
  "$schema": "https://developer.microsoft.com/json-schemas/copilot/declarative-agent/v1.8/schema.json",
  "version": "v1.8",
  "name": "Inbox Concierge",
  "description": "Finds, triages, and organizes email for the Zava Insurance support team.",
  "instructions": "$[file('instructions.txt')]",
  "capabilities": [
    {
      "name": "Email",
      "shared_mailbox": "[email protected]",
      "folders": [
        { "folder_id": "Inbox" }
      ]
    },
    {
      "name": "EmailActions"
    }
  ]
}

The Email capability is scoped to the shared mailbox inbox for grounding. EmailActions is unscoped by design: it is a capability, not a knowledge source, so it does not take a folders or shared_mailbox array. The agent can act on whatever the user has permission to touch.

What This Looks Like in Chat

Triage is where this earns its keep. A support lead comes back from vacation to 200 unread messages and asks the agent to help:

Notice what happened: the agent listed folders, spotted that Finance did not exist, and offered to create it. Listing folders, creating a folder, moving messages, archiving, flagging: every one of those is an EmailActions operation. And it paused before doing anything destructive.

Permissions Stay the User’s

Write access to a mailbox sounds scary until you remember the boundary: the agent can only do what the user could already do. EmailActions runs inside the same Exchange Online permission model as Outlook.

• The agent acts as the signed-in user, on mailboxes that user can access.
• If the user cannot delete a message in Outlook, the agent cannot delete it either.
• Shared mailbox actions require the user to have the corresponding access to that shared mailbox.
• Send stays supervised, so nothing leaves the mailbox without a human confirming it.

There is no elevated permission, no service account acting on everyone’s behalf, no admin backdoor. If you would not trust the user with the action, do not expect the agent to smuggle it past the permission model. It cannot.

The Value You Just Unlocked

One capability declaration, zero properties, and your agent crossed the line from talking about email to managing it:

• Full triage in chat: archive, flag, mark read, pin, move, copy, and report junk, all from a conversation instead of a mouse.
• Supervised send: the agent drafts and proposes, the human approves, so control never leaves the person.
• Inbox automation: create and read inbox rules so recurring email routes itself.
• Folder management: list and create folders so the agent can organize on the fly, exactly like the Zava Concierge did.
• Auto-reply management: set and update automatic replies without leaving Copilot.
• Permissions by inheritance: every action is scoped to what the signed-in user can already do in Exchange Online.

Pair it with the read-only Email capability and you get the complete loop: an agent that finds the message, understands it, and then actually does something about it. That is the difference between a search box and an assistant.

Resources

• Declarative agent schema 1.8 for Microsoft 365 Copilot
• Declarative agent manifest v1.8 JSON schema
• Declarative agent manifest schema
• Declarative agents overview
• Declarative agent permissions
• Writing effective agent instructions
• Microsoft 365 Copilot extensibility overview