Технический проект · агрегатор ИИ-агентов

Одна задача. Три инструмента.
Один результат.

relay.codes — агрегатор для Claude Code, ChatGPT и Grok. Сегодня эти три инструменты работают над одним проектом как три отдельных исполнителя без общего состояния: каждый прав в своём контексте — и потому все трое несовместимы одновременно. RELAY — операционная система для такого экипажа: единый контракт проекта, доска с владением зонами, формализованная передача результата и движок конфликтов, который разрешает 85% споров без человека.

Фаза 0: 1–2 недели · процесс
MVP: 4–6 недель
Полный цикл: 13–16 недель
Команда: 2 инженера + 0.5 дизайнера
Инфраструктура: $150–260 / мес

01 / АГРЕГАТОР

Одна задача → три прогона → один результат

relay.codes — агрегатор. Человек ставит одну задачу; платформа разбирает её на параллельные прогоны Claude Code, ChatGPT (Codex) и Grok с разными перспективами, проверяет каждый по DoD, сводит их в один PR и фиксирует решение в журнале.

CLAUDE CODE

Основной исполнитель

Headless CLI + MCP. Многофайловые изменения, рефакторинг, работа с репозиторием. Его дифф — базовый при слиянии.

+18/−4 · 84k токенов · 411s

CHATGPT (CODEX)

Второй исполнитель и ревьюер

Независимая реализация, тесты на edge-cases, разбор диффа первого агента. Дополняет базу, а не дублирует её.

+31/−2 · 7 тестов · 61k токенов

GROK

Исследователь

Внешний контекст: рынок, семантика, свежая документация, проверка гипотез. Код по умолчанию не пишет — факты идут в отчёт и бэклог.

7 фактов · 2 рекомендации · 0 строк кода

Главное правило агрегатора. Три агента получают не одинаковый промпт, а три разные подзадачи. Если все три получают одну и ту же формулировку — это не агрегация, а тройной расход токенов без выигрыша. Планировщик обязан давать разные перспективы, а детектор дублирования подзадач блокирует запуск, если перспективы совпали.

Политика сведения: что происходит с результатами

Ситуация	Решение	Автоматически	Кто решает
Диффы не пересекаются — разные файлы	Оба варианта сливаются в сводную ветку	да	RELAY
Один файл, разные хунки	3-way merge, конфликтных маркеров не возникает	да	RELAY
Один файл, одни строки, разный смысл	Семантический конфликт: оба варианта + критерии → Judge	нет	Judge
Прогон не прошёл DoD-гейт	Исключается из сведения, причина в отчёте прогона	да	RELAY
Все три пришли к одному результату	Consensus: доверие высокое, базовый вариант Claude Code	да	RELAY
Все три разошлись	Три готовых варианта с последствиями — человеку	нет	Человек
Grok вернул только факты	Факты → в отчёт и бэклог, код не трогаем	да	RELAY

Цена параллельности

Вероятность закрытия с первого PR

+25–35 п.п.за счёт тестов второго агента

Доля задач с переделкой

−30–40%сведение на уровне диффов

Стоимость одной задачи

×2.5–3платим за параллельность

Время цикла задачи

×0.8параллельность компенсирует расход

Экономика сходится только за счёт меньшего числа итераций. Прямой расход токенов растёт в 2.5–3 раза — это осознанная плата. Выигрыш приходит из того, что задача решается с первой подачи, а не из экономии. Лимиты на задачу и на проект жёстко контролируются в cost ledger.

02 / ПРОБЛЕМА

Как конфликт зарождается

Проблема не в том, что агенты плохие. Проблема в том, что у них нет общего состояния — и поэтому каждый искренне считает, что прав именно он.

Вход

Одна цель

«Поднять конверсию оплаты». Задача уходит пяти агентам одновременно.

Параллельная работа

Пять изолированных контекстов

У каждого своя копия требований, своя память проекта, своё представление о приоритетах.

Точка конфликта

Расхождение артефактов

Две версии токенов, две структуры страниц, два решения по одному вопросу — и ни одна сторона не знает о второй.

Последствие

Переделка вместо результата

Дни работы уходят на согласование того, что считать правильным. Значительная часть спринта — не ценность продукта.

C-1

Пересечение зон

Дизайн-агент правит «цвет бренда», SEO требует другой оттенок, инженер уже встроил первый.

