AutoGen email integration: 3 methods compared

AutoGen makes it straightforward to build multi-agent teams that call tools and coordinate on complex tasks. But the moment one of those agents needs to send or read email, you're dealing with SMTP configuration and OAuth token management. Neither was designed for programmatic access by autonomous agents.

I've tested the three main approaches to AutoGen email integration over the past few months. Here's how each one works, where it falls short, and what to consider before shipping one to production.

How to integrate email with AutoGen (3 methods)#

1. Composio + AutoGen: OAuth-based integration with managed credential exchange and broad provider support.
2. autogen-ext-email: Direct SMTP/IMAP connection using raw credentials, lightweight and self-hosted.
3. MCP email server: Protocol-native, with dynamically discovered tools loaded through a single endpoint.

Composio is the fastest path for prototyping with OAuth-protected providers like Gmail. The autogen-ext-email package gives you direct control over mail server connections. MCP fits agents that already use the Model Context Protocol for other capabilities and want email to work the same way.

Composio: the OAuth route#

Composio sits between AutoGen and email providers, handling OAuth token exchange so your agent never touches raw passwords. You authenticate once through their dashboard, and the agent gets callable actions like GMAIL_SEND_EMAIL or GMAIL_FETCH_EMAILS.

from composio_autogen import ComposioToolSet, Action

toolset = ComposioToolSet()
tools = toolset.get_tools(actions=[Action.GMAIL_SEND_EMAIL])

assistant = AssistantAgent(
    name="email_agent",
    llm_config=llm_config,
    tools=tools
)

This also works with Outlook. Composio supports both providers through the same interface, which is handy if your agents interact with corporate Microsoft 365 inboxes alongside personal Gmail accounts. You can also wire up event triggers: Composio supports gmail_new_gmail_message events that fire your AutoGen workflow when a new email arrives, so you don't need to poll.

The tradeoff: every email operation routes through Composio's servers. Your agent's ability to send and receive depends on their uptime and pricing. For a weekend prototype, that dependency is invisible. For a production agent processing hundreds of messages daily, it's a single point of failure you don't own.

There's also a design mismatch worth thinking about. Composio was designed for humans who want agents to handle tasks on existing accounts. An agent that needs its own independent mailbox is solving a different problem entirely.

Raw SMTP with autogen-ext-email#

The autogen-ext-email package takes the opposite approach: your agent gets direct SMTP and IMAP credentials, no intermediary.

from autogen_ext_email import EmailAgent, EmailConfig

agent = EmailAgent(
    name="email_agent",
    model_client=model_client,
    email_config=EmailConfig(
        email="agent@yourdomain.com",
        password="your-app-password",
        server="smtp.gmail.com",
        port=587
    )
)

This is the most transparent method. You see exactly what's happening, there's no third-party service in the path, and setup takes about ten minutes if you already have SMTP credentials ready. Your agent can read incoming emails and send replies within the same execution loop.

The problem is sitting right there in the code sample. A plaintext password in the source file. Every example in the package's GitHub repo does the same thing. In production, you'd pull credentials from environment variables (os.environ["EMAIL_PASSWORD"]) or a secrets manager, but the library doesn't push you in that direction or even mention it in the README.

Gmail's app passwords make this worse. Google only issues them for accounts with two-factor authentication enabled, and each app password grants full account access. Not scoped to sending. Not read-only. Full access to the inbox, sent folder, contacts, and drafts. If that credential leaks, the attacker owns the entire mailbox.

Rate limits are the other issue. Gmail caps consumer accounts at roughly 500 sends per day (2,000 for Google Workspace). The autogen-ext-email package doesn't include retry logic or rate-limit detection. Your agent hits a 550 rejection with no graceful fallback unless you build that handling yourself.

The MCP approach#

Model Context Protocol flips the integration model. Instead of installing an email-specific package, you run an MCP server that exposes email operations as discoverable tools. AutoGen 0.4 added native MCP support, making this approach feel more natural than it would have a year ago.

from autogen_ext.tools.mcp import McpWorkbench

email_tools = McpWorkbench(server_url="http://localhost:3001")
agent = AssistantAgent(
    name="email_agent",
    tools=await email_tools.list_tools()
)

Your agent connects to the MCP server, discovers available actions (send, receive, search, label), and calls them like any other tool function. Swap the email backend for a different provider, and the agent code stays the same.

The flexibility is real, but so is the immaturity. Most email MCP servers on GitHub are weekend proof-of-concept projects with minimal error handling. You're responsible for hosting the server and managing reconnections when things break. The ecosystem doesn't have a dominant, well-maintained email implementation yet, so you'll likely end up forking someone's repo and patching it yourself.

One thing MCP does well: it's the cleanest path for agents that already use MCP for file access, web browsing, or database queries. Adding email becomes another tool endpoint, not a separate SDK with its own authentication story. If AutoGen's MCP support matures alongside better email MCP servers, this could become the default approach within a year.

Where all three methods fall short#

Every method above assumes a human already created the email account, configured the credentials, and handed them to the agent. For one agent, that's trivial. For ten agents that each need their own address, you're manually provisioning Gmail accounts or buying Workspace seats at $7/month each.

None of these integrations handle inbox provisioning. They connect to existing mailboxes. They don't create new ones.

Deliverability is another shared blind spot. None of the three manage sender reputation or handle bounce processing. An AutoGen agent that starts sending from a fresh domain will land in spam folders consistently. We covered the common setup mistakes that tank deliverability in a previous post, and they apply to every method here.

Security is uneven across all three. Composio abstracts credentials but introduces a trust boundary with a third party. The autogen-ext-email package exposes secrets by default. MCP servers range from careful to careless depending on the author. None of them scan incoming emails for prompt injection, which matters when your agent is autonomously reading and acting on messages from unknown senders.

An agent-first alternative#

There's a different approach: instead of connecting AutoGen agents to human email accounts, give them access to email infrastructure designed for agents from the ground up.

LobsterMail works this way. Your agent provisions its own inbox through an API call, no human signup required. The SDK handles authentication, inbox creation, sending, and receiving. Incoming messages get scored for prompt injection before the agent processes them, which directly addresses the security gap in the three methods above.

import { LobsterMail } from '@lobsterkit/lobstermail';

const lm = await LobsterMail.create();
const inbox = await lm.createSmartInbox({ name: 'My AutoGen Agent' });
// inbox.address → my-autogen-agent@lobstermail.ai

For AutoGen, you'd wrap this as a callable tool or expose it through an MCP server. The difference from the methods above is that the agent isn't borrowing a human's Gmail. It has its own address, its own sending reputation, and security built into the infrastructure layer rather than bolted on after the fact.

If you want to try this with an AutoGen project, grab the setup instructions here and paste them into your agent.