Pipeline Triad Pattern: конвейер AI-агентов вместо команды разработки

Pipeline Triad Pattern: конвейер AI-агентов вместо команды разработки

TL;DR

Pipeline Triad Pattern – это не один AI-агент, а конвейер троек: Создатель, Критик и Арбитр. Каждая тройка закрывает свой этап SDLC, человек включается только в 4 контрольных точках, а сам паттерн лучше всего работает на типовых enterprise-задачах с формализованными правилами. Это не замена CI/CD, а слой агентного делегирования поверх обычной автоматизации. Главные ограничения – галлюцинации, качество промптов, оргпроцессы и безопасность самого конвейера.

Scope: не для discovery и не для MVP. Паттерн рассчитан на продукты с понятной архитектурой, зафиксированными стандартами и задокументированными бизнес-правилами. Чем чище вход, тем эффективнее конвейер.

Enterprise-разработка до сих пор устроена как конвейер из людей. Аналитик пишет постановку неделю. Разработчик кодит еще две. Ревьюер находит баги, возвращает. Тестировщик покрывает сценарии. Безопасник сканирует. Ops катит в прод. Между каждым этапом – ожидание, переключение контекста, больничные, отпуска, митинги. Типичная задача в банке добирается до прода за 2-3 месяца.

Я это видел изнутри на банковских проектах. И сейчас вижу, что в 2026 году тот же путь – от постановки до деплоя – для класса типовых enterprise-задач с формализованной логикой можно пройти за часы. Не одним волшебным агентом, а конвейером из троек агентов, где каждый этап защищен тройной валидацией, а человек контролирует процесс в четырех стратегических точках.

Я назвал это Pipeline Triad Pattern.

В предыдущей статье я описал Jarvis Pattern – манифест персонального агентного минимализма. Формула: LLM (мозг) + OS (руки) + файловая память (карта знаний) = полноценный специалист. Мой агент umax закрывает DevSecOps-задачи на mid-tier модели. Один агент в ряде инженерных контуров может закрывать работу одного специалиста.

Pipeline Triad – следующий шаг. Если Jarvis – это Джарвис конкретного Тони Старка, то Pipeline Triad – это конвейер таких джарвисов. Каждый специализирован, каждый знает свою роль, и вместе они закрывают весь SDLC – от аналитики до деплоя.

Рынок предлагает разные подходы к этой задаче. Devin и SWE-agent идут по пути единого агента-разработчика. Cursor и Copilot Workspace усиливают человека в IDE. CrewAI и LangGraph дают фреймворки для оркестрации мультиагентных систем. Pipeline Triad – не инструмент и не фреймворк, а паттерн организации процесса. Разница принципиальная: фреймворк устареет через год, паттерн останется. Его можно реализовать поверх любого из перечисленных инструментов.

Фундамент: на чем стоим

В конце 2025 года Antonio Gulli, Distinguished Engineer из офиса CTO Google, выпустил книгу “Agentic Design Patterns” (Springer, 424 стр.) – первую серьезную систематизацию паттернов проектирования AI-агентов. 21 паттерн, каждый с кодом и кейсами. Ключевой контрибьютор – Marco Fago, который делал код, диаграммы и ревью текста.

Параллельно свой взгляд дали Anthropic (“Building Effective Agents”), Lilian Weng из OpenAI (“LLM Powered Autonomous Agents”), и сам OpenAI выпустил “A Practical Guide to Building Agents”. Все работы приходят к одному выводу: базовые паттерны кристаллизовались. Фреймворки – разные холсты, а паттерны – одни и те же. Полный список источников – в конце статьи.

Не буду пересказывать 424 страницы. Для Pipeline Triad критичны шесть паттернов: Prompt Chaining (разбиение на мелкие шаги – LLM на маленькой задаче обычно работает лучше), Routing (условная логика – агент сам решает, куда двигать задачу), Parallelization (параллельное выполнение – на параллелизуемых задачах это дает выигрыш, но на последовательных reasoning-задачах может ухудшать результат; мультиагентность не бесплатна), Tool Use (вызов реальных инструментов – curl, git, сканеры безопасности), Memory Management (краткосрочная и долгосрочная память – те же markdown-файлы из Jarvis Pattern) и Reflection – самокритика.