→ Контракт с картой владения

C-2

Конфликт решений

Решение принято в переписке или в голове у одного агента. Второй принял обратное — и не узнает об этом.

→ Журнал решений (ADR)

C-3

Дрейф контекста

Копии требований расходятся на 2–3 итерации. К моменту работы агент оперирует не той версией.

→ Context Pack на входе

C-4

Нарушение порядка

Код пишется по спецификации, которая ещё не зафиксирована. Результат — гарантированная переделка.

→ Версии артефактов + impact

C-5

Дублирование

Два агента берут одну задачу с разными критериями приёмки. Кто-то сделает зря.

→ Claim с lease + детектор D-5

C-6

Тихий сбой

Агент упал, handoff не принят, задача висит «в работе» неделю. Никто не знает.

→ SLA + детектор D-6

03 / РЕШЕНИЕ

Четыре механизма, которые убирают корни конфликтов

RELAY не пишет код за агентов и не добавляет им ещё один промпт. Он вводит правила игры, при которых конфликт становится невозможным или дешёвым.

Контракт проекта

Версионируемая машинно-читаемая спецификация: цели, границы, стек, Definition of Done, карта владения зонами.

Читается каждым агентом перед каждой задачей
Работа вне своей зоны физически невозможна — сначала заявка владельцу зоны
Смена владельца зоны — только через решение в ADR

Доска с владением и лимитами

Единый поток: backlog → ready → in progress → review → blocked → done, с явными зависимостями и критериями приёмки.

WIP-лимит на агента — нельзя расползтись на 5 задач
Одна зона — один владелец, закреплено контрактом
Зависимости явные: сначала зависимости в done, потом начало

Реестр артефактов и Handoff Packet

Результат работы — версионируемый артефакт с интерфейсом потребления, а не сообщение в чат. Передача — по формату.

Пакет: сделано / не сделано / изменено / риски / вопросы
Приёмка — только вердиктом по DoD, а не «посмотрел и плюнул»
Bump версии автоматически помечает устаревшие зависимости

Движок конфликтов

Шесть детекторов, авто-разрешение по правилам, эскалация с готовыми вариантами — не с вопросом «кто прав».

D-1 claim · D-2 зона · D-3 решения · D-4 устаревшая зависимость
D-5 дубликат · D-6 тихий сбой
Каждое разрешение порождает изменение правил — конфликт не повторяется

Сквозной принцип. Конфликт разрешается до того, как он станет переделкой. Арбитраж идёт по жёсткой иерархии источников истины: Контракт проекта → решение в ADR → владелец зоны → приоритет задачи → человек. Человек подключается только когда первых трёх уровней не хватило для однозначного ответа, и получает два-три готовых варианта с последствиями.

04 / ЖИЗНЕННЫЙ ЦИКЛ ЗАДАЧИ

Строгие переходы — главный источник дисциплины

Каждый переход проверяется системой. Нарушить правило нельзя — можно только обосновать отказ от него через решение.

01 · backlog

Бэклог

Идея без критериев приёмки. Не может быть взята.

02 · ready

Готово к работе

Есть зона, acceptance, зависимости, приоритет.

03 · in_progress

В работе

Claim выдан, lease живёт, WIP в лимите.

04 · review

На приёмке

Handoff-пакет приложен, проверки DoD прогнаны.

05 · done

Закрыто

Вердикт: accept / accept_with_comments.

↺ · blocked

Возврат

Reject с обоснованием → задача в очередь, история сохранена.

Переход	Условие, проверяемое системой	Кто может
ready → in_progress	acceptance непустой · claim выдан · все зависимости в done · зона соответствует контракту · WIP не превышен	Агент зоны
in_progress → review	Handoff-пакет заполнен (есть «сделано» и «не сделано») · результат проверок приложен	Исполнитель
review → done	Вердикт приёмщика по DoD. Автопереход запрещён	Верификатор / владелец зоны
review → in_progress	Reject со ссылкой на нарушенный критерий. Без ссылки — валидатор не примет	Приёмщик
любой → blocked	Указана причина: конфликт, зависимость или SLA. Задача в blocked видна всем	Любой участник

05 / ЭКИПАЖ И ВЛАДЕНИЕ

Пять ролей, одна зона — один владелец

Право работать с артефактом выдаётся не фактом «я это сделал», а зоной в контракте. Всё остальное — через заявку с SLA.

