DoorDash перевела инженерные agent workloads с ноутбуков разработчиков на облачную платформу Flux. Это важно, потому что на таком переходе обычно и проявляются реальные ограничения по мощности, контролю доступа и наблюдаемости.
DoorDash упёрлась в пределы локального запуска агентных задач. Когда агенты работают на ноутбуке разработчика, они ограничены CPU и памятью конкретного устройства, зависят от его доступности и получают слишком широкий доступ к уже открытым на машине ресурсам. Для автономных сценариев это создаёт одновременно и операционный, и security-риск. Параллельно усложняется контроль: становится труднее понять, где именно запущен агент, к каким системам он обращается и от чьего имени действует.
Решение DoorDash — вынести эти workloads в Flux, облачную платформу для исполнения engineering tasks. Архитектура построена вокруг четырёх примитивов: cloud sandboxes, MCP gateway, reusable playbooks и invocation surfaces. Это прагматичный выбор, потому что он разделяет ответственность: песочница отвечает за изоляцию, gateway — за доступ к внутренним системам, playbook — за описание работы и границ, а интерфейсы запуска — за то, как задачу инициируют инженеры или автоматизация.
Внутри Flux изоляция реализована через Firecracker microVMs. Каждая среда получает репозитории, инструменты разработки, secrets и runtime dependencies, нужные для конкретной задачи. DoorDash сообщает, что 95th percentile SLO на полную подготовку sandbox составляет менее пяти секунд, включая старт microVM, клонирование репозиториев, установку build tools и настройку coding agent harness. Это важная деталь: для платформы такого типа задержка инициализации напрямую влияет на то, будет ли система использоваться для фоновой работы или начнёт мешать инженерному потоку.
Доступ к внутренним системам проходит через Agent Gateway, собственный MCP gateway DoorDash. Он выдаёт scoped permissions, логирует действия агентов и помогает применять policy enforcement и аудит. Playbooks описываются в YAML и фиксируют задачу, нужные инструменты, права, проверки и safety boundaries. При необходимости они могут сочетать agent-driven шаги с deterministic code. Это полезный компромисс: агенту отдают вариативную часть работы, а предсказуемые проверки и критичные действия оставляют в детерминированном контуре.
Запуск задач тоже вынесен в отдельные surfaces. Агенты могут стартовать из Slack, GitHub, cron, command line или conversational interfaces. Такая модель делает Flux не просто средой исполнения, а слоем управления инженерной работой. По сути, DoorDash пытается убрать фоновые ручные переключения, но не ценой потери контроля. Это заметно и по тому, что компания изменила Slack integration: вместо private channels она использует public threads, чтобы инженеры могли видеть выполнение, результаты и способы, которыми другие команды делегируют работу.
По данным DoorDash, платформа уже автоматизировала 130,000 engineering tasks за один месяц в 2026 году. Также она поддерживает более 25,000 automated code reviews в неделю, более 300 playbooks и более 10,000 weekly invocations. Исходный материал не приводит детальных сравнительных метрик до и после, поэтому говорить о производительности или экономии в процентах нельзя. Но направление эффекта читается ясно: Flux перевёл агентные сценарии из локального эксперимента в управляемую платформу с изоляцией, аудитом и масштабированием на фоне.
На уровне архитектуры это типичный сдвиг от удобства разработчика к контролируемой платформе. Локальный запуск проще, но плохо масштабируется и слабее контролируется. Облачная модель сложнее в построении, зато лучше подходит для параллельного выполнения, безопасного доступа и наблюдаемой автоматизации. Именно поэтому подобные подходы всё чаще обсуждаются в индустрии вокруг coding agents и platform engineering.