Wat delegatie bespaart (en wat niet)

Wanneer je coding agent een compliancevraag doorgeeft aan ISMS Copilot, vindt een deel van het werk aan de kant van ISMS Copilot plaats in plaats van in de context van je agent. Deze pagina legt het mechanisme uit, wat er niet verandert en hoe de twee kanten in rekening worden gebracht. Er wordt geen claim gedaan over hoeveel je bespaart: dat hangt af van je orchestrator, je model en je werk.

Waarom de context van je agent belangrijk is

Een chatgebaseerde agent onthoudt eerdere beurten niet uit zichzelf. Bij elke beurt stuurt een typische orchestrator het model opnieuw de transcriptie: je instructies, de tooldefinities, eerdere berichten, gelezen bestanden en toolresultaten. Alles wat in die transcriptie terechtkomt, wordt bij latere beurten opnieuw verzonden of verwerkt en kan meetellen voor het gebruik, afhankelijk van caching, compaction en de boekhouding van de provider. De eigen chat van ISMS Copilot werkt op dezelfde manier, vandaar dat lange threads meer van je gebruikvenster per bericht verbruiken.

De vraag is dus niet alleen wat een enkel antwoord kost, maar wat er na afloop in de transcriptie van je agent blijft staan.

Wat aan de kant van ISMS Copilot blijft

Wanneer het werk wordt gedelegeerd, blijven de volgende items aan de kant van ISMS Copilot, tenzij het geretourneerde resultaat ze reproduceert. Het MCP-verzoek dat je agent verzendt en het resultaat dat het terugkrijgt (het antwoord plus velden zoals ID's, status, gebruik en fouten) komen wel in de transcriptie terecht, samen met de toolschema's die verderop worden besproken:

• Bronmateriaal van het framework. De standaard- en regelgevingsreferenties waarop ISMS Copilot zijn antwoorden baseert. Je agent verzendt de vraag, niet de frameworktekst. Het antwoord kan de relevante delen citeren of vermelden.
• Opzoeken. Het vinden van de relevante artikelen, controles en bepalingen voor de vraag, en de context die voor het model is samengesteld.
• Werkruimtegeheugen en bestanden. Bij een beurt met workspace_id worden deze aan de kant van ISMS Copilot gelezen. Je agent laadt ze niet, hoewel het antwoord feiten daaruit kan gebruiken.
• Tussenliggende redenering. De analyse achter het antwoord, inclusief meerstaps Think- en Beyond-werk.
• Conceptversies. Lange tekst wordt gegenereerd aan de kant van ISMS Copilot. Je agent ontvangt het resultaat, niet het conceptproces.
• De kopie van de thread van de specialist. Opvolgacties met send_message zetten een thread voort die ISMS Copilot bijhoudt, zodat je agent eerdere beurten van die thread niet opnieuw in het verzoek hoeft te sturen. De eerdere toolaanroepen en antwoorden blijven wel in de eigen transcriptie van je agent staan totdat deze ze verwijdert.

Waar je agent nog wel voor betaalt

Delegatie maakt de compliance-stap niet gratis voor je orchestrator:

• Toolschema's. De ISMS Copilot MCP-tooldefinities staan in de context van je agent zodra de server is verbonden, net als de tools van elke andere MCP-server.
• De vraag die het verzendt. Alles wat je agent in create_conversation of send_message schrijft, maakt deel uit van de transcriptie.
• Het antwoord dat het leest. Het geretourneerde antwoord is input voor het model van je agent en blijft in de transcriptie staan voor de rest van de sessie.

Het antwoord is het deel waar je de meeste controle over hebt. Gebruik answer_format: "brief" (ongeveer 150 woorden) of "decision" (aanbeveling eerst, ongeveer 300 woorden) wanneer je agent alleen de conclusie nodig heeft. Als de opgave een lang document is, laat je agent dit dan naar een bestand schrijven in plaats van het in de chat te herhalen. Zie Delegeer GRC-taken vanaf je agent.

De gebruiksafrekening

Een voltooide Fast- of Think-reactie kan een usage-object bevatten:

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

De bovenstaande waarden zijn plaatshouders. De velden zijn:

• copilot_input_tokens en copilot_output_tokens: tokens die de modellen van ISMS Copilot voor die beurt hebben verwerkt en gegenereerd.
• copilot_cache_read_input_tokens en copilot_cache_creation_input_tokens: alleen opgenomen wanneer de modelprovider deze rapporteert.

Deze afrekening telt alleen tokens aan de kant van ISMS Copilot. Dit is niet de tokentelling van je agent en omvat niet wat je orchestrator uitgeeft aan de vraag, de toolschema's of het lezen van het antwoord. Je orchestrator rapporteert deze zelf. Het usage-object ontbreekt wanneer de cijfers nog niet beschikbaar zijn (get_reply voegt deze toe zodra ze zijn geregistreerd). Beyond-reacties bevatten dit object niet.

Waar ISMS Copilot-gebruik in rekening wordt gebracht

Er is geen apart MCP-product of -meter. Gedelegeerde beurten tellen mee voor je ISMS Copilot-chatplan:

• Het gebruikvenster van 4 uur. MCP-beurten putten uit hetzelfde 4-uurs UTC-sessievenster als de chat-app, binnen je eigen budget of de pool van je organisatie. Zie Gebruikslimieten begrijpen.
• Overflow. Op geschikte betaalde solo-accounts (niet Essential, met Geavanceerde gegevensbescherming uitgeschakeld) kan je agent, wanneer het venster is opgebruikt, alleen doorgaan met je expliciete toestemming door opnieuw te verzenden met overflow_consent: true. De beurt wordt dan uitgevoerd op de bekendgemaakte fallback-modellen, tot maximaal 2x de tokenlimiet van het plan. Overflow is nooit beschikbaar in een teampool.
• Beyond-runs. Beperkt tot 10 per UTC-dag op betaalde plannen, 50 op Unlimited.

Het modelgebruik van je orchestrator wordt, zoals gebruikelijk, in rekening gebracht door de provider van je orchestrator.

Gemeten resultaten

Een reproduceerbare benchmark voor delegatie is in uitvoering. We publiceren de cijfers hier met de methode en de datum waarop ze zijn gemeten, en niet eerder.