На Reflection остановимся подробнее.

Почему тройка, а не один агент

LLM плохо находит ошибки в собственном ответе. Huang et al. (ICLR 2024) показали: без внешней обратной связи LLM в reasoning-задачах обычно плохо самокорректируется, а иногда даже деградирует. Это не абсолют – модель может поймать очевидную опечатку, но систематические ошибки в логике сама часто не видит. Anthropic в “Building Effective Agents” делают из этого практический вывод: один генерирует, другой оценивает, и процесс повторяется, пока результат не достигнет нужного качества.

Gulli формализует это как Producer-Critic. Один агент генерирует, второй критикует. Работает, но недостаточно. Критик тоже может ошибиться: быть слишком строгим, пропустить критическую проблему, зациклиться на мелочах.

Поэтому я добавляю третью роль – Арбитр. Независимый судья, который проверяет и Создателя, и Критика.

Принцип maker-checker-approver известен давно – в банковских процессах это стандарт. Новизна Pipeline Triad – в системном применении этого принципа ко всему циклу разработки, где каждая тройка специализирована под свой этап и работает с общей памятью.

Аналогия простая: разработчик пишет код, ревьюер находит проблемы, техлид принимает решение. Три роли, три точки зрения, минимизация ошибок. Только вместо трех людей, которые неделю согласовывают, – три агента за минуты.

Внутренний цикл тройки: Создатель -> Критик -> Арбитр.

“Это же просто CI/CD?” – нет

Важное различие.

Jenkins, GitLab CI, TeamCity – это автоматизация. Скрипт гоняет линтер, запускает тесты, собирает билд. Если тест упал, pipeline красный. Все детерминировано: одинаковый вход = одинаковый выход.

Pipeline Triad – это не автоматизация. Это делегирование.

Критик не просто запускает линтер. Он анализирует логику: “Здесь нет проверки прав доступа, а по регламенту эту операцию может вызывать только роль ACCOUNT_MANAGER”. Арбитр не просто проверяет чеклист. Он принимает решение: “Замечание Критика обосновано, возвращаю на доработку” или “Критик придирается к стилю, а код корректен, пропускаю”.

CI/CD выполняет инструкции. Тройка интерпретирует контекст и принимает решения в рамках заданных правил. Скрипт не может найти пропущенный бизнес-сценарий или заметить, что архитектурное решение противоречит стандартам компании. Агент в ряде случаев – может.

При этом Pipeline Triad не заменяет CI/CD, а включает его: на шагах 11 и 13 работает обычный автоматический pipeline. Агенты готовят, CI/CD катит.

Human-in-the-Loop: контроль без иллюзий

Gulli выделяет два режима. Human-in-the-Loop – человек проверяет, одобряет, корректирует. Human-on-the-Loop – человек задает стратегию, агент исполняет автономно в заданных рамках.

Pipeline Triad использует оба. Шаг 0 и Human Gates – это in-the-loop. Агентные этапы между gates – это on-the-loop: человек задал правила, описал скиллы агентов и критерии качества, тройка работает сама.

Gulli честно пишет про ограничения: люди не масштабируются, эффективность зависит от квалификации проверяющего, чувствительные данные нужно анонимизировать. Именно поэтому в Pipeline Triad четыре Human Gate, а не четырнадцать – человек стоит только там, где цена ошибки максимальна.

Доска: 14 шагов от идеи до прода

Зачем спринты, если есть поток

Спринты оптимизируют работу людей. Двухнедельные итерации, ретроспективы, velocity – все потому, что люди устают, болеют, переключают контекст. Agile – великая методология. Для людей.

Агенты не устают. Не болеют. Не переключают контекст, потому что у каждого свой контекст в памяти. Когда исполнители – агенты, координация упрощается.

Kanban – это про поток задач, а не про итерации. Задача поставлена – задача поехала. Следующая не ждет конца спринта. Для агентного конвейера это естественная модель. Agile не умирает – он упрощается до непрерывного потока.

