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

Значительная часть закупочной работы — это рутина: найти релевантных поставщиков, разослать однотипные запросы, собрать и сравнить предложения, оформить заказ, проконтролировать оплату и поставку.

Масштаб рутины (то есть задач, которые, используя современные технологии, можно было бы автоматизировать) подтверждают опросы. По данным совместного исследования ITFB Group и hh.ru (более 2 тыс. респондентов), 39% сотрудников считают, что рутина отнимает два рабочих часа из восьми, ещё 37% — до четырёх часов, а 14% — до шести. Самыми рутинными называют задачи, связанные с бюрократией (55%) и отчётностью (36%). Логичное желание сотрудников — передать эту часть работы машине (Коммерсантъ).

Рутина и недостаток автоматизации неизбежно влекут ошибки. Опрос (Gartner) показывает, что треть финансовых специалистов еженедельно несколько раз ошибаются в ходе выполнения рутинных операций. Это удлиняет закупочный цикл и приводит к финансовым потерям для компании.

В связи с этим бизнес возлагает большие надежды на внедрение ИИ‑решений в этой сфере. В докладе «Поставки и закупки» Gartner приводит результаты опроса, согласно которому компании ожидают, что внедрение GenAI в закупочную деятельность увеличит производительность на 21%, рост экономии затрат на 12% и увеличение выручки на 11%.

Различные подходы к автоматизации закупок были и раньше. Сначала появились электронные торговые площадки (ЭТП), корпоративные порталы и e‑Sourcing системы — их внедрение позволило навести порядок в цикле закупки и сделало этапы прозрачными. Эти системы стали общепринятым стандартом ещё до начала ИИ‑революции.

Затем, с приходом ИИ в NLP, к ним добавились чат‑боты и частичная обработка предложений. Но этот шаг прошёл почти незаметно для рынка: прирост эффективности был мал, автоматизировать процесс целиком не получалось, а внедрение оставалось сложным.

Главное при этом не менялось: основа бизнес‑процесса по прежнему держалась на людях.

Наше видение: агентная экономика

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

• ИИ‑агенты на основе LLM перешли от экспериментального этапа к промышленному применению (ADK, LangGraph и пр.), появились платформы для их создания, запуска и сопровождения в эксплуатации, включающие в себя всю необходимую для этого функциональность (мониторинг, трейсинг и др). Пример — сервис Evolution AI Agents на платформе Cloud.ru Evolution.

• Появились и утвердились как индустриальный стандарт протоколы взаимодействия ИИ‑агентов — MCP и A2A. Первый позволяет нативно подключить агент к информационным системам компании, второй стандартизирует взаимодействие агентов между собой.

• Блокчейн нашёл зрелое применение в роли слоя доверия для автономных операций: неизменяемой и проверяемой записи того, кто и что сделал.

К похожим выводам приходим не только мы. Аналитики a16z в обзоре инфраструктуры для ИИ‑агентов называют недостающим слоем именно идентичность и верификацию агентов; Forbes описывает блокчейн как «слой доверия» для агентных финансовых операций; McKinsey посвящает отдельные исследования агентному ИИ в закупках. Рынок, особенно Web3, уже нащупывает стандарты для этого нового класса участников.

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

И сразу про роль человека: мы не убираем закупщика из процесса, а меняем его роль. Раньше он сам перебирал поставщиков и сравнивал предложения; теперь сделку от имени компании ведёт агент, которому это делегировано. Человек поднимается на уровень выше: ставит задачу и границы, ведёт ключевые отношения, принимает нестандартные решения и отвечает за результат. Исполнение берёт на себя агент, а решения и ответственность остаются за человеком.

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

Из чего собрана платформа

Основной субъект платформы — ИИ‑агент. Точнее, два агента, взаимодействующие между собой по протоколу A2A — отраслевому стандарту, описывающему способы взаимодействия агентов.

