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

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

Odyssey — execution control plane для AI‑агентов и AI‑процессов.
Мы вызываем любой compute (модель, пайплайн, инструмент, внешний сервис), применяем политику (policy), маршрутизируем выполнение (routing) и возвращаем подписанную квитанцию результата (receipt) с доказательствами и воспроизводимой историей действий (audit trail + replay hooks).

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

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

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

  1. LLM gateway / routing — прокси к множеству моделей, бюджеты, fallbacks, унификация API.

  2. LLM observability / tracing / eval — логирование, трассировка, метрики качества, отчёты, эксперименты.

  3. AI governance / risk — инвентаризация AI-систем, контроль рисков, комплаенс-процессы, аудит.

Odyssey занимает место между ними и закрывает то, что часто остаётся “ничьим”:
runtime-контроль выполнения + доказуемый артефакт результата, который можно предъявить, проверить и повторить.

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

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

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

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

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

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

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

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

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

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

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

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

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

[[1-receipt-квитанция—​system-of-record]] === 1) Receipt (квитанция) — “system of record”

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

  • вход: input hash, constraints (бюджет/латентность/режимы данных), параметры задачи;

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

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

  • выход: outcome (статус, результат, ошибки, метрики), ссылки на артефакты;

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

  • подпись: tamper-evidence — защита от незаметной подмены истории.

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

  • машиночитаемым (для аналитики/поиска),

  • пригодным для экспорта (NDJSON/PDF-пакеты),

  • воспроизводимым (replay hooks и ссылки на артефакты),

  • юридически/операционно “несущим смысл” (кто, что, почему, на каких условиях).

[[2-policy—​управление-риском-до-выполнения]] === 2) Policy — управление риском до выполнения

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

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

  • допускаем ли тип действия (например, внешние интеграции, удаление данных, отправку писем);

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

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

  • нужен ли human-approval;

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

[[3-routing—​нейтральность-к-compute-бэкендам]] === 3) Routing — нейтральность к compute-бэкендам

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

Ключевой эффект: вы переключаете compute, но не меняете контракт результата.
Это снижает lock-in и позволяет оптимизировать стоимость/латентность/риски.

[[4-execution—​единый-контракт-исполнения]] === 4) Execution — единый контракт исполнения

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

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

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

A) “Шлюз + бюджеты + fallbacks”

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

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

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

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

  • receipts как “system of record” (а не набор логов),

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

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

  • интеграция в workflow-гейты (CI/CD, бизнес-процессы),

  • SLO и эксплуатационные контуры (status/metrics/queue).

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

Для кого Odyssey (первые целевые контуры)

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

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

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

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

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

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

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

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

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

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

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

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

Базовый стек

  • Control plane (API, policy, routing, storage): Symfony 8 / PHP 8.4

  • Console (админ-плоскость, просмотр receipts, экспорт): React + TypeScript

  • Compute plane (тяжёлые вычисления): Python modules/runners (процесс/сервис), далее контейнеризация/оркестрация

  • Evidence Store: dev — filesystem; prod — объектное хранилище/DB (эволюционно, без смены контракта)

Почему так

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

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

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

Что уже есть (как техническое доказательство прогресса)

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

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

  • policy engine (allow/deny + explain);

  • routing (выбор исполнителя по constraints/capabilities);

  • evidence store (сохранение и выдача receipts);

  • подпись receipts (HMAC) как первый уровень tamper-evidence;

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

  • observability endpoints (/status, /metrics);

  • python runner skeleton (контрактный вызов compute-модуля).

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

Позиционирование: коротко и без двусмысленности

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

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

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

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

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

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

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