Кейс Outlook → RAG → Trello: как мы превращаем письма в задачи разработчикам
Рабочий маршрут от технического письма до назначенной задачи в Trello — с контекстом базы знаний и сохранённым решением.
Мы разработали процесс, который читает заданное окно писем Outlook, отделяет рабочие запросы от обычной переписки, определяет ответственного разработчика, получает релевантные сведения из базы знаний Acumatica и передаёт одобренные задачи в Trello через n8n. Система также сохраняет, почему письмо стало карточкой или было пропущено.
OUTLOOK → получить и нормализовать письма
→ AI INTAKE → создать задачу или пропустить
→ НАЗНАЧЕНИЕ → адресат, клиент и продукт
→ RAG → получить контекст до составления плана
→ ФИНАЛЬНАЯ ПРОВЕРКА → одобрить создание или пропустить
→ N8N → карточка Trello и аудитПроблема внутри почтового ящика
Техническая работа приходила цепочками писем, а не готовыми задачами. Сообщение могло быть новым запросом, пересланным поручением, уточнением, отчётом о статусе или простой благодарностью. Создавать карточку из каждого письма — значит засорять доски разработчиков. Пропустить реальный запрос — значит оставить работу в почте. Поэтому сначала нужно было решить, требует ли письмо новой задачи, и только затем обращаться к Trello.
Назначение исполнителя усложняло задачу. У клиента может быть ответственный, у продукта — профильный специалист, а поля «Кому» и «Копия» дают разные сигналы. Мы собрали процесс, который применяет их последовательно и сохраняет понятный след решения. Одной языковой модели недостаточно, чтобы надёжно управлять идентификаторами досок, доставкой и повторной обработкой.
Что мы реализовали
Рабочая система связывает Microsoft Outlook, n8n, отдельный Python AI Orchestrator, RAG по знаниям Acumatica и Trello. n8n остаётся транспортом: получает письма, нормализует технические поля, отправляет пакет в сервис принятия решений, принимает компактные действия и создаёт карточки на досках разработчиков. Orchestrator отвечает за смысловое решение, назначение, получение знаний, план задачи и финальную проверку. Запись в Trello выполняет n8n, а не Orchestrator.
В архитектуре сохранён и более ранний связанный маршрут n8n: классификация, матрицы клиентов и продуктов, обязательный RAG-поиск перед планированием, компактная карточка и обновление журнала. Активная AI-first ветка переносит смысловые решения в Orchestrator, но оставляет техническую валидацию, доставку и прослеживаемость явными. Здесь описана работающая система; подготовленные компоненты не выдаются за включённые.
Путь одного потенциального поручения
Запуск n8n по расписанию читает Inbox и Archive Outlook за настроенный период. Нормализация выделяет устойчивые идентификаторы, тему, отправителя и адресатов, дату, контекст ответа или пересылки. Это важно: технический запрос мог быть переслан одним человеком другому, а ответ о статусе в той же цепочке не обязан становиться новой задачей.
Нормализованный пакет поступает в AI Orchestrator. Первый этап решает, просит ли письмо выполнить работу. Если да, до составления плана проходят назначение исполнителя и поиск в базе знаний. Затем финальная проверка оценивает предлагаемое действие. Только одобренное создание возвращается в n8n для записи в Trello. Обновления, благодарности, неопределённые и небезопасные действия не дают команды создать карточку.
Для примера можно представить письмо с запросом изменить интеграцию Acumatica. Процесс способен выделить поручение, сопоставить сигналы ответственности, получить относящийся к теме контекст и сформировать задачу выбранному разработчику. Это иллюстративный сценарий: мы не публикуем чужое письмо и не утверждаем, что каждая неоднозначная переписка классифицируется без ошибок.
Назначение — правило бизнеса, а не угаданное имя
Система сопоставляет прямого адресата, закрепление клиента, специализацию по продукту, адресатов в копии и текущую загрузку досок в заданном порядке. Закрепление клиентов и продуктов хранится в редактируемых матрицах; Python-resolver работает с их синхронизированными копиями, а не помещает полные таблицы в каждый запрос к модели. Идентификаторы досок и списков Trello применяются после выбора разработчика.
Понятный прямой адресат может быть сильнее общего правила по клиенту или продукту. Когда сигналы не позволяют выбрать исполнителя уверенно, процесс может пропустить создание, а не отправить карточку на случайную доску. Это осознанный компромисс: неоднозначное письмо можно проверить, а уверенно неверное назначение создаёт незаметный операционный шум.
RAG даёт контекст до составления плана
Сервис знаний Acumatica предоставляет опорные материалы для технического планирования. Поиск встроен как определённый шаг перед созданием плана, а не оставлен необязательным вызовом инструмента, который агент может пропустить. Планировщик получает релевантные фрагменты и использует их для краткой задачи разработчику. База знаний становится частью процесса, а не отдельной страницей, которую оператор должен вспомнить открыть.
Найденный текст остаётся источником сведений, а не поводом придумывать поведение продукта. Если материалы отсутствуют или не относятся к теме, а техническое исполнение от них зависит, безопаснее не выпускать уверенную карточку. Простые административные или перечневые задачи можно оценить по самому письму и назначению, не делая сильное совпадение RAG обязательным для любого поручения. Это снижает и риск вымышленных инструкций, и число неоправданных отказов.
Краткая карточка и отдельный журнал
Разработчику нужна исполнимая задача, а не полный текст частной переписки или трасса модели. Компактное действие содержит понятное название, короткий рабочий контекст, выбранное место назначения и уместные метки. Нормализованная тема письма остаётся в конце видимого заголовка: связь с исходным запросом сохраняется без копирования всей цепочки в Trello.
Подробности решения хранятся в аудите. Ветвь n8n фиксирует источник и статус доставки, а Orchestrator отдельно сохраняет ход принятия решения. Такое разделение помогает разбирать пропущенную задачу, неверное назначение или сбой передачи, не открывая сырые письма и RAG-вывод на досках разработчиков. Успешный ответ промежуточного API сам по себе ещё не доказывает создание карточки Trello.
Реальный дефект изменил контракт действий
Production-аудит выявил конкретный сбой: этапы AI распознали письмо как обновление существующей работы, но fallback в Orchestrator сформировал общую новую задачу и пропустил её в Trello. Ошибка находилась в контракте между решением и доставкой. Замена модели на более мощную сама по себе не исправила бы этот путь.
Мы изменили активный контракт на два исхода. Intake должен явно определить новую задачу, а финальная проверка — явно одобрить её создание. Любое обновление, отсутствие нужных данных, неопределённость или небезопасный результат превращаются в «пропустить» и не попадают в компактные действия для Trello. Исправление прошло адресные регрессионные проверки на сервере; качество следующих реальных запусков всё равно требует наблюдения. Мы не заявляем, что риск дублей или ошибок классификации исчез полностью.
Доставка сейчас и подготовленный защитный слой
Рабочий production-маршрут использует n8n, асинхронный callback Orchestrator и существующий путь доставки. Журнал резервирования помогает не выдавать повторно действия по уже учтённым решениям, однако после записи во внешнюю систему и до подтверждения возможна неоднозначность при сбое. Поэтому проектирование идемпотентности нельзя честно описать как безусловную гарантию отсутствия дублей.
Мы подготовили более устойчивый outbox с сохраняемыми заданиями, claim действий и явным подтверждением создания карточки; код развернут за неактивным переключателем. Worker выключен, а n8n callback не переведён на новый протокол. Это выполненная подготовительная инженерная работа, но не часть активного обещания доставки в этом кейсе. Для приёмки нужен контролируемый сквозной тест Trello и проверка спорных состояний.
Полученный результат
В результате работает система «письмо → задача» с чётким распределением ролей: n8n передаёт сообщения и создаёт карточки Trello; Orchestrator принимает решение, назначает и проверяет; RAG добавляет знания в планирование; аудит сохраняет путь решения. Технический почтовый ящик превращается в более структурированный вход для разработчиков с понятными границами того, что создано и почему.
Кейс показывает выполненную интеграцию и инженерную работу по исправлению существенного production-дефекта. Он не обещает измеренную экономию времени, идеальную классификацию, отсутствие дублей или активную доставку v2. Для таких утверждений нужны другие доказательства, чем у реализованного и проверенного здесь маршрута.
Реализованный маршрут
- Окно Outlook → нормализация в n8n
- AI-решение и назначение исполнителя
- Acumatica RAG → план → финальная проверка
- Одобренное создание → n8n → Trello
- Аудит решения и доставки