База знаний
Как подключить AI-агента к отдельному почтовому ящику в Google Workspace, Microsoft 365, Яндекс 360 и Cloudflare: API, IMAP/SMTP, маршрутизация и безопасность.
Подключить AI-агента к отдельному почтовому ящику можно почти в любой корпоративной почте — но способ зависит от платформы. Это руководство сравнивает варианты для Google Workspace, Microsoft 365, Яндекс 360 и Cloudflare и показывает, как выбрать безопасный путь под конкретный бизнес-процесс.
Главное различие между платформами — есть ли у них webhook-native доступ к почте (когда о новом письме узнаёшь мгновенно, без опроса) или агенту приходится опрашивать ящик по IMAP.
| Платформа | Способ подключения | Webhook-native | Когда выбирать |
| Google Workspace | Gmail API + Pub/Sub push, либо маршрутизация копии | Да | Кастомный агент на корпоративной почте |
| Microsoft 365 | Microsoft Graph + change notifications, shared mailbox | Да | Enterprise, общие ящики команды |
| Яндекс 360 | IMAP/SMTP + OAuth, правила обработки писем | Нет (polling / IMAP IDLE) | Российский рынок, платный тариф 360 |
| Mail.ru / VK WorkMail | IMAP/SMTP, OAuth или пароль приложения | Нет | 1–2 ящика, небольшие команды |
| Cloudflare Email Service | Email Routing → Worker (open-source Agentic Inbox) | Да | Быстрый пилот на отдельном поддомене |
| Helpdesk-платформы | Входящая почта превращается в тикеты | — | Поддержка клиентов с готовым процессом |
| Unified email API | Один API для Gmail, Outlook, Exchange, IMAP | Да | SaaS-продукт под разные почты клиентов |
Независимо от платформы рабочий контур почтового агента выглядит одинаково:
flowchart LR
A["Письмо на отдельный адрес"] --> B["Агент классифицирует тип"]
B --> C["Извлекает поля: кто, что, бюджет, сроки"]
C --> D["Готовит черновик ответа"]
D --> E["Создаёт задачу или запись в рабочей системе"]
E --> F["Человек подтверждает отправку"]Почтовый агент — это не кнопка «написать ответ», а отдельный рабочий контур. В полезном бизнес-сценарии он:
Самый безопасный режим для старта: агент не отправляет письма сам, а создаёт черновики и структурированные заметки. Автономную отправку включают только для узких сценариев с понятными правилами.
Google Workspace — один из самых удобных вариантов для подключения агента к отдельному корпоративному email.
Рабочая схема:
leads@company.com;Подписка на новые письма строится через метод users.watch, который привязывает ящик к вашему Pub/Sub-топику:
POST https://gmail.googleapis.com/gmail/v1/users/me/watch
{
"topicName": "projects/my-project/topics/gmail-inbox",
"labelIds": ["INBOX"]
}Важная деталь: watch живёт не дольше 7 дней, поэтому его нужно периодически продлевать (обычно — повторным вызовом users.watch раз в сутки по расписанию), иначе уведомления тихо прекратятся.
Для корпоративного внедрения есть два уровня доступа.
Первый — пользовательская авторизация OAuth для конкретного ящика. Хорошо для пилота: владелец ящика явно даёт приложению доступ.
Второй — domain-wide delegation. Это админский механизм Google Workspace: сервисное приложение получает доступ к данным пользователей организации без отдельного согласия каждого. Режим мощный, поэтому минимальные scopes, отдельный сервисный аккаунт, список разрешённых ящиков и журналирование обязательны.
Встроенный Gemini в Gmail — это помощник для пользователя внутри интерфейса, а не кастомный агент на отдельном бизнес-ящике. Gemini помогает с summary и черновиком, но для процесса «письмо пришло → агент разобрал → создал задачу → подготовил ответ по правилам компании» нужен отдельный интеграционный слой.
Полезные источники:
Если компания не хочет давать агенту прямой API-доступ к ящику, можно использовать маршрутизацию. Google Workspace поддерживает split delivery, dual delivery, forwarding / address maps и compliance routing.
Для агентного сценария это даёт несколько вариантов:
Удобно, когда надо пилотировать агента без изменения MX домена и без переноса всей почты.
Microsoft 365 часто даже удобнее для enterprise-сценариев: Microsoft Graph хорошо покрывает почту, shared mailboxes и события.
Рабочая схема:
requests@company.com;Подписка на новые письма создаётся так:
POST https://graph.microsoft.com/v1.0/subscriptions
{
"changeType": "created",
"notificationUrl": "https://your-app.example.com/graph-webhook",
"resource": "users/requests@company.com/mailFolders('inbox')/messages",
"expirationDateTime": "2026-06-25T18:00:00Z",
"clientState": "secret-state-value"
}Mail.Read.Shared / Mail.ReadWrite.Shared. Но для подписки на change notifications (webhooks) делегированные .Shared-права не работают — нужны application-права (Mail.Read / Mail.ReadWrite). По умолчанию application-права дают доступ ко всем ящикам тенанта, поэтому их обязательно ограничивают одним ящиком через application access policy (RBAC for Applications) в Exchange Online. Microsoft Graph не поддерживает доступ к in-place archive mailboxes.Shared mailbox — естественная модель для support, sales intake, тендеров, бухгалтерских документов и внутренних сервисных адресов: ящик виден команде, а агент работает как первый слой разбора. Для маршрутизации и копий используются Exchange Online mail flow rules.
Полезные источники:
Copilot в Outlook решает соседнюю задачу — помогает пользователю суммировать цепочки и писать ответы. Но для отдельной агентной роли («агент входящих заявок», «агент тендеров», «агент HR-резюме») обычно нужен собственный workflow через Graph, shared mailbox и внешнюю бизнес-логику.
Яндекс 360 важен для российского рынка: корпоративная почта на домене, shared mailboxes и админские правила.
Реалистичная схема подключения агента:
zayavki@company.ru;Отличие от Google и Microsoft: меньше ощущения «готового webhook-native email API». Поэтому для агента чаще нужен polling или IMAP IDLE, аккуратная обработка повторов, статусов прочтения, папок и ошибок SMTP. Для интеграций есть API Яндекс 360 и сценарий со шлюзом входящей почты.
Полезные источники:
Для Mail.ru, VK WorkMail и других провайдеров базовая модель такая же: IMAP для чтения, SMTP для отправки, OAuth или пароль приложения для авторизации, если это разрешено настройками безопасности.
Это рабочий путь для небольших компаний, но менее удобен для масштабного агентного продукта:
Для одного-двух ящиков можно подключаться напрямую через IMAP/SMTP. Для продукта на множество клиентов лучше рассмотреть унифицированную прослойку.
Cloudflare Email Service — другой класс решения. Он не подключается к существующему Gmail или Яндекс-ящику как клиент, а строит агентный email-контур на инфраструктуре Cloudflare. В апреле 2026 на Agents Week сервис вышел в public beta и объединил отправку (Email Sending) и входящую маршрутизацию (Email Routing) в один продукт.
Вместе с ним Cloudflare открыла Agentic Inbox — open-source reference-приложение (self-hosted почтовый клиент с AI-агентом), которое показывает, как собрать такой контур целиком.
Как это устроено:
Обработка входящего письма в Worker выглядит примерно так:
export default {
async email(message, env, ctx) {
const from = message.from;
const subject = message.headers.get("subject");
const raw = await new Response(message.raw).text();
// классификация и черновик через Workers AI,
// состояние ящика — в Durable Object, вложения — в R2
await env.INBOX.handleIncoming({ from, subject, raw });
},
};Сильная сторона подхода — быстрый запуск отдельного агентного адреса без тяжёлой интеграции с корпоративной почтой. Например: brief@ai.company.com, lead@inbox.company.com, tender@agent.company.com, docs@intake.company.com. Основная почта при этом остаётся в Google, Microsoft или Яндекс.
company.com уже обслуживается Google Workspace или Яндекс 360, нельзя включить маршрутизацию только для одного адреса agent@company.com без учёта всей почты домена. Чистый путь — отдельный поддомен или пересылка из существующей почтовой системы.Полезные источники:
Если задача — поддержка клиентов, часто не нужно начинать с низкоуровневого подключения к email. Уже есть платформы, где письмо превращается в тикеты, очереди, SLA, базу знаний и AI-ответы.
Типовые возможности:
Хороший путь, если у компании уже есть support-процесс или много обращений. Минус: такие системы менее удобны для кастомных задач вроде разбора инвестиционных заявок, тендерных ТЗ или юридического intake — там слишком много helpdesk-логики и мало свободы для своего агента.
Примеры: Zendesk AI agents, Front.
Если нужно строить агентный продукт, подключающийся к почте разных клиентов, прямые интеграции с Google, Microsoft, Яндекс и IMAP быстро становятся дорогими в поддержке. В этом случае полезны unified email API:
Минусы: появляется внешний посредник с доступом к почте; нужна проверка безопасности и хранения данных; стоимость растёт с числом ящиков; для российских клиентов важен вопрос юрисдикции.
| Провайдер | Модель | Когда подходит |
| Nylas | Управляемый SaaS, шире по календарю и контактам | Нужны почта + календарь + контакты без своих серверов |
| Unipile | Управляемый SaaS, multi-channel (почта + мессенджеры) | Несколько каналов общения в одном API |
| EmailEngine | Self-hosted, фиксированная цена (около $995/год) | Данные не должны покидать вашу сеть, нужен только email |
Примеры: Nylas Email API, Unipile Email API, EmailEngine.
Каждый сценарий — это отдельный адрес, набор извлекаемых полей и результат.
leads@company.comtender@company.comdocs@company.comjobs@company.comsupport@company.comoffice@company.comGoogle Workspace: для кастомного агента — Gmail API + Pub/Sub; для осторожного пилота — forwarding или dual delivery на агентный адрес; для масштаба — admin review domain-wide delegation.
Microsoft 365: лучший путь — shared mailbox + Microsoft Graph + change notifications; для маршрутизации — Exchange Online mail flow rules; права приложения ограничить только нужным ящиком.
Яндекс 360: начать с отдельного ящика или shared mailbox; подключить через IMAP/SMTP OAuth (с платным тарифом); использовать правила обработки писем; заранее продумать polling, дедупликацию и журналирование.
Не трогая основную почту: создать поддомен ai.company.com или inbox.company.com, подключить его к Cloudflare Email Routing, запустить Agentic Inbox на отдельном адресе, при необходимости настроить пересылку.
Нужен готовый support: смотреть Zendesk, Front, Freshdesk, Intercom; не писать свой агент, пока не понятно, что helpdesk-платформы не хватает.
SaaS для разных клиентов: рассмотреть Nylas, Unipile или EmailEngine; отдельно проверить безопасность, хранение данных, OAuth scopes, стоимость и юрисдикцию.
Самый практичный первый шаг — «AI intake mailbox».
Что запускаем:
Чего не делаем на первом этапе:
Хорошие первые адреса: brief@..., leads@..., tender@..., docs@..., support@....
Почтовый агент работает с внешним, недоверенным текстом: письмо может содержать не только полезную информацию, но и вредные инструкции для модели.
Безопасная модель простая: агент предлагает, человек подтверждает.
На практике: первичную базу с данными россиян держите в РФ, а использование зарубежной почты для агента оформляйте как трансграничную передачу — с уведомлением Роскомнадзора и правовым основанием (например, согласием субъектов). Для чувствительных процессов с данными граждан РФ это весомый аргумент в пользу Яндекс 360, Mail.ru / VK WorkMail и российской инфраструктуры. Это не юридическая консультация — перед внедрением проверьте схему с юристом по 152-ФЗ.
Рынок движется в сторону AI-помощников в почте, но остаётся свободная практическая ниша — специализированные агентные ящики под конкретные операционные процессы.
Для Google и Microsoft это лучше делать через официальные API и события. Для Яндекс 360 — через отдельный ящик, IMAP/SMTP OAuth и админские правила (с учётом платного тарифа). Для быстрого независимого пилота — через Cloudflare Email Service и Agentic Inbox на отдельном поддомене. Для поддержки клиентов — через готовые helpdesk-платформы. Для SaaS-интеграции с разными почтами — через unified email API.
Главная ценность не в том, что агент «умеет читать почту». Ценность в том, что у компании появляется управляемый входной канал: письмо превращается в структурированную работу, черновик ответа и понятный следующий шаг.
Если у вас уже есть поток писем, который хочется превратить в управляемый процесс, начать стоит с одного адреса под одну задачу — так быстрее всего увидеть пользу без риска.
Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov
Можно прийти с идеей, черновым контекстом или уже живой задачей. Помогу быстро понять, где реальный следующий шаг, а где лишний шум.
Обычно хватает 2–3 сообщений, чтобы понять, могу ли я здесь реально помочь и в каком формате лучше двигаться дальше.
Эндрю Ын запустил Context Hub — CLI-инструмент, который даёт кодинг-агентам актуальную документацию по API. Но самое интересное — агенты смогут обмениваться находками между собой.
Я подключил Codex к Яндекс.Диску через официальное приложение Яндекса, провёл metadata-only аудит, нашёл дубли, вынес мусор в карантин и подготовил облако к дальнейшей миграции.
История о том, как после очистки Яндекс.Диска через Codex мы запускаем прямую миграцию в домашний Synology: metadata-only manifest, NAS-worker, контроль маршрута, retry-логи и прим…
Мы используем cookie и аналитические сервисы Яндекс.Метрика, Top.Mail.Ru и Umami для анализа посещаемости и улучшения сайта. Продолжая пользоваться сайтом, вы соглашаетесь с Политикой обработки персональных данных.