Що економить делегування (і що ні)

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

Чому важливий контекст вашого агента

Агент на основі чату не пам’ятає попередні повідомлення самостійно. На кожному кроці типовий оркестратор знову надсилає моделі її транскрипт: ваші інструкції, визначення інструментів, попередні повідомлення, файли, які вона прочитала, та результати інструментів. Усе, що потрапляє до цього транскрипту, знову надсилається або обробляється на наступних кроків і може враховуватися у використанні, залежно від кешування, ущільнення та обліку постачальника. Власний чат ISMS Copilot працює так само, тому довгі ланцюжки використовують більше вашого вікна використання на кожне повідомлення.

Отже, питання не лише в тому, скільки коштує одна відповідь, а й у тому, що залишається в транскрипті вашого агента після неї.

Що залишається на боці ISMS Copilot

Під час делегування роботи наступні елементи залишаються на боці ISMS Copilot, якщо повернений результат їх не відтворює. Запит MCP, який надсилає ваш агент, і отриманий результат (відповідь та такі поля, як ID, статус, використання та помилки) потрапляють до його транскрипту разом із схемами інструментів, описані далі:

• Вихідний матеріал фреймворків. Посилання на стандарти та нормативні акти, на які спирається ISMS Copilot у своїх відповідях. Ваш агент надсилає запитання, а не текст фреймворку. У відповіді можуть наводитися цитати або посилання на відповідні частини.
• Пошук. Знаходження відповідних статей, заходів контролю та положень для запитання, а також збір контексту для моделі.
• Пам’ять робочого простору та файли. На кроці, обмеженому workspace_id, вони читаються на боці ISMS Copilot. Ваш агент їх не завантажує, хоча відповідь може використовувати факти з них.
• Проміжні міркування. Аналіз, що стоїть за відповіддю, включаючи багатокрокову роботу в режимах Think і Beyond.
• Чернетки. Довгі тексти генеруються на боці ISMS Copilot. Ваш агент отримує результат, а не процес створення чернетки.
• Копія потоку спеціаліста. Продовження роботи за допомогою send_message триває в потоці, який зберігає ISMS Copilot, тому ваш агент не надсилає повторно попередні повідомлення цього потоку у запиті. Попередні виклики інструментів і відповіді все ще знаходяться в транскрипті вашого агента, поки він їх не скоротить.

За що все одно платить ваш агент

Делегування не робить крок відповідності безкоштовним для вашого оркестратора:

• Схеми інструментів. Визначення інструментів MCP для ISMS Copilot потрапляють до контексту вашого агента, як тільки сервер підключено, як і інструменти будь-якого іншого сервера MCP.
• Запитання, яке він надсилає. Усе, що ваш агент пише в create_conversation або send_message, стає частиною його транскрипту.
• Відповідь, яку він читає. Повернута відповідь є вхідними даними для моделі вашого агента, і вона залишається в транскрипті до кінця сеансу.

Відповідь – це те, що ви контролюєте найбільше. Передавайте answer_format: "brief" (приблизно 150 слів) або "decision" (рекомендація спочатку, приблизно 300 слів), коли вашому агенту потрібен лише висновок. Якщо результат – це довгий документ, нехай ваш агент запише його до файлу, а не повторює в чаті. Див. Делегуйте роботу з GRC зі свого агента.

Квитанція про використання

Завершена відповідь у режимах Fast або Think може містити об’єкт usage:

{
  "usage": {
    "copilot_input_tokens": 0,
    "copilot_output_tokens": 0
  }
}

Наведені вище значення – це заготовки. Поля такі:

• copilot_input_tokens і copilot_output_tokens: токени, які обробила та згенерувала модель ISMS Copilot для цього кроку.
• copilot_cache_read_input_tokens і copilot_cache_creation_input_tokens: включаються лише тоді, коли постачальник моделі повідомляє про них.

Ця квитанція враховує лише токени на боці ISMS Copilot. Це не кількість токенів вашого агента і не включає те, що витрачає ваш оркестратор на запитання, схеми інструментів або читання відповіді; ваш оркестратор повідомляє про це самостійно. Об’єкт usage опускається, якщо дані ще не доступні (get_reply включає його, коли вони записані), а відповіді в режимі Beyond його не містять.

Де обліковується використання ISMS Copilot

Немає окремого продукту або лічильника для MCP. Делеговані кроки враховуються в межах вашого тарифного плану для чату ISMS Copilot:

• 4-годинне вікно використання. Кроки MCP використовують те саме 4-годинне вікно сеансу в UTC, що й додаток чату, у межах вашого особистого бюджету або пулу організації. Див. Розуміння обмежень використання.
• Перевищення ліміту. На платних індивідуальних облікових записах (не Essential, без Розширеного захисту даних) після вичерпання вікна ваш агент може продовжити роботу лише за вашою явною згодою, повторно надіславши запит із overflow_consent: true. Крок виконується на розкритих резервних моделях, до додаткових 2x ліміту токенів за тарифним планом. Перевищення ліміту ніколи не доступне для пулу команди.
• Запуски в режимі Beyond. Обмежені 10 на добу за UTC на платних тарифах, 50 – на Unlimited.

Використання моделі вашого оркестратора оплачується постачальником вашого оркестратора, як завжди.

Виміряні результати

Наразі триває робота над відтворюваним тестом делегування. Ми опублікуємо цифри тут разом із методом і датою їх вимірювання, і не раніше.