Полная модель

Pipeline Triad: 14 шагов от идеи до прода

0. Создание задачи – Human. Формулируешь задачу и ставишь на доску. Качество постановки определяет качество всего конвейера. Garbage in – garbage out никто не отменял.

1. Аналитика – Тройка. Создатель читает требования, базу знаний, стандарты компании. Пишет техническую постановку. Критик ищет дыры: пропущенные сценарии, конфликты с архитектурой, неоднозначности. Арбитр решает, готова постановка или нет.

2. Валидация требований – Human Gate #1. Самый дешевый gate. Поймать ошибку в требованиях – часы. Поймать в коде – дни. Поймать в проде – месяцы и деньги.

3. Разработка – Тройка. Создатель пишет код. Критик с промптом “ты строгий Senior Developer” ищет баги, уязвимости, нарушения стиля. Арбитр принимает решение.

4. Code Review – Тройка. Ревью кода: архитектура, производительность, поддерживаемость. Если FAIL – возврат на шаг 3.

5. Тестирование – Тройка. Создатель генерирует и запускает тесты. Критик анализирует покрытие, ищет пропущенные сценарии. Агент может прогнать существенно больше техник параллельно и быстрее, чем это обычно делает один человек: boundary testing, mutation testing, property-based, fuzz testing.

6. Регрессия – Тройка. Полный набор тестов всей системы. Создатель запускает, Критик анализирует падения, Арбитр принимает решение.

7. Безопасность – Тройка. Сканирование кода и зависимостей на уязвимости: SAST, DAST, проверка сторонних библиотек на известные уязвимости. Критические уязвимости – блокер, возврат на разработку.

8. Одобрение готовности – Human Gate #2. Ответственный смотрит на результат всех этапов: код, тесты, безопасность. Дает добро.

9. Подготовка артефактов – Тройка. Релизная документация: план испытаний, протоколы приемки, пользовательская документация, release notes, нотификация заинтересованных. Критик проверяет комплектность. Арбитр подтверждает.

10. Одобрение деплоя – Human Gate #3. Команда эксплуатации подтверждает готовность инфраструктуры и наличие плана отката.

11. Деплой на staging – Авто. CI/CD разворачивает на тестовую среду.

12. Подтверждение прода – Human Gate #4. Проверка на staging: базовые сценарии работают, метрики в норме. В финтехе это обязательно. Цена ошибки в проде измеряется деньгами и репутацией.

13. Деплой в production – Авто. Раскатка в боевую среду.

Операционная модель конвейера

Pipeline Triad – это не просто набор ролей, а контракт исполнения. Каждый этап обязан производить формализованный артефакт, критерии приемки, журнал замечаний Критика и решение Арбитра. Следующий этап не начинает работу, пока не получил валидный пакет входа. Это превращает конвейер из набора промптов в воспроизводимый инженерный процесс.

Что это значит на практике. Каждый этап выдает:

• Артефакт – что именно выходит с шага. Шаг 1 выдает техническую постановку в формате: требования, API contract, бизнес-правила, edge cases. Шаг 3 выдает diff и описание изменений. Шаг 5 выдает отчет покрытия и список упавших тестов. Формат артефакта описан в скилле агента – тот же markdown, что и в Jarvis Pattern.

• Критерии PASS/FAIL – что считается успешным прохождением. Для аналитики: все сценарии покрыты, нет неоднозначностей, нет конфликтов с архитектурой. Для безопасности: нет critical/high уязвимостей. Для тестирования: покрытие не ниже порога, нет упавших тестов. Пороги задаются конфигурацией этапа.

• Trace – кто что предложил, кто что отклонил и почему. Создатель предложил X. Критик нашел проблему Y с обоснованием. Арбитр принял решение Z с причиной. Все пишется в лог этапа. Это не служебный мусор, а audit trail.

• Решение Арбитра – PASS, FAIL или PARTIAL. PASS – артефакт переходит дальше. FAIL – возврат с указанием причины. PARTIAL – артефакт проходит с замечаниями, которые нужно учесть на следующем этапе.