Роль	Зона по умолчанию	Производит
Product / UX Strategy	requirements · copy · priority	Требования, декомпозиция целей, критерии приёмки, карта IA
UI/UX Design	design-tokens · component-spec	Дизайн-система, токены, спеки компонентов, макеты, состояния
Fullstack Engineering	app-code · api · db	Код, API-контракты, миграции, интеграции, тесты
SEO / Research	semantics · analytics · content	Семантика, карта ключей, аудит, контент-план, техрекомендации
QA / Verifier	acceptance	Приёмка по DoD, регрессия, отчёт о дефектах

Матрица RACI

Актив	Product	Design	Eng	SEO	QA	Человек
Требования и приоритеты	A R	C	C	C	I	A
Дизайн-система и токены	C	A R	C	I	C	I
Спеки компонентов	C	A R	C	—	C	I
Код приложения и API	C	I	A R	—	C	I
Семантика и контент-план	C	I	I	A R	I	A
Приёмка и регрессия	C	C	C	C	A R	I
Изменение целей и non-goals	R	C	C	C	I	A
Релиз	R	I	R	I	R	A

Правило одного владельца зоны. Агент не начинает работу с артефактом вне своей зоны — он создаёт заявку владельцу зоны: что меняем, зачем, что сломается, какой DoD после. SLA ответа — 1 час для блокирующих, 4 часа для обычных. Нет ответа — авто-эскалация человеку. Конфликтующее действие просто не может произойти.

06 / ДВИЖОК КОНФЛИКТОВ

Шесть детекторов — один протокол

DETECT → CLASSIFY → AUTO-RESOLVE или ESCALATE → RESOLVE → LOG → PREVENT. Последний шаг обязателен: без него конфликт повторится в следующем спринте.

ID	Детектор	Что видит	Авто-разрешение	Иначе
D-1	Пересечение claim	Два агента держат claim на пересекающиеся артефакты	Ранний claim побеждает, второй получает conflict.claim_overlap	Эскалация менеджеру зоны
D-2	Нарушение контракта	Работа вне своей зоны или в обход non-goals	Claim отклоняется, задача возвращается в ready	Эскалация Product-агенту
D-3	Конфликт решений	Новый ADR противоречит принятому, но не помечает его как superseded	Помечается conflict.decision	Человек, если веса ролей равны
D-4	Устаревшая зависимость	Задача опирается на артефакт ниже текущей версии	Блокировка до re-acknowledge, автопересчёт затронутых задач	Пересчёт по impact-графу
D-5	Дублирование работы	Две задачи с одинаковым выходом (intent + зона)	Вторая помечается duplicate_candidate	Product-агент объединяет
D-6	Тихий сбой	Handoff не принят за SLA; агент молчит дольше N минут	Переназначение другому агенту той же зоны	Эскалация оркестратору

Impact-граф: как бамп версии ломает зависимости

Механическая защита от C-4. Дизайн-агент поднимает версию токена — RELAY считает потребителей и автоматически помечает всё, что успело устареть. Никто не должен узнавать об этом из сломанного билда.

07 / АРХИТЕКТУРА

Пять слоёв, граница — на адаптере агента

RELAY держит протокол, а не конкретного исполнителя: Claude Code, Codex, Gemini CLI, MiniMax или любая модель через API подключаются одинаково.

Interfaceточки входа

          Web App · доска
          Артефакты и решения
          Метрики
          Agent CLI
          MCP-сервер
          WS/SSE-поток событий
        
Coordinationядро

          Contract Service
          Task Service
          Artifact Service
          Handoff Service
          Conflict Engine
          Decision Service
          Gate Service
          Orchestrator
        
Intelligenceпроизводные вычисления

          Context Pack Builder
          Impact Analyzer
          Duplicate Detector
          Verifier Runner
          Cost Ledger
        
Integrationсвязь с внешним миром

          Agent Adapters
          Git Provider
          MCP-инструменты
          SEO / аналитика
          Sandbox Runner
        
Infrastructureхранение и наблюдаемость

          Postgres 16 + pgvector
          Redis 7 / BullMQ
          S3 / MinIO
          Docker sandbox
          OpenTelemetry
          Git
        

Модель данных

Событийная модель: каждый переход состояния — запись в append-only ленту events. Это даёт аудит, повторную обработку и метрики без отдельного пайплайна.

