Промоційний шлюз: агент ніколи не затверджує власне замовлення на роботу

🚦 Два агенти, один цикл

Поширена схема: старший агент пише замовлення на роботу для дешевшого агента, і замовлення потрапляє в чергу. Якщо та сама система, яка пише замовлення, може його й затвердити, то ніхто нічого не вирішив. Помилка в замовленні йде прямо у виконання, а рахунок не забарюється.

🧩 Три окремі кроки

У нашій схемі цикл має три кроки, кожен — окрема команда.

1. Підготувати. Старший агент пише замовлення: специфікацію для виконавця й контракт приймання, в одному файлі, з полем approved, усталено false.
2. Промотувати. Названа людина затверджує файл. Це окрема дія, записана в журнал: хто, коли і який файл. Агент не може зробити це за себе.
3. Поставити в чергу. До черги потрапляє лише затверджений файл.

Глобальний перемикач у визначенні сервісу, який вмикає диспетчер, — не затвердження. Наша проєктна нотатка прибирає перемикач, що робив саме це, бо прапорець на весь процес затверджує все одразу й нічого не фіксує про те, хто вирішив.

💵 Резервуйте всю задачу

Друге правило — про гроші. Перевірка, що залишок балансу більший за нуль, дозволяє одній дорогій задачі з'їсти все. Натомість бюджет усієї задачі резервують до першого запиту. Тайм-аут, убитий процес або помилка залишають списання в стані «невизначене» й блокують нові задачі, доки людина його не звірить. Рахується вся траєкторія: цикли викликів інструментів, роздуми, проходи критика, повторні спроби й запасні варіанти, а не лише остання відповідь. Невідома вартість — не нуль.

📊 У цифрах

Кожен токен задачі в нашому транспорті прив'язаний до відбитка пакета задачі, і від 2026-09-21 видано 1 415 токенів. Транспорт зафіксував 4 резервування. Обидва показники пораховані з бази даних 3 листопада 2026, 21:53 UTC.

🛠️ Практика: додайте шлюз до своєї черги

1. Додайте поле approved у формат замовлення на роботу й усталено поставте false.
2. Напишіть команду промоції: їй потрібні файл, ім'я людини й причина. Вона дописує рядок у журнал і перемикає поле.
3. Зробіть так, щоб черга відхиляла будь-яке замовлення, у якого поле false або хеш відрізняється від записаного в журналі.
4. Приберіть усі глобальні перемикачі «увімкнути диспетчеризацію» з ваших визначень сервісів.
5. Резервуйте бюджет замовлення під час постановки в чергу, а не під час запуску. Відмовляйтеся ставити в чергу, якщо ліміт буде перевищено.
6. Позначайте тайм-аути й убиті запуски як невизначені та зупиняйте лінію, доки хтось їх не звірить.

✅ Перевірте себе

• Змініть затверджений файл на один символ. Черга відхилить його, бо хеш змінився.
• Спробуйте промотувати з порожнім ім'ям. Не вийде.
• Запустіть диспетчер без затверджених замовлень. Він нічого не зробить.
• Візьміть будь-яке замовлення за минулий тиждень і знайдіть, хто й коли його затвердив.

🚧 Коли це не працює

• Затвердження на автоматі. Якщо одна людина затверджує п'ятдесят замовлень за хвилину, їх ніхто не читає. Обмежте розмір пакета.
• Повільні лінії. Затвердження додає хвилини. Для крихітних задач лише на читання розгляньте постійне правило замість рішення щодо кожного замовлення.
• Затвердження не того. Людина бачить підсумок, а не завжди виклики інструментів. Показуйте у запиті хеш файлу й бюджет.
• Один затверджувач. Коли ця людина відсутня, лінія зупиняється. Призначте заступника.
• Агенти, що редагують журнал. Тримайте журнал затверджень поза будь-яким шляхом, куди агент може писати.

📊 Докази

➡️ Далі

Пишіть саме замовлення разом із Розробка на основі специфікацій з наявними пакетами задач, а з застряглої лінії виходьте через Відновлення після невдалого, застряглого чи невизначеного запуску.

Джерела

• Розробка на основі специфікацій з наявними пакетами задач: написання замовлення.
• Відновлення після невдалого, застряглого чи невизначеного запуску: застряглі лінії.
• Витрати, бюджети й ліміти: бюджети.
• Політика використання AI та реєстр, які може впровадити невелика команда: кому що можна робити.