Worth separating two different failure modes here, because they need different fixes.
Ungrounded responses and web search cause the agent to invent an answer when it has no data. If your agent is calling ServiceNow and getting a real response back, wrong IDs are not that. More likely the agent is passing the wrong argument to the tool, or getting several records back and choosing badly. Turning those settings off is good hygiene, but it will not fix this.
First, find out which is happening. Open Analytics, then Sessions, and read the transcript for a bad response. You will see the tool that was called, the exact arguments passed, and what came back. That tells you immediately whether the wrong record was requested or the wrong record was selected from a correct result. Everything after this depends on knowing which.
If the arguments are wrong, the usual causes are:
- Ambiguous parameter descriptions on the tool. The model chooses arguments from the description text, so "user identifier" invites it to pass a name where a sys_id is required. Be explicit about format and give an example.
- Missing required filters. If the tool can return multiple records and nothing constrains it, you get whatever comes first.
- The model resolving an identifier from conversation context rather than looking it up. This is common and is why you get a plausible-looking but wrong employee ID. If an ID has to come from a lookup, say so in the instructions, and add a separate lookup tool the agent must call first.
If the arguments are right but the record is wrong, the tool is returning a set and the agent is picking. Fix that at the tool, not in the prompt. Constrain the query so it returns one record, or return a small structured list and have the agent confirm with the user before acting.
A pattern that helps generally. Keep the deterministic work out of the model. Anything that is a lookup, a filter, or an exact match belongs in the tool definition or in a flow, not in the agent's judgement. The agent should be interpreting and summarizing, not deciding which sys_id to use.
If you can share the transcript for one bad response, arguments and result, that would narrow it quickly.
