Qué ahorra la delegación (y qué no)

Cuando su agente de codificación delega una pregunta de cumplimiento a ISMS Copilot, parte del trabajo se realiza en el lado de ISMS Copilot en lugar de en el contexto de su agente. Esta página explica el mecanismo, qué no cambia y cómo se facturan ambos lados. No afirma cuánto se ahorra: esto depende de su orquestador, de su modelo y de su trabajo.

Por qué importa el contexto de su agente

Un agente basado en chat no recuerda las interacciones anteriores por sí mismo. En cada turno, un orquestador típico envía al modelo su historial nuevamente: sus instrucciones, las definiciones de herramientas, mensajes anteriores, archivos que leyó y resultados de herramientas. Cualquier elemento que entre en ese historial se envía o procesa de nuevo en turnos posteriores y puede contar para el uso, sujeto a caché, compresión y contabilidad del proveedor. El chat de ISMS Copilot funciona de la misma manera, por lo que los hilos largos consumen más de su ventana de uso por mensaje.

Por lo tanto, la pregunta no es solo cuánto cuesta una respuesta individual, sino qué permanece en el historial de su agente después.

Qué permanece en el lado de ISMS Copilot

Cuando el trabajo se delega, los elementos siguientes permanecen en el lado de ISMS Copilot a menos que el resultado devuelto los reproduzca. La solicitud MCP que envía su agente y el resultado que recibe (la respuesta, más campos como IDs, estado, uso y errores) sí entran en su historial, junto con los esquemas de herramientas cubiertos más adelante:

• Material de origen de los marcos. Las referencias a estándares y regulaciones en las que ISMS Copilot basa sus respuestas. Su agente envía la pregunta, no el texto del marco. La respuesta puede citar o referenciar las partes relevantes.
• Recuperación. Búsqueda de los artículos, controles y cláusulas relevantes para la pregunta, así como el contexto ensamblado para el modelo.
• Memorias y archivos del espacio de trabajo. En un turno con ámbito workspace_id, se leen en el lado de ISMS Copilot. Su agente no los carga, aunque la respuesta puede usar datos de ellos.
• Razonamiento intermedio. El análisis detrás de la respuesta, incluido el trabajo de varios pasos de los modos Think y Beyond.
• Pasos de redacción. El texto largo se genera en el lado de ISMS Copilot. Su agente recibe el resultado, no el proceso de redacción.
• La copia del hilo del especialista. Las interacciones posteriores con send_message continúan un hilo que ISMS Copilot mantiene, por lo que su agente no vuelve a enviar los turnos anteriores de ese hilo en su solicitud. Las llamadas a herramientas y respuestas anteriores siguen en el historial de su agente hasta que este las elimine.

Qué sigue pagando su agente

La delegación no hace que el paso de cumplimiento sea gratuito para su orquestador:

• Esquemas de herramientas. Las definiciones de herramientas MCP de ISMS Copilot están en el contexto de su agente una vez que el servidor está conectado, como las herramientas de cualquier otro servidor MCP.
• La pregunta que envía. Lo que su agente escribe en create_conversation o send_message forma parte de su historial.
• La respuesta que lee. La respuesta devuelta es una entrada para el modelo de su agente y permanece en el historial durante el resto de la sesión.

La respuesta es la parte que más controla. Use answer_format: "brief" (aproximadamente 150 palabras) o "decision" (recomendación primero, aproximadamente 300 palabras) cuando su agente solo necesite la conclusión. Si el entregable es un documento largo, haga que su agente lo escriba en un archivo en lugar de repetirlo en el chat. Consulte Delegar trabajo de GRC desde su agente.

El recibo de uso

Una respuesta completada de Fast o Think puede incluir un objeto usage:

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

Los valores anteriores son marcadores de posición. Los campos son:

• copilot_input_tokens y copilot_output_tokens: tokens que los modelos de ISMS Copilot procesaron y produjeron para ese turno.
• copilot_cache_read_input_tokens y copilot_cache_creation_input_tokens: incluidos solo cuando el proveedor del modelo los informa.

Este recibo cuenta solo los tokens del lado de ISMS Copilot. No es el conteo de tokens de su agente y no incluye lo que su orquestador gasta en la pregunta, los esquemas de herramientas o la lectura de la respuesta. Su orquestador informa esos valores por su cuenta. El objeto usage se omite cuando los números aún no están disponibles (get_reply lo incluye una vez que se registran), y las respuestas de Beyond no lo llevan.

Dónde se factura el uso de ISMS Copilot

No hay un producto o medidor MCP separado. Los turnos delegados se descuentan de su plan de chat de ISMS Copilot:

• La ventana de uso de 4 horas. Los turnos MCP consumen de la misma ventana de sesión UTC de 4 horas que la aplicación de chat, dentro de su presupuesto personal o del grupo de su organización. Consulte Comprender los límites de uso.
• Desbordamiento. En cuentas individuales de pago elegibles (no Essential, con la Protección de datos avanzada desactivada), cuando la ventana se agota, su agente puede continuar solo con su consentimiento explícito al reenviar con overflow_consent: true. El turno se ejecuta entonces en los modelos de respaldo divulgados, hasta un límite adicional de 2 veces el límite de tokens del plan. El desbordamiento nunca está disponible en un grupo de equipo.
• Ejecuciones de Beyond. Limitadas a 10 por día UTC en planes de pago, 50 en Unlimited.

El uso del modelo de su orquestador se factura por su proveedor de orquestador, como de costumbre.

Resultados medidos

Un benchmark reproducible de la delegación está en curso. Publicaremos los números aquí con el método y la fecha en que se midieron, y no antes.