Odyssey: кто мы и какую нишу занимаем

Source asciidoc: `docs/article/odyssey-who-is-announcement.adoc` == Краткое заявление

Odyssey — execution control plane для AI-агентов и AI-процессов. Мы вызываем любой compute, применяем политику, маршрутизируем выполнение и возвращаем подписанную квитанцию результата с доказательствами и воспроизводимой историей действий.

Принцип: invoke compute, deliver proof. Не ещё один чат, не ещё один LLM-шлюз, не ещё один рынок GPU. Odyssey — слой ответственности и доказуемости, который делает AI-выполнение пригодным для enterprise-эксплуатации.

Контекст рынка: где мы стоим

Рынок вокруг AI-исполнения расколот на три сильных сегмента:

  1. LLM gateway / routing

  2. LLM observability / tracing / eval

  3. AI governance / risk

Odyssey занимает место между ними и закрывает то, что часто остаётся ничьим:

runtime-контроль выполнения + доказуемый артефакт результата, который можно предъявить, проверить и повторить.

Это отдельная категория: AgentOps Control Plane / AI Execution Control Plane.

Проблема: почему enterprise не может просто внедрить агента

Enterprise-внедрение упирается не в способность модели ответить, а в способность организации:

  • доказать, что было сделано,

  • объяснить, почему решение принято именно так,

  • воспроизвести выполнение при инциденте, споре, аудите,

  • ограничить действия политиками и ролями,

  • измерять стоимость, латентность и ошибки на уровне процесса,

  • держать ответственность: кто разрешил действие, какой контроль сработал, где лежат артефакты.

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

Решение: receipt-first execution

Odyssey стандартизирует выполнение через один пайплайн:

Request → Policy → Routing → Execution → Receipt → Evidence Store → Export/Replay

1. Receipt — system of record

Receipt — это структурированный документ, который фиксирует:

  • вход: input hash, constraints, параметры задачи,

  • решение политики: allow/deny + explain, версия политики,

  • маршрут: какой исполнитель выбран, какие кандидаты рассматривались, почему,

  • выход: outcome, ошибки, метрики, ссылки на артефакты,

  • корреляцию: trace/task/batch идентификаторы,

  • подпись: tamper-evidence.

Receipt проектируется так, чтобы быть:

  • машиночитаемым,

  • пригодным для экспорта,

  • воспроизводимым,

  • юридически и операционно несущим смысл.

2. Policy — управление риском до выполнения

Policy-слой решает: что разрешено, что запрещено, на каких условиях. Это не после-фактум отчёт, а перед-выполнением контроль.

Практически policy отвечает на вопросы:

  • допускаем ли тип действия,

  • можно ли обрабатывать PII,

  • какой класс моделей и провайдеров разрешён,

  • нужен ли human approval,

  • какие лимиты бюджета и латентности применимы.

3. Routing — нейтральность к compute-бэкендам

Routing выбирает исполнителя под constraints и политику: титан-API, self-hosted модель, python-пайплайн, внутренний сервис, внешний подрядчик, децентрализованный compute.

Ключевой эффект:

вы переключаете compute, но не меняете контракт результата.

Это снижает lock-in и позволяет оптимизировать стоимость, латентность и риски.

4. Execution — единый контракт исполнения

Исполнение оформляется через единый интерфейс Executor. Executor возвращает Outcome, а Odyssey превращает его в Receipt и сохраняет в Evidence Store.

Чем Odyssey отличается от лёгких конкурентов

На лёгком входе чаще всего появляются два продукта:

Шлюз + бюджеты + fallbacks

Это полезно, но в основном решает задачу подключения к моделям. Odyssey рассматривает gateway-часть как подмодуль, а не как ядро.

Трейсинг + eval + красивые дашборды

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

Odyssey строит эксплуатационный ров:

  • receipts как system of record,

  • подписи и tamper-evidence по умолчанию,

  • воспроизводимость и экспорт доказательств,

  • интеграция в workflow-гейты,

  • SLO и эксплуатационные контуры.

Эти вещи трудно скопировать по подсказке без реальной эксплуатации.

Для кого Odyssey

Odyssey нужен там, где AI-решение становится действием, а не советом.

Типовые сценарии

  • Финансы и операции: возвраты, споры, чарджбеки, triage, риск-решения с обязательной трассируемостью.

  • Enterprise support: агент делает шаги в тикет-системе, CRM, документации.

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

  • Инжиниринг: агентные пайплайны в репозиториях, CI-гейты, без квитанции нельзя.

Роли покупателей и пользователей

  • CTO / Head of Engineering: эксплуатация, SLO, интеграции, стоимость.

  • Security / GRC: политики, аудит, tamper-evidence.

  • Product / Operations: воспроизводимые решения и отчётность.

Архитектура и стек

Odyssey наследует архитектурный канон Smart Responsor как основу дисциплины: воспроизводимость, доказательства, строгие границы ответственности. При этом compute-слой допускает стековые ответвления, но контракт результата и учёт остаются едиными.

Базовый стек

  • Control plane: Symfony 8 / PHP 8.4

  • Console: React + TypeScript

  • Compute plane: Python modules and runners

  • Evidence Store: dev — filesystem; prod — object storage / DB

Почему так

  • PHP/Symfony отлично подходит для enterprise-контроля, интеграций, политики, RBAC, событий и API.

  • Python естественен для моделей и вычислительных пайплайнов.

  • Разделение control plane / compute plane снижает риски и упрощает эксплуатацию.

Что уже есть

На текущей стадии реализованы базовые кирпичи:

  • контракт receipt и примеры,

  • policy engine,

  • routing,

  • evidence store,

  • подпись receipts,

  • async выполнение через очередь и worker,

  • observability endpoints,

  • python runner skeleton.

Это не презентация, а работающий каркас, который можно наращивать до enterprise-уровня.

Позиционирование

  • Мы не конкурируем с титанами в качестве моделей.

  • Мы не конкурируем с децентрализаторами в продаже GPU.

  • Мы делаем слой, который делает любой compute управляемым и доказуемым.

Odyssey = accountability layer для AI-исполнения. Там, где другим хватает логов и дашборда, мы выдаём квитанции и доказательства.

Следующий шаг

Если вы внедряете AI-агентов в прод, вы неизбежно упираетесь в контроль: кто разрешил, что сделано, почему так, как повторить. Odyssey создан именно для этой границы между AI-возможностями и enterprise-ответственностью.

Если вам нужен enterprise-уровень доказуемости выполнения — Odyssey является базовой плоскостью, на которую можно опереться.