ServiceNow AI agent tools: build an evidence-first support flow

What ServiceNow AI agent tools are

ServiceNow's current AI Agent Studio guide defines tools as the capabilities that let an agent take action and retrieve data. It identifies script tools, subflows, and retrievers. The wider Skill Kit tool reference also includes flow actions, skills, web search, Predictive Intelligence, and Document Intelligence.

The Skill Kit catalog applies to tool nodes inside skills; do not assume its additional types are all direct Agent Studio tool choices. Whether you configure a direct agent tool or a skill that composes several steps, make each boundary explicit instead of hiding an entire business process behind one description.

Start with an evidence-first support job

Take a request: “My account has disappeared.” The tempting tool is a broad “find customer” API call. A better design asks what a human teammate would need before looking up or changing anything:

1. Which account evidence is required by policy?
2. Which records may the requester see?
3. What status fields are relevant to the support response?
4. Which outcome needs a human owner?

The first tool can validate whether the ticket includes the account email and a qualifying reference. The second can retrieve the permitted account status. A third can bring in the current policy. If any requirement is missing, the result is a precise clarification message or a handoff, not a speculative answer.

A tool output is useful only when another person can see why it was allowed to run and what it found.

Write tools for selection and review

ServiceNow's prompting guidance says the name, description, and input descriptions tell the orchestrator when and why to use a tool. Use names that describe the boundary: “Retrieve verified account status” is preferable to “Account tool.” Include the conditions that rule it out: “Do not call without a ticket number and approved account evidence.”

Then make the response contract concrete. A retrieval might return match found, authorisation status, account status, and a reason when nothing was returned. A downstream decision can distinguish “no match” from “not authorised” rather than treating both as a generic tool error. That is the difference between a support flow that can be fixed and one that only produces a mysterious failure.

Permissions are not a footnote

ServiceNow explains that ACLs decide who can discover and invoke an agent or workflow, while its user identity determines the data it can access and the actions it can take after invocation. Dynamic-user mode inherits the invoking user's roles. An AI user runs with fixed roles. Role masking can make the inherited set smaller. See ServiceNow's permissions guide for the full model.

For a script that accesses platform data, ServiceNow recommends GlideRecordSecure instead of GlideRecord to enforce table-level ACLs. For sensitive actions, ServiceNow's security documentation describes supervised mode, which requires human approval. Configure it where the action warrants approval; do not assume it applies to every tool automatically.

Test the missing-evidence branch

Test this small case set before a rollout:

• Valid ticket and verified account evidence: does the retrieval return only the approved fields?
• Correct ticket but missing account evidence: does the agent ask the right question or hand off?
• Evidence for another account: does access stop the lookup?
• Stale policy or no retrieval result: does the agent avoid filling the gap with an answer?
• API timeout or malformed result: does the workflow preserve the evidence and tell the next owner what failed?

The final response matters, but the tool trace matters too. Test the inputs, returned values, selected branch, and action that did or did not happen.

Inspect an eesel result before widening the task

eesel's AI helpdesk teammate can handle a defined support job in the environment a team already uses. Its dashboard, terminal, scripts, and coding agents such as Claude Code, Codex, and Cursor operate the same teammate and workspace. The CLI requires Node.js 18.17 or newer and returns JSON, so a script can inspect a result without creating another support system.

After a missing-account-evidence case, an operator can review the teammate's recent work and any held next step:

npx @eesel/cli activity --agent "Helpdesk"
npx @eesel/cli approvals --agent "Helpdesk"
npx @eesel/cli instructions --agent "Helpdesk"

eesel activity gives the work history to inspect; eesel approvals lists actions a human has chosen to hold; and eesel instructions checks the standing rule that should have produced the clarification or handoff. If a supported configuration update is appropriate, first run it with --dry-run, review the exact server call, then approve the real update. That is a positive operating loop: inspect the evidence, improve the teammate's rule or knowledge, test the defined failure again, and broaden the task only when it behaves as intended. The eesel CLI guide has the complete command reference.

The eesel Activity page shows recent work and status filters for reviewing a handoff.

Use tools to produce a better next step

The point of a ServiceNow AI agent tool is not to maximise actions. It is to give the next person or system the right evidence and a safe, understandable next step. Start with retrieval and a handoff, test the cases where evidence is weak, then add narrowly approved actions only when the job requires them.

Review one support result before you add authority

eesel gives a support team one AI teammate it can operate from the dashboard, terminal, or a coding workflow. Use that shared view to inspect knowledge, instructions, activity, and held actions around a real support case. Try eesel when you want to test the next step before you grant more scope.