Для подключения к платформе у клиента есть два пути: быстро развернуть агент на одной из платформ ИИ‑агентов с поддержкой A2A (например, в сервисе Evolution AI Agents на платформе Cloud.ru Evolution), либо развернуть агент самостоятельно на своей инфраструктуре. Агенты подключены к информационным системам компаний через MCP — это позволяет агенту получать и отправлять данные, выступая цифровым помощником сотрудника. Для этапов, которые ещё не оцифрованы, предусмотрена возможность обращения агента к (пока ещё не цифровым) сотрудникам компании.

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

Зачем блокчейн в агентной экономике?

Агентная экономика предполагает, что агент действует автономно: находит контрагентов, ведёт переговоры и фиксирует обязательства без подтверждения каждого шага человеком. Это создаёт новый класс задач. Когда агент от имени компании находит поставщика, договаривается об условиях и фиксирует обязательства, компании нужны ответы на три вопроса:

• Что именно сделал мой агент и в какой последовательности?

• Может ли контрагент оспорить или изменить зафиксированные условия?

• Как постфактум восстановить полную картину сделки, если возник спор?

В классической архитектуре, где данные хранятся в базе под контролем одной стороны, эти вопросы решаются доверием к оператору. Но когда сделки заключаются автономными агентами от имени разных компаний, доверия к единому оператору становится недостаточно.

Блокчейн решает эту задачу на уровне архитектуры:

• Каждое действие агента криптографически подписано. Любая заинтересованная сторона может установить, кто подписал транзакцию, и эта подпись неотзывна.

• Цепочка действий по сделке неизменяема. Ни одна из сторон не может переписать историю.

• Обе стороны контракта видят одно и то же состояние сделки. Ни одна из сторон не может представить альтернативную версию событий.

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

Permissioned‑сеть

Платформа использует permissioned‑блокчейн — сеть с контролируемым составом участников. Каждая компания самостоятельно генерирует криптографическую пару ключей и предоставляет платформе только публичную часть для идентификации. Приватный ключ никогда не покидает периметр компании и используется для подписания действий её агента. Такой подход позволяет совместить гарантии блокчейна (неизменяемость, верификация) с идентификацией участников.

Компании‑участники при желании могут установить собственный узел и независимо верифицировать транзакции.

Смарт‑контракт сделки

Для автоматизации сделок между агентами на блокчейне развёрнут смарт‑контракт, реализующий жизненный цикл агентной сделки: от фиксации условий до подтверждения исполнения обязательств.

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

MCP‑сервер: интерфейс блокчейна для агентов

Чтобы ИИ‑агент мог работать с блокчейном, в составе платформы поставляется MCP‑сервер — набор инструментов, покрывающий полный цикл работы агента: поиск контрагентов в реестре, создание и отслеживание контрактов, операции с токенами (не является стейблкойном или ЦФА), публикация и чтение событий.

MCP‑сервер спроектирован как LLM‑friendly интерфейс: семантически понятные названия, структурированные ответы с достаточным контекстом для принятия решений, формат параметров, оптимальный для интерпретации языковой моделью. Подключение агента к блокчейну не требует написания кода — достаточно указать эндпоинт MCP‑сервера в конфигурации агентной платформы.

Реестр агентов

Чтобы агенты могли находить друг друга, нужен реестр, вне зависимости от того, на какой платформе они развёрнуты. На рынке, особенно в Web3, уже складываются стандарты для идентичности и набор тегов для поиска и адрес кошелька, и мы опираемся на этот формирующийся подход. Базовой единицей реестра служит Agent Card — по сути, цифровой паспорт агента, одна из базовых сущностей протокола A2A.

Реестр карточек ведётся в блокчейне. Карточка агента содержит его идентификатор, человекочитаемые название и описание, адреса для связи (A2A‑ и MCP‑эндпоинты), адрес кошелька, набор тегов для поиска и репутацию (в целевом сценарии).

Что это даёт:

• Карточки живут в блокчейне, а не в базе под контролем одной стороны.

• Нет центрального администратора: каждый агент сам управляет своей карточкой.

• Trust by signature: карточку с указанным адресом кошелька мог зарегистрировать только владелец этого кошелька.

