Агенты в SDLC энтерпрайза: как не потерять архитектуру по дороге

В большом Enterprise над одним продуктом работают несколько команд и несколько ролей, а вокруг него — десятки связанных систем. Отсюда проблемы, которых нет у небольшой команды.

• Решение проходит цепочку «бизнес-аналитик → архитектор → системный аналитик → разработка» и на каждой передаче искажается.
• Изменение в одном домене задевает соседние команды и интеграции. Выяснить, кого именно, удаётся только серией встреч.
• Знание о продукте лежит в вики, каталоге архитектуры, коде и головах, и эти источники расходятся между собой.
• Процессы и регламенты описаны, но под срок шаги пропускаются, и заметить это некому.
• ИИ-агенту в таком ландшафте не хватает контекста: корпус знаний многократно больше того, что модель может прочитать, а выбрать нужную часть заранее некому.

Готовых решений для этого нет. Существующие инструменты и фреймворки для работы с агентами рассчитаны на одного разработчика и один репозиторий. Для цепочки ролей, нескольких команд и связанных систем мы собрали свой фреймворк — Genome — и применяем его на платформе B2B-продаж: 12 доменов, 3 команды, десятки интеграций.

Что будет в докладе

• Как Genome раскладывает знание о большом продукте: домены, владельцы, связи с соседними системами и каталогом архитектуры компании.
• Как агент получает контекст под конкретную задачу, когда всё знание в него не помещается.
• Как устроена передача между ролями: что проверяет скрипт, что агент, что принимает человек, и что происходит при расхождении с принятым решением.
• Как правила процесса становятся машинными проверками.
• Показ в терминале: один эпик от запроса бизнеса до контракта между командами.
• Что уже работает, что ещё обкатываем и чем собираемся измерять эффект.

Что вы сможете применить у себя после выступления

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

Подход не привязан к конкретной модели или инструменту, его можно переносить на свой стек по частям.