Build an email agent with Google ADK and Agent Inbox

Google’s Agent Development Kit is a Python way to define agents, tools, and runners. It does not need to become a Gmail OAuth project. If the agent should have a mailbox people can reply to, give it Agent Inbox through MCP/stdio or ordinary HTTP tools. Do not touch SMTP. Do not store a user’s mailbox password. Drafts wait on Ask.

This is a how-to for a pattern: ADK as the agent runtime, Agent Inbox as the mailbox, Neuro OS as the company control plane when you are ready to run the same role with policy and review.

Tools over transports

ADK agents call tools. You can expose Agent Inbox in two ways:

• MCP/stdio: run the Agent Inbox MCP server as a subprocess and let ADK use those tools.
• HTTP: wrap the REST API in Python functions — create_inbox, list_threads, get_message, search, create_draft.

HTTP is explicit and easy to test. MCP is convenient if you already standardize on MCP across runtimes. Pick one per project. Mixing both in the same agent usually duplicates tools and confuses the model.

Provision once, outside the hot path:

from agentinbox import AgentInbox
client = AgentInbox()
inbox = client.inboxes.create(username="adk-mail", domain="agentinbox.space")

Pass inbox.id into the agent’s instruction as a constant. The model should not create a new inbox because a prompt said “hello.”

Python agent, no SMTP

A minimal ADK mail agent: receive an inbound thread id (from a webhook worker), fetch messages, classify, and call create_draft. The send tool either does not exist or it only completes after an approval record is present. In Neuro OS that record is Ask. In a local ADK runner it can be a CLI confirm or a small review page. Do not smtplib.sendmail from a tool “just for the demo.” Demos become production.

Keep API keys in the environment of the runner, not in the instruction text. Log tool names and thread ids. Do not log message bodies in shared debug channels.

Drafts plus Ask

The product boundary that matters is outbound. The agent may read. The agent may search. The agent may write a draft. A human sends. If you connect a CRM tool in the same ADK agent, that write is Ask too.

Structure the draft: thread id, to, cc, subject, body, attachments the agent actually fetched. Show the human the last inbound excerpt. If they edit, send the edited body. If they reject, store the reason on the thread as an internal note, not as mail.

Threading headers stay the platform’s job. You pass the thread id; Agent Inbox keeps the conversation together. Background is in email threading for AI agents.

A first ADK loop you can test

Write three unit tests that do not require a model: tool list is scoped to one inbox; create_draft does not send; a second identical inbound event does not create two drafts. Then run one live thread: you email the agent, the runner drafts, you approve, you see the reply.

When the same workflow must run for a team, move the role to Neuro OS. ADK can remain how you prototype tools. The gates, the git-backed instructions, and the forwarding path for humans are the company layer.

Skip Gmail OAuth unless you are building a personal experiment that you are willing to revoke. Production agents get an API mailbox. That is the whole design.

Agent Inbox gives each role a mailbox people can reply to, with forwarding into Neuro OS when a human must see the thread. Outbound mail defaults to Ask. Run the role on Neuro OS. To scope the first inbox, get started.

Explore Neuro OS →