Куда это пишется. В простейшем случае – файловая структура в памяти агента, как в Jarvis Pattern. Для production – внешнее хранилище: Git для артефактов, лог-система для trace, dashboard для состояния доски.

Границы применимости

Pattern лучше всего работает там, где бизнес-правила уже описаны, стандарты известны, а результат можно проверить артефактами и тестами. Он хуже подходит для research-задач, слабо формализованных доменов и крупных межкомандных изменений, где основная проблема не в исполнении, а в неопределенности и согласовании.

Хорошо подходит: change requests и bugfixes, CRUD/API-endpoints, интеграции, инфраструктурные изменения, типовые enterprise-задачи с регламентом.

Плохо подходит: greenfield-архитектура без зрелых стандартов, R&D с неясной постановкой, cross-team крупные рефакторинги, домены, где часть знания живет в головах, а не в документах.

Пример: задача проходит через конвейер

Для тех, кто работает с банковским бэкендом, – конкретный прогон. Задача: добавить REST endpoint /api/v2/accounts/{id}/freeze для заморозки счета клиента. Типичная enterprise-задача средней сложности: нужно учесть бизнес-правила, безопасность и интеграцию с существующей системой.

Шаг 0. Архитектор ставит на доску: endpoint, бизнес-правила, ссылка на регламент заморозки.

Шаг 1. Аналитика. Создатель читает регламент, смотрит документацию существующих endpoints, пишет постановку: HTTP метод, формат запроса/ответа, бизнес-валидации, коды ошибок, требования к логированию. Критик: “Не описано поведение при частичной заморозке – что если на счету запланированные автоплатежи?” Арбитр подтверждает замечание, возврат. Второй проход – Создатель добавляет сценарий. Критик доволен. Арбитр пропускает.

Шаг 2. Human Gate. Архитектор: сценарий с автоплатежами учтен, все на месте, пропускаю. 15 минут.

Шаг 3. Разработка. Создатель пишет контроллер, сервис, слой работы с базой, миграцию. Критик: “Нет проверки прав доступа. Кто может вызывать freeze? Нужна авторизация по роли”. Цикл. Создатель добавляет. Критик: ОК. Арбитр пропускает.

Шаг 4. Code Review. Тройка проверяет именование, обработку ошибок, потокобезопасность, идемпотентность.

Шаг 5. Тестирование. Создатель делает модульные, интеграционные и негативные тесты. Критик: “Нет теста на гонку – два параллельных вызова freeze на один счет”. Цикл.

Шаги 6-7. Регрессия проходит. Сканер безопасности чисто.

Шаг 8. Human Gate. Архитектор проверяет итог: код, тесты, отчет безопасности. Все чисто. 20 минут.

Шаги 9-13. Документация, одобрение эксплуатации, staging, проверка, прод.

Итого, время человека: постановка (10 минут) + проверка требований (15 минут) + одобрение (20 минут) + одобрение деплоя и проверка staging (15 минут) = примерно 1 час.

В классическом enterprise та же задача обычно занимает 2-3 недели: аналитика, разработка, ожидание ревью, тестирование, безопасность, документация. Здесь – около часа человеческого времени плюс машинная работа конвейера.

Оговорка: эти цифры относятся к задачам, где бизнес-логика уже описана в регламенте и не требует длинных согласований. Если нужно получить одобрение юриста, compliance-офицера и трех аналитиков из разных подразделений, Pipeline Triad не телепортирует организационные процессы. Он ускоряет техническую работу.

Экономика: сколько стоит конвейер

Считать нужно в двух моделях – через API и через подписку.

Расчет через API

Один проход тройки – это три вызова LLM: Создатель, Критик, Арбитр. Каждый вызов – примерно 10-20K input и 2-5K output. При 2-4 проходах тройки на этап и 7 агентных этапах получаем 42-84 вызова на задачу.

Грубый расчет: примерно 1-2M input-токенов и 200-400K output-токенов. В денежном выражении для mid-tier модели это дает порядок $6-12 за полный прогон одной задачи.

Это оценка. Реальное потребление зависит от сложности задачи, размера контекста и количества возвратов на доработку. Для простых задач может быть $3-5, для задач с большим контекстом и множеством итераций – $15-20.