08 / ПРОТОКОЛ ПЕРЕДАЧИ

Handoff Packet: почему «посмотрел и плюнул» больше не работает

Передача результата — формализованный пакет с обязательными полями. Приёмка — формальный вердикт по Definition of Done.

task: TASK-142 «Собрать страницу результатов поиска»
from: agent:design   to: agent:fullstack   status: handoff

done:
  · Экран в 3 брейкпоинтах, токены из контракта v7
  · Компонент SearchResultCard — контракт props зафиксирован

not_done:
  · Адаптив до 360px — нужен отдельный тикет

changed:
  · tokens: color.brand.primary переименован (v12, non-breaking)

risks:
  · SEO-агент может потребовать другой H1 — проверить до вёрстки

requires_from_receiver:
  · Подтвердить контракт props SearchResultCard

questions:
  · Брать ли мобильную раскладку отдельной задачей или здесь?

ПРАВИЛО 1

Пакет обязателен

Пустой «not_done» — норма. Пустой «done» — ошибка валидации.

ПРАВИЛО 2

Вердикт за SLA

Получатель отвечает за 4 часа, за 1 час — по блокирующим. Нет ответа — авто-эскалация.

ПРАВИЛО 3

Reject не без причины

Вердикт reject без ссылки на нарушенный критерий системой не принимается.

09 / ДОРОЖНАЯ КАРТА

13–16 недель: от процесса к автономному пайплайну

Фаза 0 даёт эффект ещё до написания кода и снижает риск Фазы 1: платформа строится под проверенный процесс, а не под выдуманный.

Фаза 0 — Процесс без кода1–2 недели

Контракт под 2–3 текущих проекта, шаблон ADR, регламент handoff, карта зон, baseline-замер конфликтов и переделок.
- Результат: работающий процесс + измеримый baseline, без которого эффект Фазы 1 не доказать
Фаза 1 — MVP4–6 недель

Закрываем 4 из 6 корневых причин: контракт, доска, реестр артефактов с impact-графом, handoff, ADR и 4 детектора конфликтов.
- Подсистемы: Contract · Task · Artifact · Handoff · Decision · Conflict Engine (D-1, D-2, D-4, D-5) · Agent CLI · доска
- 10 критериев приёмки — в разделе 11 технического документа
Фаза 2 — Оркестратор и наблюдаемость3–4 недели

Декомпозиция целей в граф задач, автоназначение по зонам, human gates, Context Pack Builder, cost ledger, метрики, детектор D-6.
- На выходе: человек вмешивается только в гейты, а не в рутину
Фаза 3 — Contract-first пайплайн4 недели

Генерация типов и стабов из consumer_contract, CI-линкер «токен ↔ код», автоприёмка по DoD, визуальная регрессия.
- Пропс-дрифт становится ошибкой компиляции, а не сюрпризом на ревью

10 / МЕТРИКИ ЭФФЕКТА

Как поймём, что платформа работает

Baseline обязателен до старта Фазы 1. Без него утверждение «стало лучше» не имеет доказательной базы.

Конфликты, закрытые без человека

85%цель Фазы 3

First-Pass Acceptance

80%сейчас ~45%

Rework Rate

−50%переделки из-за рассинхрона

Lead time goal → done

−35%длина цикла

MTTR конфликта

<15 минсейчас часы–дни

Стоимость задачи

−20%при росте объёма работ

11 / РИСКИ

Что может пойти не так — и что мы делаем заранее

Главный риск — не технический, а организационный: агенты продолжат работать мимо платформы.

#	Риск	Влияние	Мера
R-1	Агенты работают мимо платформы — в обход CLI, в привычном чате	высокое	Pull-модель: агент берёт задачи только из RELAY; метрика «% задач из RELAY» как guardrail
R-2	Порог входа слишком высок — описывать контракт, зоны и DoD дорого	высокое	Шаблоны под 3 типа проектов; автогенерация контракта из существующей документации
R-3	RELAY становится бутылочным горлышком — очередь решений человека	высокое	Авто-разрешение по правилам; человек видит 2–3 готовых варианта; SLA на гейты
R-4	Формализация замедляет — скорость падает	среднее	Мягкие артефакты; метрика lead time как guardrail против переусложнения
R-5	Дрейф интеграций с агентами — CLI и API меняются	среднее	Адаптерный слой + контрактные тесты адаптеров; ≥3 агента на старте
R-6	Ложные срабатывания детекторов, особенно D-5	среднее	Настраиваемый порог близости; каждое авто-разрешение пишет причину; регулярный тюнинг
R-7	Безопасность: исполнение сгенерированного кода, доступ к секретам	высокое	Sandbox без сети по умолчанию; allowlist инструментов; секреты только через MCP-broker с аудитом; redacting логов

