Cosa risparmia la delega (e cosa no)

Quando l’agente di coding affida una domanda di conformità a ISMS Copilot, parte del lavoro viene eseguita lato ISMS Copilot invece che nel contesto dell’agente. Questa pagina spiega il meccanismo, ciò che non cambia e come vengono fatturati i due lati. Non afferma quanto si risparmia: dipende dall’orchestratore, dal modello e dal lavoro.

Perché il contesto dell’agente è importante

Un agente basato su chat non ricorda automaticamente i turni precedenti. A ogni turno, un tipico orchestratore invia al modello il suo transcript: le istruzioni, le definizioni degli strumenti, i messaggi precedenti, i file letti e i risultati degli strumenti. Tutto ciò che entra nel transcript viene inviato o elaborato nuovamente nei turni successivi e può contribuire all’utilizzo, soggetto a caching, compattazione e contabilità del provider. Anche la chat di ISMS Copilot funziona allo stesso modo, ed è per questo che i thread lunghi consumano di più la finestra di utilizzo per ogni messaggio.

Quindi la domanda non è solo quanto costa una singola risposta, ma cosa rimane nel transcript dell’agente in seguito.

Cosa rimane lato ISMS Copilot

Quando il lavoro viene delegato, gli elementi seguenti rimangono lato ISMS Copilot a meno che il risultato restituito non li riproduca. La richiesta MCP che l’agente invia e il risultato che riceve (la risposta più campi come ID, stato, utilizzo ed errori) entrano nel suo transcript, insieme agli schemi degli strumenti trattati più avanti:

• Materiale sorgente dei framework. I riferimenti a standard e regolamenti su cui ISMS Copilot basa le risposte. L’agente invia la domanda, non il testo del framework. La risposta può citare le parti rilevanti.
• Retrieval. Individuazione delle clausole, dei controlli e degli articoli pertinenti alla domanda e del contesto assemblato per il modello.
• Memorie e file dell’area di lavoro. In un turno con ambito workspace_id, vengono letti lato ISMS Copilot. L’agente non li carica, anche se la risposta può utilizzare dati da essi.
• Ragionamento intermedio. L’analisi dietro la risposta, compreso il lavoro multi-passaggio delle modalità Think e Beyond.
• Passaggi di stesura. Il testo lungo viene generato lato ISMS Copilot. L’agente riceve il risultato, non il processo di stesura.
• La copia del thread dello specialista. I follow-up con send_message continuano un thread che ISMS Copilot mantiene, quindi l’agente non reinvia i turni precedenti di quel thread nella richiesta. Le chiamate agli strumenti e le risposte precedenti rimangono comunque nel transcript dell’agente fino a quando non vengono rimosse.

Cosa paga ancora l’agente

La delega non rende gratuito il passaggio di conformità per l’orchestratore:

• Schemi degli strumenti. Le definizioni degli strumenti MCP di ISMS Copilot rimangono nel contesto dell’agente una volta che il server è connesso, come per qualsiasi altro server MCP.
• La domanda che invia. Qualsiasi cosa l’agente scriva in create_conversation o send_message fa parte del suo transcript.
• La risposta che legge. La risposta restituita è un input per il modello dell’agente e rimane nel transcript per il resto della sessione.

La risposta è la parte che si può controllare di più. Passare answer_format: "brief" (circa 150 parole) o "decision" (raccomandazione per prima, circa 300 parole) quando l’agente ha bisogno solo della conclusione. Quando il deliverable è un documento lungo, fare in modo che l’agente lo scriva su un file invece di ripeterlo nella chat. Vedi Delega il lavoro GRC dall’agente.

La ricevuta di utilizzo

Una risposta completata in modalità Fast o Think può includere un oggetto usage:

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

I valori sopra sono segnaposto. I campi sono:

• copilot_input_tokens e copilot_output_tokens: token elaborati e prodotti dai modelli di ISMS Copilot per quel turno.
• copilot_cache_read_input_tokens e copilot_cache_creation_input_tokens: inclusi solo quando il provider del modello li segnalati.

Questa ricevuta conta solo i token lato ISMS Copilot. Non è il conteggio dei token dell’agente e non include ciò che l’orchestratore spende per la domanda, gli schemi degli strumenti o la lettura della risposta; l’orchestratore segnalerà questi dati autonomamente. L’oggetto usage viene omesso quando i numeri non sono ancora disponibili (get_reply lo include una volta registrati), mentre le risposte Beyond non lo includono.

Dove viene fatturato l’utilizzo di ISMS Copilot

Non esiste un prodotto o un contatore MCP separato. I turni delegati vengono conteggiati nel piano chat di ISMS Copilot:

• La finestra di utilizzo di 4 ore. I turni MCP attingono dalla stessa finestra di sessione UTC di 4 ore dell’app chat, dal budget personale o dal pool dell’organizzazione. Vedi Comprendere i limiti di utilizzo.
• Overflow. Negli account individuali a pagamento idonei (non Essential, con la Protezione dati avanzata disattivata), quando la finestra è esaurita, l’agente può continuare solo con il consenso esplicito reinviando con overflow_consent: true. Il turno viene quindi eseguito sui modelli di fallback divulgati, fino a un limite aggiuntivo di 2x il limite di token del piano. L’overflow non è mai disponibile in un pool di team.
• Esecuzioni Beyond. Limitate a 10 al giorno UTC nei piani a pagamento, 50 in Unlimited.

L’utilizzo del modello dell’orchestratore viene fatturato dal provider dell’orchestratore, come al solito.

Risultati misurati

Un benchmark riproducibile della delega è in corso. Pubblicheremo i numeri qui con il metodo e la data in cui sono stati misurati, e non prima.