Расчет через подписку

Подписка почти всегда дешевле API, потому что субсидируется провайдером. Но там нет точной арифметики: лимиты плавают, задачи разные по тяжести, а интенсивность работы зависит от конкретного окна, модели и нагрузки.

Практически это означает одно: подписка удобна для пилотов, личного стенда и ограниченного числа досок. Для стабильного production-потока считать придется через API и ставить лимиты.

Сравнение

Типичная enterprise-команда на один продукт – это аналитики, разработчики, тестировщики, DevOps, безопасник, техлид, PM. Даже неделя работы такой команды – совсем другой порядок цифр. Задача, которая раньше занимала полкоманды две недели, здесь потенциально проходит через конвейер за обеденный перерыв.

Метрики качества

Экономика без KPI качества – это скорость в никуда. Четыре метрики, без которых паттерн нельзя считать production-ready:

• Lead time – от постановки задачи до staging/prod. Для типовой CRUD-задачи целевое значение – часы, не дни.

• Rework rate – доля возвратов между шагами. Если 80% задач возвращаются с разработки на аналитику, проблема в постановке или в скилле тройки аналитики.

• Defect escape rate – баги, прошедшие через конвейер и обнаруженные в проде. Главная метрика качества.

• Human touch time per task – сколько реального времени человек потратил на задачу: постановка, валидация, одобрения.

Cost per task отслеживается как финансовая метрика, но не является KPI качества. Дешевый плохой результат хуже дорогого хорошего.

Где это ломается

LLM галлюцинирует бизнес-логику. Агент может выдумать правило, которого нет в регламенте. Тройка снижает риск, но не устраняет полностью.

Стоимость ошибки на ранних этапах. Если тройка на аналитике приняла неверное архитектурное решение и Human Gate это пропустил, все последующие этапы будут делать идеально, но не то.

Зависимость от качества промптов. Скилл каждого агента – что он делает, на что смотрит, какие критерии – это тонкая работа. Плохо описанный Критик будет либо пропускать все, либо заворачивать все.

Организационные процессы никуда не деваются. Конвейер ускоряет техническую работу. Совещания, согласования и политика остаются.

Стоимость при масштабе. $6-12 на задачу по API – недорого. Но 20 досок по 50 задач в неделю – это уже заметные деньги на токены. Все равно дешевле зарплатного фонда, но бюджетировать это придется.

Безопасность конвейера

Блок “безопасность” на шаге 7 – про продукт. Но кто защищает сам конвейер? Если агент имеет доступ к репозиторию, CI/CD и секретам, это отдельная attack surface.

Изоляция агентов по правам. Создатель пишет код, но не мержит в main. Критик читает код, но не меняет. Арбитр принимает решение, но не трогает файлы. Least privilege обязателен.

Read/write scope по репозиториям. Агент аналитики читает регламенты и стандарты, но не имеет доступа к исходникам. Агент разработки работает в feature-branch, не в main.

Запрет прямого доступа к проду. Даже агент деплоя не катит напрямую. Он инициирует CI/CD pipeline, который выполняет реальную работу. Секреты живут в CI/CD, не в памяти агента.

Audit log всех действий. Каждый вызов инструмента, каждое чтение файла, каждая команда – логируются. Это нужно не для паранойи, а для postmortem.

Policy engine над tool use. Перед вызовом инструмента policy engine проверяет, имеет ли агент с этой ролью право на этот инструмент в этом контексте. Это не промпт-ограничение, а enforce на уровне оркестратора.

Data classification. Не все данные можно отдавать модели. PII, credentials, коммерческая тайна должны быть отфильтрованы до попадания в контекст агента.

Без этого любой безопасник скажет: “Красиво, но вы просто вынесли supply chain risk внутрь LLM-оркестратора”. И будет прав.

Откат и инциденты

Путь до деплоя описан. Пути назад – нет. А это пробел.

Кто инициирует rollback. В модели Pipeline Triad – только человек. Если после релиза пошла деградация метрик, Ops инициирует rollback.

