Step 1 of 4
Measure usage and pick the core
The data decides what stays eager.
Analyze tool usage to define the core set. From transcript logs, compute per-tool: call frequency across sessions, task-type coverage (which task categories touch it), and first-call timing (tools needed in early turns favor eager loading). Also measure the token cost of each tool's definition. Core-set criteria: high frequency OR early-turn necessity OR safety-critical (permission gates should not be deferred). Everything else defers. Deliver: the ranked usage table, the core list (aim for the smallest set covering ~90% of calls), and the projected context savings from deferring the rest.
Expected after this step
A data-backed core set with projected savings.
Should not happen
- ✕Deferring a tool the model needs but never discovers, silently degrading capability
- ✕A catalog so verbose it costs as much as the definitions it replaced
- ✕Cache-hostile loading that invalidates the prompt prefix every registration
- ✕No measurement, so the 'optimization' is faith-based
Verify before continuing
Do not move on until every check is true. The complete button stays locked until then.
Do not continue if…
- !Deferring a tool the model needs but never discovers, silently degrading capability
- !A catalog so verbose it costs as much as the definitions it replaced
- !Cache-hostile loading that invalidates the prompt prefix every registration
- !No measurement, so the 'optimization' is faith-based
If the AI messes this up
Use this when the AI fakes progress or breaks the feature. It forces a real fix.
No usage logs exist. Instrument tool-call logging now and run a week of normal usage first - core-set guesses without data produce exactly the discovery failures this flow exists to avoid.