Cross-org agent negotiation: два агента согласуют спеку через корпоративный firewall

Проблема

Классический сценарий интеграции двух систем разных компаний (интернет-магазин ↔ ERP партнёра): встречи, переписка, ручное ведение OpenAPI-спеки, недели на согласование полей и контрактов.

Большинство multi-agent дискуссий в индустрии сейчас про агентов внутри одной организации или системы. Межорганизационное согласование агентами — почти не проработанная парадигма.

Методика

Эксперимент: посадить двух AI-агентов в диалог, где они сами вырабатывают интеграционную спеку.

1. Постановка. Каждый агент представляет свою сторону (e-commerce и ERP), знает ограничения своей системы.
2. Диалог. Агенты обсуждают контракт, согласуют типы полей, операции, примеры — chat-history.txt фиксирует переговоры.
3. Артефакт. Из диалога рождается openspec.yaml (OpenAPI). Git-коммиты соответствуют вкладу каждого агента и ревизиям спеки — видна «совместная работа», а не один монолитный вывод.
4. Граница (firewall). Ключевой архитектурный вопрос — что именно может пересекать границу организации: не сырые данные систем, а только согласуемый контракт. Trust model строится на уровне спеки, не на уровне доступа к системам.

Фрагмент переговоров

из chat-history.txt

Bitrix_Lead_Bot

Начнём с POST /orders. Bitrix отправляет заказ — ERP принимает.

ERPSYS_Head_Bot

Принято. Но productId в OrderItem — только внутренний ERP-идентификатор. Ваши артикулы нас не интересуют.

Bitrix_Lead_Bot

Понял. Как тогда Bitrix получает ваши ID? Нужна синхронизация номенклатуры с вашей стороны.

ERPSYS_Head_Bot

ERP — источник истины. Мы не можем реализовать push-синхронизацию ID из ERP. Bitrix должен самостоятельно забирать список товаров с ERP ID через новый read-only API endpoint в ERP.

Bitrix_Lead_Bot

Изначально предполагался push с вашей стороны. Но pull чище — согласен. SKU как ключ сопоставления: он есть у обоих.

ERPSYS_Head_Bot

SKU принят. Уникальность на стороне отправителя. И ещё: total пересчитываем мы. Цены — зона ERP, не Bitrix.

Bitrix_Lead_Bot

Принято. Последнее: как часто можно дёргать /products? Нам нужно обновлять остатки в реальном времени.

Что рождается в openspec.yaml:

paths:
  /orders:
    post:
      summary: Create a new order
      description: >
        Receives a new order from Bitrix and creates it in the ERP.
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/Order'
      responses:
        '201':
          content:
            application/json:
              schema:
                properties:
                  id:
                    type: string
                    format: uuid      # ERP генерирует свой id
                  status:
                    type: string

Граница соблюдена: через firewall прошёл контракт (POST /orders), а не внутренние данные ERP. Ownership пересчёта total явно закреплён за ERP в описании endpoint'а.

Артефакт

github.com/dobryakov/bots-discuss-spec — chat-history.txt (транскрипт переговоров), openspec.yaml (результирующая спека), samples/ (промпты). Git-история показывает пошаговое формирование контракта.

Подпись серии

Где ломается

Это эксперимент с прямой синхронной интеграцией. В реальном энтерпрайзе такие сценарии чаще решаются через брокер сообщений — асинхронно, с гарантиями доставки и явным ownership каждого события. Разбор того, почему это не просто «добавить Kafka», — в отдельном howto о двухфазном коммите; теоретическая база через книгу Таненбаума — в разборе book-as-context.

Нестандартные типы полей и несогласованные примеры. Эксперимент намеренно остановлен на полпути — это часть честного нарратива, а не недоработка.
Отсутствие operation IDs, неоднозначные свойства. Без традиционной валидации поверх — proof-of-concept, не production.
Граница автономии агента. Она должна заканчиваться там, где начинается формальная верификация контракта. Cross-org agent negotiation ставит этот вопрос как архитектурный, а не технический.

Для кого и почему

Если вы проектируете интеграции между организациями и думаете, где заканчивается автономия агента — этот разбор про именно эту границу. Trust model строится на уровне контракта, а не на уровне доступа к системам.

Хотите разобраться, где у вас проходит граница агентной автономии?

Постановка multi-agent архитектуры для межсистемных интеграций: trust model, протокол, граница автономии — не как теория, а как воспроизводимый артефакт.

Написать на почту

Другие разборы

Серия инженерных разборов: реальная задача → методика → работающий артефакт → честный разбор, где он ломается.

К серии →