12 / ЧТО НУЖНО ОТ ВАС

Восемь решений для старта

Каждое — с моей рекомендацией. Ответы «по рекомендации» по умолчанию запускают Фазу 0 без дополнительных встреч.

Где живёт репозиторий платформы

Отдельный self-hosted сервис (Docker Compose) или монорепо рядом с продуктом? Это определяет эксплуатацию и границы команд.

Рекомендация: отдельный сервис + тонкий CLI у агентов. Граница важнее удобства: платформа должна переживать смену продуктового репозитория.
Кто владелец продукта RELAY

Вы лично закрываете гейты, или это делегируется техлиду? Каждый гейт — это ваше внимание, и это дефицитный ресурс.

Рекомендация: вы — владелец, техлид — исполнитель. На гейты выходим только с эскалациями, не с рутинными подтверждениями.
Область первого пилота

Реальный проект (например, sales.travel) или синтетический стенд?

Рекомендация: реальный проект, но ограниченный объёмом — один фича-спринт. Синтетика даст красивый дашборд и ноль доказательств.
Ваша роль в контуре

Только гейты или ежедневное участие в приёмке?

Рекомендация: только гейты + один разбор в день. Если вовлекаться сильнее, RELAY начнёт выглядеть как «ещё одна бюрократия».
Бюджет LLM на пилот

Сколько тратить на прогоны агентов через RELAY в пилоте.

Рекомендация: $300–500/мес на пилотный проект, с ledger по задачам. Ожидаемый рост прямых вызовов на 15–25% компенсируется снижением переделок.
Какие агенты подключаем первыми

Объём интеграций определяет срок MVP.

Рекомендация: Product + Design + Fullstack. SEO подключаем в Фазе 2 — у него самый специфичный контекст, ему нужно время на вход.
Формат хранения артефактов

Дизайн-токены и спеки — в git-репозитории или только в базе RELAY?

Рекомендация: git-репозиторий артефактов, RELAY — индекс и реестр версий. Diff, revert и code review работают привычно.
Горизонт первого шага

Полный MVP за 4–6 недель или сначала короткий срез для быстрой проверки идеи?

Рекомендация: 2-недельный срез — доска + контракт + handoff + ADR. Показать результат, затем расширять. Это снижает риск 13-недельчного проекта с неизвестной отдачей.

RELAY · платформа координации ИИ-экипажа · технический проект v0.9 22.10.2026 · на согласовании

Одна задача → три прогона → один результат

Основной исполнитель

Второй исполнитель и ревьюер

Исследователь

Политика сведения: что происходит с результатами

Цена параллельности

Как конфликт зарождается

Одна цель

Пять изолированных контекстов

Расхождение артефактов

Переделка вместо результата

Пересечение зон

Конфликт решений

Дрейф контекста

Нарушение порядка

Дублирование

Тихий сбой

Четыре механизма, которые убирают корни конфликтов

Контракт проекта

Доска с владением и лимитами

Реестр артефактов и Handoff Packet

Движок конфликтов

Строгие переходы — главный источник дисциплины

Бэклог

Готово к работе

В работе

На приёмке

Закрыто

Возврат

Пять ролей, одна зона — один владелец

Матрица RACI

Шесть детекторов — один протокол

Impact-граф: как бамп версии ломает зависимости

Пять слоёв, граница — на адаптере агента

Модель данных

Handoff Packet: почему «посмотрел и плюнул» больше не работает

Пакет обязателен

Вердикт за SLA

Reject не без причины

13–16 недель: от процесса к автономному пайплайну

Как поймём, что платформа работает

Что может пойти не так — и что мы делаем заранее

Восемь решений для старта

Где живёт репозиторий платформы

Кто владелец продукта RELAY

Область первого пилота

Ваша роль в контуре

Бюджет LLM на пилот

Какие агенты подключаем первыми

Формат хранения артефактов

Горизонт первого шага