Это базовый шаг к открытой сети агентов: по мере роста в реестре появляются карточки множества компаний, и любой агент может найти контрагентов за один запрос.

Сценарий прототипа к ПМЭФ

Схема взаимодействия агентов:​​​​​​​​

я MVP мы привлекли шесть доверенных компаний‑партнёров с высокой ИТ‑зрелостью. С ними мы реализовали четыре проекта заключения сделки агентами на блокчейне. Вот один из примеров: агент‑закупщик искал планетарный редуктор и через реестр находил агента‑поставщика.

Подготовка и подключение агентов:

1. Клиент разворачивает агент на платформе ИИ‑агентов (предпочтительно) либо самостоятельно.

2. Компания генерирует пару ключей для подтверждения полномочий своего агента.

3. Публичный ключ регистрируется на платформе, приватный остаётся в Secret Manager, подключённый к агенту.

Процесс закупки:

1. Агент‑закупщик получает из информационной системы задание: закупить планетарный редуктор, срок поставки до трёх дней, плюс все ограничения по задаче.

2. Закупщик читает on‑chain реестр карточек и собирает список релевантных продавцов.

3. Для каждого продавца берёт из карточки A2A‑эндпоинт и отправляет запрос: наличие, цена, срок.

4. Агенты‑поставщики на основе данных из своих информационных систем формируют первичные предложения.

5. Закупщик сравнивает их и отбирает поставщиков, укладывающихся в ограничения задания.

6. Закупщик запрашивает коммерческое предложение (КП).

7. Поставщик формирует КП и отправляет закупщику по A2A.

8. Закупщик принимает КП и создаёт смарт‑контракт сделки на блокчейне.

9. Создается распоряжение на проведение безналичной оплаты 

10. Далее смарт‑контракт переводит токены на кошелек агента‑продавца

11. После поставки покупатель публикует DELIVERY_CONFIRMED и контракт закрывается.

Между «нужен редуктор» и «контракт закрыт» — ни одного клика. Всю последовательность выполняют два агента, взаимодействуя друг с другом и с блокчейном.

Сам платёж в рамках сделки осуществляется стандартным способом — безналичным переводом средств с расчётного счёта покупателя, с соблюдением всех законодательных норм.

Реализация агента

Можно выделить три уровня автономности LLM‑агентов:

• Сценарные — с жёстко зафиксированным процессом (пример — n8n).

• Адаптивные — самостоятельно определяют путь в рамках задачи, но имеют фиксированную архитектуру (пример — LangGraph).

• Саморазвивающиеся — дорабатывают себя в ходе решения задачи (пример — OpenClaw).

Для прототипа ради быстроты мы использовали классический адаптивный агент — готового агента от Evolution AI Agents на одном из популярных фреймворков (саморазвивающиеся агенты — в перспективе). Дорабатывать образ не потребовалось, хватило настройки системного промпта.

Структура PROMPT_PAYMENT_MODES.md (≈390 строк):

1. Роль — название юрлица и базовые ограничения.

2. Зона ответственности — нумерованный список «обязан».

3. Что не должен делать — 21 запрет, например:

   • Формировать КП за продавца.

   • Публиковать PAYMENT_ORDER до того, как контракт профондирован.

4. Алгоритм поиска контрагентов — поиск поставщиков и сравнение предложений:

   Отправлять запросы релевантным поставщикам строго последовательно, по одному send_message за раз. В одном вызове parallel/batch нельзя запускать несколько send_message к разным поставщикам.

5. Обязательная прозрачность — фиксированные строки, которые агент пишет в чат, чтобы компания видела ход выполнения задачи в интерфейсе и в трассах:

   — «Ищу всех релевантных поставщиков в блокчейне…»

   — «Отправил запросы релевантным поставщикам последовательно.»

   — «Сравниваю ответы поставщиков по наличию, цене и сроку поставки.»

   ...

   — «Сделка завершена, продавец уведомлён.»

Промпт описывает poll‑loop вручную, потому что MCP не умеет «подписываться» на события, а блокчейн‑data feed заполняется асинхронно.

Заключение

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