Ваш чат, ваш UX
Клиент пишет в вашем интерфейсе. API-ключ остаётся на сервере, а не в браузере.
Octo API · Agent as a Service
Ваш продукт.
Его агент.
Соберите собственный чат или рабочий интерфейс. Octo получает задачу, работает с вашими и внешними инструментами и возвращает результат в ваше приложение.
Агент внутри вашего сценария.
Клиент остаётся в вашем приложении. Ваш сервер передаёт ход агенту; инструменты связывают внешние сервисы с действиями внутри продукта.
Агент действует
Один ход может включать инструменты и помощников, а не только генерацию текста.
Экран меняется
Структурированные результаты идут через инструменты с вашей схемой. Приложение обновляет данные и показывает ответ.
Разница в уровне
Не просто модель. Исполнитель задачи.
Сырой API модели
Вам приходится собирать цикл инструментов, память, повторы, маршрутизацию, файлы, ограничения и учёт расходов вокруг вызова модели.
Octo API
Вы отправляете ход в пространство. Агент ведёт итерацию, вызывает доступные инструменты и возвращает ответ и файлы; политика моделей и учёт энергии работают на платформе.
Ваш продукт по-прежнему отвечает за интерфейс, авторизацию клиентов и проверки действий во внутренних системах.
Формат для вашего backend.
Bearer-ключ, JSON-запрос, асинхронный ход. Получите turn_id сразу, затем прочитайте результат или примите событие вебхука.
01 · ЗапросPOST /v1/turns
POST https://dash.octomatica.ru/v1/turns
Authorization: Bearer octo_live_…
Content-Type: application/json
Idempotency-Key: <uuid>
{
"space": "<space_id>",
"end_user_ref": "customer-42",
"text": "Подготовь отчёт по заказу",
"file_ids": ["<file_id>"]
}02 · ОтветGET /v1/turns/{turn_id}
202 {"turn_id":"<turn_id>","state":"queued"}
GET /v1/turns/<turn_id>
{
"state": "done",
"result": "Отчёт готов",
"files": [
{"file_id":"<file_id>",
"name":"report.pdf",
"source":"agent",
"url":"/v1/files/<file_id>"}
],
"energy_used": <число>
}Структура соответствует справочнику API; текст задачи, ответ и идентификаторы показаны для иллюстрации.
Файлы
POST /v1/spaces/{slug}/files принимает multipart-поле file. Передайте file_id в file_ids; созданные агентом файлы скачиваются через GET /v1/files/{file_id} с Bearer-ключом.
Ход и доставка
queued → running → done, failed или cancelled. Опросите GET /v1/turns/{turn_id} либо получите подписанное событие вебхука. Текстовый ответ в result.
Разговор и память
Пространство на клиента. История остаётся с ним.
Создайте пространство один раз, сохраните space_id у себя и отправляйте следующие сообщения туда же.
Свой чат поверх API
Сервер связывает пользователя с пространством. В многопользовательском приложении ключ
space_adminсоздаёт отдельное пространство поend_user_ref, без смешения диалогов.Один разговор сквозь ходы
Обычный ход сохраняет историю пространства.
stateless: trueзапускает независимую задачу без истории. Для под-ключа приложения stateless включён по умолчанию: для памяти задайтеstateless: false.Сессии сменяются, память остаётся
При смене сессии «dream» сохраняет память пространства. Долгая работа продолжается в одном пространстве, но это не бесконечное контекстное окно: детали, не сохранённые в памяти, могут потеряться.
Соберите агента под продукт.
Манифест описывает поведение; секреты дают доступ; список инструментов определяет допустимые действия.
01 · Создать
Пространство
POST /v1/spaces с {"title":"Support"} возвращает space_id.
02 · Настроить
Манифест
PUT /v1/spaces/{slug}/manifest с полем manifest задаёт устойчивые инструкции агенту.
03 · Подключить
MCP и секреты
PUT /v1/spaces/{slug}/tools задаёт allowlist и MCP-серверы. PUT /v1/spaces/{slug}/secrets сохраняет именованные значения.
04 · Маршрутизировать
Модели по политике
По умолчанию действует политика платформы. GET /v1/models показывает каталог, PUT /v1/spaces/{slug}/policy задаёт override для orchestration.
MCP · инструменты приложения
Дайте агенту действия, а не HTML для разбора.
Опишите в манифесте, когда и как вызывать инструменты. Подключите свой MCP-сервер с операциями приложения и ограничьте встроенные возможности.
КонфигурацияPUT /v1/spaces/{slug}/tools
{
"allow": ["web", "files"],
"mcp_servers": [
{
"name": "my-app",
"url": "https://mcp.example.com",
"headers": {"Authorization": "Bearer …"}
}
]
}Типизированный инструмент
Определите вывод как инструмент MCP или REST-действие с вашей схемой. Агент вызывает его; ваш сервер проверяет поля и возвращает ошибку для корректировки. Не извлекайте контракт из свободного текста ответа.
Только нужные возможности
allow ограничивает встроенные инструменты. Секреты хранятся на стороне пространства; права во внутренних API остаются под вашим контролем.
Личное пространство Commander не управляется через API. Для приложения создайте отдельное API-пространство; MCP-серверы родительского пространства не наследуются tenant-пространствами.
Одна платформа для разных задач.
Собственный интерфейс остаётся вашим. Платформа объединяет вызов агента, маршрутизацию, файлы, ограничения и расход энергии.
Единый баланс
Расход идёт с аккаунта владельца. GET /v1/usage разбивает энергию по клиентам, пространствам и ключам.
Модели по задаче
Политика выбирает модель для разных видов работы; у пространства есть override для orchestration.
Лимиты и доступ
Область действия ключа, дневной предел, лимит клиента и список доступных инструментов.
Файлы через API
Передавайте вложения в пространство и получайте созданные агентом файлы по защищённой ссылке.
Следующий шаг
Встроить агента в продукт.
Начните с одного пространства, своего сценария и инструмента, через который агент действует в вашем приложении.