Современные AI-приложения все сильнее зависят от конкретных провайдеров.

Проект начинается с простого вызова OpenAI API. Затем появляются:

• собственные тулзы,
• memory-системы,
• function calling,
• role-based prompts,
• orchestration-логика,
• agent-to-agent взаимодействие,
• structured outputs,
• provider-specific поведение.

Через несколько месяцев AI-модель перестает быть просто API. Она становится частью архитектуры приложения.

Именно в такой ситуации оказался один из моих legacy-проектов.

В системе уже существовали:

• десятки внутренних тулзов,
• собственная логика взаимодействия агентов,
• memory management,
• knowledge system,
• role-based инструкции,
• workflow-логика, глубоко встроенная в кодовую базу.

Полноценная миграция на другого AI-провайдера означала бы огромный объем работы.

Первой мыслью было:

• эмулировать OpenAI API,
• воспроизводить function calling,
• писать compatibility layer,
• переписывать orchestration.

Но потом появилась другая идея:

А что если вообще перестать зависеть от provider-specific протокола?

Что если не переписывать архитектуру, а просто отправлять весь контекст — вместе с ролями, тулзами, системными инструкциями и техническими данными — обычным текстом другому AI-агенту?

Именно так и появился этот эксперимент.

В качестве агента использовался open-source проект HAIH Agent:

HAIH Agent on GitHub

Суть эксперимента

Изначально система использовала классический OpenAI-style формат сообщений:

[
  {
    "role": "system",
    "content": "Rules and instructions..."
  },
  {
    "role": "user",
    "content": "User request..."
  }
]

Поверх этого работали:

• тулзы,
• память,
• внутренние агенты,
• knowledge base,
• orchestration logic.

Вместо переписывания всей инфраструктуры я попробовал максимально простой подход:

• взять весь массив сообщений,
• сериализовать его в текст,
• отправить как одно user-сообщение другому агенту.

Не через native function calling.

Не через provider-specific API.

А буквально как текст.

Концептуально это выглядело примерно так:

OPENAI_PAYLOAD:
[
  { role: "system", content: "..." },
  { role: "assistant", content: "..." },
  { role: "user", content: "..." }
]

TOOLS:
[...]

INSTRUCTION:
Interpret this conversation and continue it correctly.

На первый взгляд это выглядит неправильным.

Многие разработчики уверены, что:

• роли строго изолированы,
• system prompt — привилегированный канал,
• tools требуют native API,
• provider protocols имеют фундаментальное значение.

Но эксперимент показал неожиданную вещь:

Современные LLM очень хорошо восстанавливают семантику протокола даже из обычного текста.

Что получилось

Эксперимент проводился на:

• Qwen 3.5 4B (локально),
• Gemini Flash Lite.

Обе модели успешно:

• понимали иерархию ролей,
• соблюдали embedded-инструкции,
• корректно работали с форматированием,
• обрабатывали огромные serialized contexts,
• сохраняли tool semantics,
• возвращали чистый результат без лишних комментариев.

И все это несмотря на то, что вся история диалога была встроена внутрь одного user-сообщения.

В одном из тестов prompt содержал почти 70 000 токенов:

• system instructions,
• memory records,
• internal rules,
• tool descriptions,
• previous assistant responses,
• knowledge base entries,
• orchestration logic.

При этом сама задача была тривиальной: оформить информацию о заведении в markdown.

И обе модели стабильно выдавали правильный результат.

Без native function calling.

Без provider-specific APIs.

Без специальных role channels.

Что на самом деле показывает этот эксперимент

Это не означает, что native APIs бесполезны.

Они по-прежнему дают:

• validation,
• constrained decoding,
• более стабильное поведение,
• streaming,
• structured outputs,
• дополнительные safety layers.

Но эксперимент показывает важную вещь:

Многие protocol semantics являются не жесткими архитектурными ограничениями, а обученными behavioral patterns.

Это очень важное различие.

Сегодня многие AI-системы строятся вокруг предположения, что:

• system roles обладают особым статусом,
• chat protocols — это строгая execution environment,
• function calling — обязательная часть архитектуры.

Но на практике многие из этих механизмов оказываются скорее conventions, чем hard boundaries.

Модель не воспринимает role как права доступа операционной системы.

Она видит токены.

А современные LLM прекрасно умеют восстанавливать намерение из структурированного текста.

Иллюзия безопасности

Эксперимент также хорошо показывает опасную проблему современной AI-индустрии.

Многие разработчики воспринимают system prompt как:

• immutable policy,
• security boundary,
• sandbox,
• hard rule system.

Но это не так.

System prompt — это не система безопасности.

Это не access control.

Это не гарантия.

Это сильная probabilistic instruction.

И это становится особенно очевидно, когда начинаешь вручную сериализовывать протокол.

Если модель способна корректно интерпретировать:

role: system

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

Именно поэтому prompt injection до сих пор остается настолько сложной проблемой.

Модель работает в языковой среде, а не в формально изолированной execution environment.

Почему это важно для legacy-систем

Практический вывод здесь очень интересный.

Сегодня огромное количество проектов жестко завязано на:

• OpenAI APIs,
• Anthropic-specific behavior,
• provider-native tools,
• SDK-specific orchestration.

Из-за этого миграция кажется почти невозможной.

Но эксперимент показывает альтернативный подход:

Вместо переписывания orchestration-слоя можно виртуализировать сам протокол.

Во многих случаях оказывается возможным:

• сохранить существующую архитектуру,
• сериализовать operational context,
• перенаправить его в другую модель,
• и продолжить работу с минимальными изменениями.

Это особенно полезно для:

• legacy systems,
• experimental agent platforms,
• self-hosted models,
• multi-provider infrastructures,
• быстрых миграций между провайдерами.

Важные ограничения

Разумеется, этот подход не является универсальным решением.

У него есть свои недостатки:

• меньшая предсказуемость,
• weaker guarantees,
• большие prompts,
• менее deterministic behavior,
• сложность prompt management.

Кроме того, разные провайдеры ведут себя по-разному.

Например, Anthropic-модели заметно сильнее завязаны на structured protocol handling и runtime orchestration layers, чем многие open-weight модели.

Поэтому результаты нельзя автоматически переносить на весь рынок LLM.

Но общий вывод остается важным:

Современные языковые модели способны восстанавливать surprisingly complex interaction protocols из обычного текста.

И это серьезно меняет взгляд на AI-архитектуру.

Итог

Главный вывод этого эксперимента заключается в том, что многие AI-системы сегодня, возможно, слишком сильно завязаны на provider-specific abstractions.

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

А это означает, что:

• protocol virtualization может быть реальным инструментом,
• orchestration можно отделять от провайдера,
• миграция между моделями может быть проще, чем кажется,
• а многие “обязательные” AI-механизмы на деле являются conventions, поддерживаемыми tooling-слоем.

По мере усложнения agentic AI-систем понимание различий между:

• поведением модели,
• runtime-логикой,
• protocol conventions

может стать одним из важнейших инженерных навыков ближайших лет.