Делает ли это агент. Нет. Но тройка может участвовать в postmortem: анализировать trace, искать, какой этап пропустил проблему, и готовить fix-forward.

Что происходит при деградации. Мониторинг детектит аномалию. Ops получает алерт. Если решение – rollback, CI/CD откатывает на предыдущую версию. Конвейер на это время ставится на hold.

Postmortem. Тройка анализирует incident report, diff, trace, метрики до и после. Результат – обновление скиллов ответственного этапа. Так замыкается цикл улучшения конвейера.

Оркестрация задач

При масштабировании на одну кодовую базу едут несколько задач, и сразу возникают конфликты.

• Конфликт контекстов – пока задача А прошла аналитику, задача Б уже изменила код. Контекст задачи А устарел.

• Гонка за shared memory – агенты читают и пишут в общую базу знаний. Нужна версионность или optimistic locking.

• Конфликт миграций – две задачи добавляют колонки в одну таблицу.

• Конфликт release branch – одна ветка мержится первой, вторая должна rebaseиться.

• Устаревание артефакта – артефакт с шага 3 может стать невалидным к моменту шага 8, если другие изменения уже уехали вперед.

Решение – orchestration layer над доской. Не отдельный супер-агент, а набор правил: lock на файлы или модули при активной задаче, rebase и revalidation при конфликте, dependency graph между задачами. Это не rocket science, но без этого enterprise-масштабирование не работает.

“А покажи работающую доску”

Справедливый вопрос. Pipeline Triad на момент публикации – это паттерн, проверенный на отдельных этапах на моем стенде. Агент umax из Jarvis Pattern закрывает DevSecOps-этапы конвейера: безопасность, CI/CD, инфраструктура. Тройка Создатель-Критик-Арбитр обкатана на аналитике и code review.

Полный конвейер из 14 шагов с работающей доской – следующий шаг.

Публикую это как паттерн, а не как готовый продукт, потому что архитектура процесса важнее конкретной реализации. Jarvis Pattern тоже начинался как манифест, а потом быстро превратился в рабочую систему. Здесь логика та же.

Масштабирование: от одной доски до предприятия

Одна тройка на этапе – минимум. Для крупного enterprise это выглядит так:

• 10 Создателей параллельно работают над 10 задачами

• 10 Критиков параллельно проверяют

• 10 Арбитров параллельно принимают решения

Одна доска = один продукт или сервис. 20 продуктов = 20 досок. 24/7. Без перерывов. Утром на доске уже лежат готовые артефакты, ждущие одобрения на Human Gate.

Параллелизация работает для независимых задач. Задачи с зависимостями требуют оркестрации: SLA между задачами, приоритизация через человека, merge-стратегии. Это отдельная тема, выходящая за рамки статьи.

Основная работа при масштабировании – не код, а описание скиллов: что делает каждый агент, куда смотрит, куда пишет, куда коммитит. Те же markdown-файлы из Jarvis Pattern, только для каждой роли в тройке.

Минимальная команда

Вот во что превращается штат при Pipeline Triad:

Архитектор/техлид (1 человек). Ставит задачи, валидирует требования, одобряет готовность. Это человек, который видит картину целиком, понимает бизнес-контекст и может быстро оценить, правильно ли тройка поняла задачу.

Ops/эксплуатация (1 человек). Одобряет деплой, проверяет staging, отвечает за инфраструктуру, rollback и мониторинг в проде.

Бизнес-аналитик (опционально, для сложных доменов). Если продукт работает в тяжелом регулировании, нужен человек, который проверяет бизнес-логику на шагах 2 и 8.

Итого: 2-3 человека.

Не потому, что остальные не нужны. Их работу выполняет конвейер. Но эти 2-3 человека должны быть сильными. Джуниор не потянет роль единственного архитектора на конвейере из 7 агентных этапов. Здесь нужен Senior+, который видит систему целиком и может за 15 минут оценить, правильно ли агенты отработали. Pipeline Triad не снижает требования к людям. Он радикально снижает их количество.

Что нужно для production-grade внедрения

Чеклист. Без любого из пунктов это прототип, не production.

