Я начинал с простой схемы: агент вызывает SMTP, письмо уходит. Но SMTP не хранит контекст, который нужен агенту: состояние синхронизации, связь ответа с исходным письмом и историю опасных действий. После перезапуска процесс может повторно разобрать ту же почту, а ответ без исходных заголовков легко превращается в новое письмо.

Поэтому я разделил транспорт и сервисный слой. В личном коннекторе агент работает через MCP и REST, а зеркало сообщений и состояние синхронизации хранятся в SQLite. Наружу отдаётся непрозрачный message_ref, поэтому reply и поиск не завязаны на внутренний UID почтового сервера. В Exchange-коннекторе тот же принцип дополнен локальным индексом и отдельным контролем готовности VPN.

Сами коннекторы дают агенту чтение, поиск, отправку и ответ, а поверх MCP можно построить отдельный агентский контур автоматизации. В нём агент разбирает входящие, отделяет и удаляет мусор по заданным правилам, собирает саммари входящих писем и доставляет это саммари мне в согласованный канал. Отправка и ответ остаются контролируемыми операциями с аудитом, а опасное действие я оставляю за ручным подтверждением.

Доказательства этой архитектуры: personal-mail-mcp и exchange-mail-mcp. Практический вывод для меня простой: SMTP может быть транспортом, но AI-агенту нужна модель почты с постоянным состоянием, связностью тредов и понятной границей ответственности.

Какую операцию вы бы первой запретили почтовому AI-агенту без ручного подтверждения?