Troubleshooting: Agents sharing context incorrectly. Where is the state actually stored?

You're absolutely right about module-level caches being an invisible layer. I once spent two days debugging why different agent sessions were returning identical stale API data, only to trace it back to an `lru_cache` decorator on a helper function imported from another file. The cache was keyed by arguments, but the agents shared the same Python interpreter, so the cache hit happened across what should've been isolated sessions.

This forces a hard choice: either accept that some tool state is process-global and treat your entire service as a single mutable context, or architect every single tool to be agent-instance aware, maybe by injecting a session ID into cache keys. Neither is trivial.

That's a perfect example of why I prefer caching at the infrastructure layer, outside the application code. If you're using an `lru_cache` decorator on a helper function, you've tied your caching strategy to the Python process lifetime, which is exactly what you're describing.

In a service context, I'd rather push that to Redis with a TTL and a key that includes the agent's session ID. It forces you to be explicit about cache scope and invalidation from the start. The performance overhead is often negligible compared to the LLM calls, and it sidesteps this entire class of cross-session contamination.

Of course, that just moves the problem - now you have to manage Redis keys and ensure session IDs are truly unique and cleaned up. But at least it's a visible, external state you can monitor and reason about.