• Skill catalog – описанные скиллы для каждой роли в тройке на каждом этапе.

• Policy engine – права доступа агентов к инструментам, репозиториям, секретам.

• Artifact schema – формат артефакта на каждом этапе.

• Eval harness – набор эталонных задач с известными ответами.

• Audit log – полный trace всех действий агентов.

• Rollback policy – кто инициирует откат, как он выполняется, что в это время делает конвейер.

• Cost guardrails – лимиты на токены per task, per board, per day.

Без этого агентный контур останется демо-стендом.

Когда бутылочное горлышко уже не в разработке, а в людях

Есть еще один эффект, который неочевиден, пока не увидишь его вживую. Когда технический контур резко ускоряется, организация не успевает адаптироваться к новой скорости.

Проблема уже не в том, что аналитика, код, тесты и деплой идут слишком медленно. Проблема в другом: люди не успевают формулировать задачи, приоритизировать backlog, валидировать результат и перестраивать roadmap под новый темп. Найти специалистов, которые понимают, как работать с таким контуром, тоже непросто. Обучить можно, но организационная адаптация все равно идет медленнее, чем сам конвейер.

На практике это выглядит непривычно: за несколько недель закрывается объем работ, который раньше растягивался на месяцы. В какой-то момент бутылочное горлышко смещается из engineering в управление продуктом и изменениями. Конвейер не упирается в код. Он упирается в способность людей успевать придумывать, отбирать и подтверждать следующие задачи.

В пределе это дает странный для классического enterprise эффект: продуктовый backlog заканчивается быстрее, чем организация успевает произвести новый. И это уже не проблема разработки, а проблема управления скоростью.

Заключение

В Jarvis Pattern я писал: человек остается в центре. Не как оператор при машине, а как инженер, которому машина подчиняется. Pipeline Triad не меняет эту позицию – он масштабирует ее.

Эволюция простая: один агент закрывает один инженерный контур. Тройка агентов закрывает один этап с тройной валидацией. Конвейер троек закрывает весь цикл разработки – от аналитики до деплоя.

Через полгода выйдут новые модели. Через год – новое железо. Уже сейчас mid-tier модели хватает, чтобы закрывать существенную часть инженерной работы. Следующий логичный шаг очевиден: собирать из таких агентов не помощников, а полноценный конвейер разработки.

Фреймворки приходят и уходят. Паттерны остаются. Pipeline Triad можно реализовать на чем угодно: LangGraph, CrewAI, Nanoclaw, скриптах и API. Важна архитектура процесса, а не конкретный инструмент.

Pipeline Triad пока не продукт, а паттерн. Но если Jarvis показал, что один агент может закрывать работу одного специалиста, то следующий шаг уже не выглядит фантастикой.

Источники

1. Antonio Gulli (Google, Office of CTO) – “Agentic Design Patterns: A Hands-On Guide to Building Intelligent Systems”, Springer, 2025. Marco Fago – ключевой контрибьютор. https://link.springer.com/book/10.1007/978-3-032-01402-3

2. Erik Schluntz, Barry Zhang (Anthropic) – “Building Effective Agents”, декабрь 2024. https://www.anthropic.com/research/building-effective-agents

3. Lilian Weng (OpenAI) – “LLM Powered Autonomous Agents”, июнь 2023. https://lilianweng.github.io/posts/2023-06-23-agent/

4. OpenAI – “A Practical Guide to Building Agents”, апрель 2025. https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf

5. Google Research + DeepMind + MIT – “Towards a Science of Scaling Agent Systems”, 2024

6. Jie Huang et al. – “Large Language Models Cannot Self-Correct Reasoning Yet”, ICLR 2024

7. Егор Зиновьев – “Jarvis Pattern: почему AI-агенту не нужен фреймворк, а нужна операционная система”, zinovev.org, 2026. https://zinovev.org/post/jarvis-pattern

Егор Зиновьев – IT-архитектор. Исследует и проектирует AI-агентов, занимается IT-аудитом и архитектурой. Автор концепций Jarvis Pattern и Pipeline Triad Pattern.

Связь: zinovev.org