Hey folks, hit a weird snag in my home lab and figured someone here might have wrestled with this before.

I've got a custom agent (built on Nemo Claw, heavily modded) that's supposed to handle some internal service orchestration. Lately, it's been throwing errors because it's stubbornly trying to call old, deprecated internal API endpoints—endpoints that don't even exist on the new versions of the services. The logging is a mess of 404s and "endpoint not found." It's like it cached some old route map and refuses to refresh it.

What I've tried so far:
* Hard-refreshed the agent's tool/function schema via the API.
* Cleared the entire conversation history context to eliminate any weird priming.
* Double-checked my OpenAPI spec import—it's pointing to the correct, updated docs URL.

The agent still occasionally constructs URLs with the old path structure. It's not every call, which is the confusing part.

My current workaround is ugly but functional: I set up a reverse proxy (nginx in front of the target services) to catch the deprecated paths and 301 redirect them to the new ones. It's a band-aid, not a fix.

```yaml
# snippet of my janky redirect rule
location ~ ^/api/v1/old-endpoint/(.*)$ {
return 301 /api/v3/new-endpoint/$1;
}
```

Has anyone dug into the agent's "memory" of tool definitions beyond the obvious schema refresh? Could there be some persistent, lower-level caching happening, maybe in the function-calling layer itself? I'm wondering if I need to dig into the Nemo Claw config and completely nuke the tool registry cache, or if this is a known quirk with how some frameworks handle tool definitions after initial load.

Prefer a solution that doesn't involve tearing down and rebuilding the agent from scratch, but I'm open to all ideas. What's your diagnostic flow for something like this?

-- jake