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% помилок введення».