Idea principal

Un punto de enganche llamado Stop evoca un final: te lo imaginas disparándose cuando cierras la herramienta, una vez por sesión. En realidad se dispara al final de cada turno — después de cada respuesta completa del asistente, tanto si cabe en una frase como si ha encadenado quince llamadas a herramientas. Entre la idea que te haces de él y lo que hace, el factor es de varias decenas.

La diferencia no es un detalle de documentación, cambia lo que puedes conectarle. Un procesamiento diseñado para ejecutarse una vez al día — una síntesis costosa, un envío de correo, una escritura masiva — se vuelve inutilizable a esa cadencia. A la inversa, un mecanismo que necesita ver cada intercambio estaría vacío si solo se disparase al cerrar.

La frecuencia real es, por tanto, lo primero que hay que establecer ante un punto de enganche, incluso antes de saber qué datos recibe. El nombre es una indicación de intención, no una especificación.

Por qué es importante

El error no se ve al escribirlo: el código conectado funciona, simplemente funciona mucho más a menudo de lo previsto. Se paga después en coste, en lentitud o en volumen de datos producidos, y rara vez se establece el vínculo con el malentendido inicial.

De forma más general, en cualquier integración, la granularidad de un evento es un dato que hay que verificar igual que su formato.

Matices y límites

La frecuencia real depende también del uso: el mismo punto de enganche se dispara veinte veces en una sesión de trabajo intensa y dos veces en una sesión corta. No es una constante que puedas establecer de una vez por todas.

Y el nombre no siempre engaña: el problema es tomarlo por una especificación, no el hecho de que evoque algo.

Preguntas abiertas

• ¿Cómo verificar la frecuencia real de un evento antes de conectarle un procesamiento, más allá de observarlo en producción?