monday.com запустила AI Teammates - production-агентов, которые автономно выполняют задачи в рабочем пространстве: от создания тикетов до генерации и мёрджа кода. В основе - Amazon Bedrock для инференса моделей и связка EKS, SNS/SQS, ElastiCache и EFS для оркестрации, событийной обработки и памяти. Система прошла путь от простых ассистентов до мультиагентов с автоматическим ревью действий и механизмом доверительного слияния PR. В этом разборе - архитектурные решения, пять ретрофитов для интеграции в десятилетнюю кодовую базу и конкретные конфигурации, которые вы сможете адаптировать.
Команда monday.com решала задачу, знакомую многим инженерам: как встроить AI-агентов в монолитную систему, не переписывая её с нуля. Ответом стали пять ретрофитов - точечных инженерных вмешательств, которые добавили событийность, управление состоянием, долговременную память, автоматический контроль и доверенное слияние кода. Каждый ретрофит решал одну конкретную проблему без каскадных изменений в легаси-коде.
Введение: зачем monday.com понадобились AI-агенты и почему Bedrock
Платформа monday.com управляет миллионами рабочих процессов. Пользователи тратят часы на рутинные операции: обновление статусов, назначение ответственных, перенос задач между досками, генерацию отчётов. AI Teammates задумывались как автономные участники команды, которые берут эти задачи на себя. Первая версия - простые ассистенты, реагирующие на прямые команды в чате. Текущая - мультиагентная система, где агенты координируют работу друг друга и выполняют цепочки из десятков действий без участия человека.
Выбор Amazon Bedrock определили три фактора. Безопасность: данные клиентов не покидают контур AWS, все вызовы моделей идут через Bedrock API с IAM-политиками. Управляемость: команда не хотела тратить ресурсы на хостинг open-source моделей и мониторинг GPU-инфраструктуры. Интеграция: Bedrock нативно стыкуется с остальными сервисами AWS, которые уже использовались в monday.com - EKS, SNS/SQS, ElastiCache, EFS. Подробный разбор возможностей Bedrock для агентных систем мы делали в руководстве по Bedrock Managed Knowledge Base.
Архитектура production AI-агентов на AWS
Архитектура AI Teammates построена вокруг четырёх ключевых сервисов AWS. EKS оркеструет контейнеры агентов, SNS/SQS формирует событийную шину, ElastiCache держит оперативное состояние, EFS хранит долговременную память. Bedrock выступает единой точкой входа для всех LLM-вызовов - агенты не ходят напрямую к моделям, все запросы проходят через Bedrock с включёнными Guardrails.
Поток данных выглядит так: событие из monday.com (пользователь создал задачу, изменился статус, пришёл вебхук) попадает в API Gateway, который публикует его в SNS-топик. Топик фан-аутит событие в несколько SQS-очередей - по одной на каждый тип агента. Агент в поде EKS забирает сообщение из очереди, извлекает контекст из ElastiCache, при необходимости подгружает историю из EFS, формирует промпт и отправляет его в Bedrock. Ответ модели парсится, действие выполняется через API monday.com, результат пишется обратно в кэш и файловую память.
EKS как основа оркестрации: почему не Lambda
Агентам monday.com нужно долгоживущее состояние. Типичный сценарий - агент ведёт многошаговый диалог с пользователем или координирует цепочку из 5-7 действий, удерживая контекст между вызовами. Lambda с её 15-минутным лимитом и холодными стартами не подходит: каждый запуск требовал бы перезагрузки контекста из внешнего хранилища, что добавляло бы 200-400 мс latency на операцию.
EKS решает это через поды с длительным временем жизни. Каждый под держит WebSocket-соединение к Bedrock, in-memory кэш сессий и пул подключений к Redis. Автомасштабирование настроено по глубине SQS-очереди: если очередь растёт быстрее, чем агенты разбирают, Horizontal Pod Autoscaler добавляет поды. Пример манифеста пода агента:
apiVersion: apps/v1
kind: Deployment
metadata:
name: ai-teammate-task-agent
spec:
replicas: 3
selector:
matchLabels:
app: task-agent
template:
metadata:
labels:
app: task-agent
spec:
containers:
- name: agent
image: monday/ai-teammate:2.4.1
env:
- name: BEDROCK_MODEL_ID
value: "anthropic.claude-sonnet-4-20250514-v1:0"
- name: REDIS_ENDPOINT
valueFrom:
secretKeyRef:
name: redis-credentials
key: endpoint
- name: SQS_QUEUE_URL
value: "https://sqs.us-east-1.amazonaws.com/123456789/task-agent-queue"
resources:
requests:
memory: "512Mi"
cpu: "250m"
limits:
memory: "2Gi"
cpu: "1"Поды не хранят критическое состояние локально - всё важное сразу уходит в Redis и EFS. Это позволяет убивать и пересоздавать поды без потери данных.
Событийная шина на SNS/SQS: надёжная доставка задач
Десятилетняя кодовая база monday.com построена на синхронных вызовах. Чтобы добавить асинхронную обработку событий агентами без переписывания ядра, команда внедрила событийную шину на SNS/SQS. Паттерн: API Gateway проксирует запросы пользователей, параллельно публикуя копию события в SNS-топик. Основной поток выполнения не меняется - monday.com обрабатывает запрос синхронно как и раньше. Агенты получают событие асинхронно и реагируют независимо.
Fan-out реализован через подписки SNS на несколько SQS-очередей. Каждый тип агента - свой consumer с отдельной очередью. Это даёт изоляцию: если агент задач лёг под нагрузкой, агент уведомлений продолжает работать. Каждая очередь имеет Dead Letter Queue с политикой редрайва после трёх неудачных попыток:
{
"RedrivePolicy": {
"deadLetterTargetArn": "arn:aws:sqs:us-east-1:123456789:task-agent-dlq",
"maxReceiveCount": 3
},
"VisibilityTimeout": 300,
"MessageRetentionPeriod": 86400
}VisibilityTimeout в 300 секунд даёт агенту пять минут на обработку одного сообщения. Если агент не уложился и не удалил сообщение из очереди, оно становится видимым для другого пода - встроенный механизм retry без дополнительного кода.
ElastiCache и EFS: память и состояние агентов
У агентов monday.com два типа памяти: оперативная (сессионный контекст, промежуточные результаты) и долговременная (история действий, пользовательские предпочтения, результаты прошлых runs). Для оперативной используется ElastiCache for Redis, для долговременной - EFS.
Redis держит сессионные данные с TTL 30 минут. Ключ формируется как session:{user_id}:{agent_type}, значение - JSON с текущим контекстом диалога, планом действий и промежуточными результатами. После завершения цепочки действий сессия сбрасывается, а итоговый результат пишется в EFS. Latency чтения из Redis - менее 1 мс, что критично для агентов, делающих 5-10 вызовов Bedrock на одну пользовательскую команду.
EFS смонтирована ко всем подам агентов как общая файловая система. Структура директорий:
/mnt/efs/
agents/
{agent_id}/
memory/
2026-07/
23.jsonl
22.jsonl
preferences.json
metrics/
success_rate.json
avg_latency.jsonКаждая запись в JSON Lines - одно завершённое действие агента с полным контекстом: промпт, ответ модели, выполненные операции, затраченное время. Файлы ротируются ежедневно. Версионирование реализовано через копирование предыдущего файла перед записью - простой механизм отката, не требующий базы данных. Сравнение стоимости: EFS стоит около $0.30/ГБ/месяц против $0.25/ГБ для S3, но даёт POSIX-совместимую файловую систему с монтированием NFS, что упрощает код агентов - они просто читают и пишут файлы.
Пять ретрофитов для интеграции AI в десятилетнюю кодовую базу
Ядро monday.com - монолит на Node.js и Ruby, который развивается с 2014 года. Прямая вставка AI-логики в этот код означала бы многомесячный рефакторинг и риски для стабильности основного продукта. Команда выбрала стратегию ретрофитов - внешних надстроек, которые перехватывают события и управляют агентами, не трогая ядро. Пять ретрофитов закрыли ключевые разрывы между синхронным монолитом и асинхронной агентной системой.
Ретрофит 1: Перехват событий через API Gateway и SNS
Проблема: монолит monday.com не генерирует события - все операции синхронные, запрос пришёл, обработался, ответ ушёл. Агентам нужен поток событий для реакции. Решение: API Gateway, который уже стоял перед монолитом, настроили на публикацию копии каждого релевантного запроса в SNS-топик. Основной поток не изменился - запрос уходит в монолит и возвращает ответ пользователю. Параллельно событие уходит агентам.
Конфигурация интеграции API Gateway с SNS:
{
"integration_type": "AWS",
"integration_method": "POST",
"uri": "arn:aws:apigateway:us-east-1:sns:action/Publish",
"request_parameters": {
"integration.request.header.Content-Type": "'application/x-www-form-urlencoded'",
"integration.request.querystring.TopicArn": "'arn:aws:sns:us-east-1:123456789:ai-events'"
},
"request_templates": {
"application/json": "{\"Message\": $input.json('$'), \"MessageAttributes\": {\"event_type\": {\"DataType\": \"String\", \"StringValue\": \"$input.params('event_type')\"}}}"
}
}Фильтрация событий происходит на уровне подписок SNS - агент задач подписан только на события создания и изменения задач, агент уведомлений - на события дедлайнов и упоминаний. Это исключает лишнюю нагрузку на очереди.
Ретрофит 2: Управление состоянием через внешний кэш
Проблема: агенты выполняют многошаговые цепочки - собрать данные, проанализировать, предложить план, дождаться подтверждения, выполнить. Состояние цепочки нужно хранить вне монолита, чтобы не добавлять таблицы в его базу данных. Решение: Redis как внешний кэш состояний с паттерном Saga для распределённых транзакций.
Каждый шаг цепочки - отдельное сообщение в SQS. Перед выполнением шага агент проверяет состояние в Redis: если предыдущий шаг завершился успешно, продолжает; если упал - запускает компенсирующее действие. Пример состояния цепочки в Redis:
{
"chain_id": "chn_abc123",
"user_id": "usr_456",
"steps": [
{"action": "collect_data", "status": "completed", "result": {"tasks": 42}},
{"action": "analyze", "status": "in_progress", "started_at": "2026-07-23T10:15:00Z"},
{"action": "propose_plan", "status": "pending"},
{"action": "execute", "status": "pending"}
],
"compensations": ["rollback_task_updates"]
}TTL для состояния цепочки - 1 час. Если цепочка не завершилась за час, запускается компенсация и пользователь получает уведомление о тайм-ауте.
Ретрофит 3: Память агентов на EFS с версионированием
Проблема: агентам нужна долговременная память о прошлых взаимодействиях с пользователем - его предпочтения, типичные паттерны задач, результаты предыдущих runs. Хранение в базе данных монолита потребовало бы схемы миграции и индексов, которые команда не хотела добавлять в production-базу. Решение: EFS как общее файловое хранилище с простым версионированием.
Каждый агент пишет в свою директорию на EFS. Формат - JSON Lines, одна строка на действие. Перед записью агент копирует текущий файл с суффиксом .bak - это даёт точку отката на последнее стабильное состояние. Для длительной истории агент подгружает только последние 50 записей при старте сессии, полная история используется редко - для анализа паттернов поведения пользователя.
Выбор EFS вместо S3 обоснован latency: чтение маленького JSON-файла с EFS занимает 5-10 мс, с S3 - 50-100 мс за счёт HTTP-запроса. При 10 чтениях на сессию разница становится заметной.
Ретрофит 4: Guardrails - автоматическое ревью действий агента
Проблема: агенты выполняют действия от имени пользователя - создают задачи, меняют дедлайны, отправляют уведомления. Ошибка агента может нарушить рабочий процесс. Ручное ревью каждого действия убивает весь выигрыш в скорости. Решение: Guardrails - слой автоматической проверки планов агента перед выполнением.
Механизм работает так: агент формирует план действий и отправляет его на проверку в Bedrock Guardrails. Там план прогоняется через набор правил: запрет на удаление данных, ограничение по количеству изменяемых задач за один run (не более 50), проверка на соответствие политике доступов пользователя. Если план проходит проверку, агент выполняет его. Если нет - план возвращается агенту на доработку с указанием нарушенных правил.
Пример правила Guardrail:
{
"name": "no_deletion",
"type": "DENY",
"filter": {
"action": "DELETE",
"resource": ["task", "board", "workspace"]
},
"message": "Agent is not allowed to delete resources. Suggest archiving instead."
}За первые три месяца работы Guardrails отклонили 2.3% планов агентов - в основном попытки удалить задачи вместо архивации и превышение лимита изменений за run. Ни одного инцидента с потерей данных пользователей.
Ретрофит 5: Confidence-scored auto-merge для PR
Проблема: AI-агенты monday.com генерируют код - автоматизацию рабочих процессов, скрипты интеграций, шаблоны досок. Код нужно проверять и сливать в репозиторий. Ручное ревью каждого PR от агента создавало узкое горлышко. Решение: confidence-scored auto-merge - система, которая вычисляет оценку уверенности для каждого PR и автоматически сливает те, что выше порога.
Confidence score вычисляется как взвешенная сумма факторов:
- Прохождение юнит-тестов: 40% веса. Если все тесты зелёные - 1.0, есть упавшие - 0.
- Статический анализ (ESLint, RuboCop): 20% веса. Нормализованный счёт от 0 до 1 на основе количества и серьёзности предупреждений.
- Покрытие тестами нового кода: 15% веса. Отношение покрытых строк к добавленным.
- Историческая точность агента: 15% веса. Доля успешно слитых PR этого агента за последние 30 дней.
- Сложность изменений: 10% веса. Обратно пропорциональна количеству затронутых файлов - чем меньше файлов, тем выше score.
Формула: score = 0.4 * tests + 0.2 * lint + 0.15 * coverage + 0.15 * history + 0.1 * (1 / sqrt(files_changed))
Порог для автоматического слияния - 0.85. PR с оценкой 0.7-0.85 уходят на ревью человеку с пометкой «высокая уверенность», ниже 0.7 - стандартное ревью. За первые полгода работы системы 62% PR от агентов были слиты автоматически, среднее время от генерации кода до мёрджа сократилось с 4.2 часов до 18 минут. Ноль откатов автоматически слитых PR в production.
Эволюция: от AI-ассистентов к полностью автономным мультиагентам
AI Teammates прошли три этапа развития за два года. Каждый этап добавлял автономности и требовал архитектурных изменений.
Этап 1: Ассистенты, реагирующие на команды. Первая версия - чат-бот в интерфейсе monday.com. Пользователь пишет «создай задачу» или «покажи мои дедлайны», ассистент выполняет одно действие и ждёт следующей команды. Архитектура: один под в EKS, один тип событий в SQS, состояние в памяти пода. Процент успешных действий: 78%. Среднее время ответа: 3.2 секунды. Главное ограничение - ассистент не мог инициировать действия сам и не держал контекст между сессиями.
Этап 2: Полуавтономные агенты с ограниченным набором действий. Агентам добавили триггеры: изменение статуса задачи, приближение дедлайна, утренний дайджест. Агент сам определял, нужно ли реагировать, и выполнял до трёх действий за один run. Появились Redis для состояния и EFS для памяти. Процент успешных действий вырос до 89%, но агенты всё ещё работали по одному на рабочее пространство и не координировались друг с другом.
Этап 3: Полностью автономные мультиагенты. Текущая версия. Несколько агентов в одном рабочем пространстве координируют работу через общее состояние в Redis. Агент задач может передать контекст агенту отчётности, тот - агенту уведомлений. Цепочки из 10+ действий без участия человека. Процент успешных действий: 96.4%. Среднее время выполнения цепочки из пяти действий: 8.7 секунд. Ключевое архитектурное изменение - добавление координационного слоя в Redis, где агенты публикуют свои намерения и проверяют конфликты перед выполнением.
Критерии перехода между этапами, которые команда monday.com использовала для принятия решений: процент успешных действий выше 85% на текущем этапе, время восстановления после сбоя менее 30 секунд, покрытие Guardrails для всех новых типов действий. Без выполнения этих критериев переход на следующий этап не начинался.
Опыт monday.com пересекается с другими production-внедрениями агентов. В кейсе агента для разработки мы разбирали, как инструмент, проваливший боевые задачи, закрыл более 50% исследовательских запросов аналитиков - схожий паттерн эволюции от узкой задачи к неожиданно полезному применению. А в разборе code-агентов мы поднимали проблему лавины сгенерированного кода - ровно ту, которую confidence-scored auto-merge в monday.com решает через автоматическую фильтрацию.
Практические выводы и рекомендации для вашего проекта
Кейс monday.com даёт семь конкретных уроков для команд, которые строят production AI-агентов.
1. Начинайте с событийной шины. Первый ретрофит monday.com - перехват событий через API Gateway и SNS - занял две недели и сразу дал агентам поток данных без изменения ядра системы. Без событийной модели агенты останутся чат-ботами.
2. Выносите состояние в Redis. Не храните состояние агента в памяти пода или в базе данных монолита. Redis с TTL и паттерном Saga даёт отказоустойчивость и изоляцию. При падении пода другой под продолжит цепочку с того же места.
3. Guardrails обязательны с первого дня. 2.3% отклонённых планов на старте - это тысячи предотвращённых ошибок. Настройте правила до того, как агенты получат доступ к реальным данным пользователей. Bedrock Guardrails позволяют сделать это декларативно, без написания кода проверок.
4. Managed сервисы экономят время. Bedrock снимает с команды хостинг моделей, мониторинг GPU, обновление версий. EFS даёт файловую систему без управления NFS-серверами. Каждый час, не потраченный на инфраструктуру, уходит на улучшение логики агентов.
5. Автоматизируйте слияние кода через confidence score. Если ваши агенты генерируют код, метрика уверенности с автоматическим порогом убирает узкое горлышко ревью. Начните с консервативного порога 0.9 и снижайте по мере накопления статистики успешных мёрджей.
6. Повышайте автономность поэтапно. Не пытайтесь сразу строить мультиагентов. Пройдите путь от ассистента к полуавтономному агенту и только потом к координации нескольких агентов. Критерии перехода monday.com - успешность выше 85% и время восстановления менее 30 секунд - работающий ориентир.
7. Мониторьте глубину очередей. SQS-очередь агента - опережающий индикатор проблем. Если очередь растёт, агенты не справляются с нагрузкой. Настройте алерты на глубину очереди и автомасштабирование подов по этому же параметру.
Типичные ошибки, которые команда monday.com совершила и исправила: игнорирование latency EFS при чтении больших файлов (перешли на построчную загрузку), перегрузка одного SNS-топика всеми типами событий (разделили на топики по доменам), отсутствие мониторинга confidence score в динамике (добавили дашборд с графиком распределения score по времени).
Архитектура AI Teammates - пример прагматичного подхода к внедрению агентов в production. Команда не переписывала легаси, не строила идеальную событийную архитектуру с нуля, а точечно добавляла ровно те компоненты, которые нужны для каждого этапа автономности. Результат: 96.4% успешных действий, 62% автоматически слитых PR и ноль инцидентов с потерей данных за два года работы системы.