Read
Read сразу, write по правилам
Статус, остаток, занятость — автономно за latency вашего API. Отмена, возврат, смена PII — только после кнопки.
Нет успешного read — нет выдуманного ETA. Честный текст и Inbox.
Как вызывается API
Схема → read → кнопка → write с ключом
ИИ не исполняет код серверов. Он заполняет аргументы разрешённого инструмента. Секреты модель не видит.
Write · HITL
Критичный write — карточка человеку
Агент собрал параметры и проверил схему. Смена видит «подтвердить / отклонить», не сырой JSON в чате клиента.
Запуск
Две операции, один контракт, потом HITL
- 01
Выбрать 2–3 операции
Статус заказа, слот, остаток. Не «весь ERP в первый день».
- 02
Описать контракт
Имя, аргументы, типы. Готовый OpenAPI — в конструктор volbor.
- 03
Read / write и кто жмёт
Что автономно, что клиенту, что смене. Секреты — в vault.
- 04
Прогон 5xx и таймаутов
Модель не имеет права нарисовать успех. Смотрите журнал первую неделю.
Методология и источники
Как считаются цифры на этой странице
- [1]Статус и перенос слота — минуты L1 против секунд API
Разбор шагов первой линии: найти заказ, сверить статус, открыть курьерку, перебить адрес. На пике это 10–30 минут календаря человека. Read/write volbor занимает latency вашего API — обычно секунды при живом ответе. Не среднее время решения всех тикетов Inbox и не обещание SLA.
- [2]Без Idempotency-Key повтор сети даёт двойной write
Сценарий: клиент или оператор жмёт «подтвердить» дважды на плохой сети, или клиент ретраит таймаут. Без ключа бэкенд создаёт второй заказ или второе списание. Ключ делает повтор безопасным. Это механика протокола, не полевой A/B.
- [3]Часы L1 на статус и перенос — деньги смены
Если статус и перенос слота составляют около трети очереди L1, loaded cost смены $4–6 тыс./мес. даёт порядка $1.3–2 тыс. на эти тикеты. Worked example состава очереди, не обещание экономии клиенту и не «0% ошибок ввода».