Main idea

A hook point named Stop suggests an ending: you picture it firing when you close the tool, once per session. It actually fires at the end of every turn — after each complete assistant response, whether it fits in one sentence or chained fifteen tool calls. Between the idea you have of it and what it does, the factor is several dozen.

The gap isn't a documentation detail, it changes what you can wire onto it. A job designed to run once a day — an expensive synthesis, an email send, a bulk write — becomes unusable at that cadence. Conversely, a mechanism that needs to see every exchange would be empty if it only fired at shutdown.

The real frequency is therefore the first thing to establish in front of a hook point, even before knowing what data it receives. The name is an indication of intent, not a specification.

Why it matters

The error isn't visible when you write it: the wired code works, it simply works far more often than expected. It is paid for afterwards in cost, in slowness or in volume of data produced, and the link with the initial misunderstanding is rarely made.

More generally, in any integration, the granularity of an event is a fact to be checked just as much as its format.

Nuances and limits

The real frequency also depends on usage: the same hook point fires twenty times in an intense working session and twice in a short one. It isn't a constant you can establish once and for all.

And the name isn't always misleading: the problem is taking it for a specification, not the fact that it evokes something.

Open questions

• How do you check the real frequency of an event before wiring a job onto it, other than by observing it in production?