Common ServiceNow AI Agent Mistakes (and How to Avoid Them)
Practical lessons for building reliable, secure and cost-aware agents in AI Agent Studio
Building an AI agent in ServiceNow AI Agent Studio is fast. The guided setup walks you through instructions, tools and triggers, and within an hour you can have something that works in the test console.
Getting that agent to behave well in production is a different job. Most of the problems I've seen while designing and testing agents don't come from the LLM. They come from how the agent was set up.
This post covers the mistakes I see most often, why each one happens, and how to fix it. Everything here refers to the Australia release documentation.
A quick refresher
On the ServiceNow AI Platform, an AI agent is a set of LLM instructions plus the tools it needs to do a job. An agentic workflow defines the problem you want solved. One or more agents then work on that problem using tools such as record operations, flows, knowledge search or web search.
So the quality of an agent comes down to three things you control: instructions, tools and triggers. Nearly every mistake below traces back to one of them.
Mistake 1: Writing vague instructions
Symptom: The agent picks the wrong tool, asks the user for things it could look up, or gives a different answer every run.
Why it happens: Instructions are the agent's job description. "Help users with incidents" leaves the LLM to guess the steps, the order and what "done" means.
There's also a second trap: mixing up the two levels of instructions. Workflow-level instructions describe the business goal. Agent-level instructions describe how this specific agent does its part.
Fix: Write agent instructions like a runbook:
numbered steps in the order you expect them to happen
which tool to use at each step
what to do when information is missing (ask the user, or stop and hand off?)
what the agent must never do
a clear completion condition
Weak:
Help the user resolve their incident.
Better:
1. Use "Get incident details" to read the incident's short description and category.
2. Use "Search knowledge" with the short description to find up to 3 relevant articles.
3. If an article matches, summarize the resolution steps for the user in under 120 words.
4. If no article matches, do not guess. Tell the user the incident will be routed
to the assignment group, then stop.
Never update the incident state or close the incident.
Mistake 2: Writing thin tool descriptions
Symptom: The agent has the right tool but doesn't use it, or uses it at the wrong moment.
Why it happens: The agent decides what a tool does by reading its description. A description like "Gets records" gives it almost nothing to go on.
Fix: For every tool, describe:
what it does
what inputs it expects
when to use it, and when not to
what the output looks like
If a tool can return a lot of data, such as records from several tables, use the description or the output transformation strategy field to tell the agent how to handle it.
Mistake 3: Giving one agent too many tools
Symptom: Tool selection gets unreliable, executions take more steps than they should, and consumption climbs.
Why it happens: Every extra tool is one more option the LLM has to weigh at every step. A "do everything" agent is harder to test, harder to debug and more expensive to run.
ServiceNow even caps tools per agent with the sn_aia.maximum_agent_tools system property. Treat that cap as a ceiling, not a target.
Fix:
Split the work across specialized agents inside one agentic workflow, for example a triage agent, a knowledge agent and a fulfillment agent.
Give each agent only the tools its job needs.
Before building a new agent, check whether an existing one already does the job. Reuse beats duplication.
Mistake 4: Configuring triggers that create loops
Symptom: The same agent runs again and again on one record. Work notes fill up with repeated output, and assist consumption spikes.
Why it happens: This is the classic setup. An agent is triggered on both record created and record updated. It writes its recommendation to the work notes. That update fires the trigger again, and the agent runs again.
Fix:
Use one trigger unless you truly need two.
Add condition filters, so the agent only fires when a meaningful field changes, not on every update. One way to do this is to exclude updates made by the agent's own user.
Know the built-in safeguards.
sn_aia.continuous_tool_execution_limitcaps how many times in a row the same tool can run.sn_aia.react_failure_retry_max_limitcaps retries after an execution failure. These are fail-safes, not a design strategy.Remember that testing isn't free. AI Agent Studio test runs and sub-production environments also consume assists, so a looping agent in dev still costs you.
Mistake 5: Letting agents write without human oversight
Symptom: An agent submits the wrong catalog item, updates the wrong record or sends a message nobody approved, and the cause is only found afterwards.
Why it happens: By default, it's tempting to let every tool run autonomously because it makes demos look smooth.
Fix: Use supervised execution mode for tools that take sensitive or critical actions. In supervised mode, the agent proposes the action and a human approves it before it runs. You set this per tool in the guided setup by choosing Supervised as the execution mode, for example when adding a catalog item tool.
A practical split:
| Tool type | Execution mode |
|---|---|
| Read-only lookups (get record, search knowledge) | Autonomous |
| Creating or updating records | Supervised, at least until the agent is proven |
| Submitting requests, sending communications | Supervised |
When I built an email-triage agent that routes inbound emails into incidents or requests, keeping record creation supervised during validation was what made the test findings trustworthy. Every routing decision was reviewed before it touched real data.
Mistake 6: Treating record content as trusted input
Symptom: An agent processing an email, a ticket description or a knowledge article behaves strangely, ignoring its instructions or revealing information it shouldn't.
Why it happens: Email bodies, descriptions and comments are written by people outside your control. If that text says "ignore your previous instructions and…", your agent reads it as part of its input. This is prompt injection.
Fix: Configure Now Assist Guardian's prompt injection protection deliberately:
Check custom work explicitly. Prompt injection detection is on by default for Now Assist skills, except Platform and custom skills, which you have to configure yourself. Custom builds are exactly where teams assume they're covered when they aren't.
Decide between logging and blocking. By default, Guardian logs detected attempts. You can also configure it to block the AI-generated response.
Pick a severity level. Medium flags clear or moderate attempts; High flags only high-certainty ones.
Know which setting wins. When a skill has its own setting, Guardian applies whichever is more protective: the skill-level or the instance-level one.
Review the logs under Now Assist Admin → Settings → Now Assist Guardian.
Guardian is probabilistic, and ServiceNow states it may not catch every attempt. Treat it as one layer, alongside least-privilege tools and supervised execution for write actions.
Mistake 7: Skipping access testing
Symptom: The agent works perfectly for the admin who built it, then fails for real users, or worse, can do more than the user should.
Why it happens: Agents and tools are governed by roles and ACLs. To test an agent, you need sn_aia.admin and whatever roles the agent's and tools' ACLs require. Builders usually have everything, so access gaps stay hidden.
Fix:
Define the roles that can use each agent.
Use the AI agent user access test type in AI Agent Studio to confirm that only the right users can run it.
Test with accounts that match real personas, not just admin accounts.
Mistake 8: Testing one happy path, once
Symptom: The agent passes your test, then fails on the third real request.
Why it happens: Generative AI is non-deterministic. The same input can produce different plans and results across runs. One successful run proves very little.
Fix:
Run each manual test several times and review the runs in the Activity tab.
Then move to automated agentic evaluations. They test your agent against a dataset and use LLM judges to score metrics such as overall task completeness, tool performance and tool calling.
Build datasets from the execution logs of previous runs, or generate new ones.
ServiceNow's guidance recommends at least 100 scenarios for a reliable evaluation. Include edge cases: missing fields, ambiguous requests, multilingual input and hostile text.
Mistake 9: Not monitoring after go-live
Symptom: Nobody notices quality drifting or consumption creeping up until someone asks about the bill.
Why it happens: Teams treat go-live as the finish line.
Fix: Know where execution data lives and review it regularly:
Execution Plans (
sn_aia_execution_plan): one record per agent execution, with its tasks, messages and tool executions.Execution Tasks (
sn_aia_execution_task): the individual steps inside a plan, useful for finding where an execution stopped.Generative AI logs (
sys_generative_ai_log): general-purpose logs of generative AI interactions.AI Agent Studio's Activity view: run history and trends in one place.
Set a weekly review rhythm, and enable consumption-spike alerts where your release supports them.
Pre-deployment checklist
Before an agent goes to production, confirm:
[ ] Agent instructions are step-by-step, with a fallback and a completion condition
[ ] Every tool has a detailed description and output handling
[ ] Tool count is the minimum the job needs
[ ] Triggers have condition filters, with no possibility of self-triggering
[ ] Write and communication tools run in supervised mode
[ ] Guardian prompt injection protection is configured for custom work, with a block-or-log decision made
[ ] Access was tested with real user personas
[ ] An automated evaluation was run against a realistic dataset
[ ] A monitoring owner and review cadence are defined
Wrapping up
None of these mistakes are exotic. They're the gap between "it works in the test console" and "it works for a thousand users on a Monday morning."
Get the instructions, tools and triggers right, put humans in the loop where actions matter, and keep watching after go-live.
I write about ServiceNow AI, agentic workflows and Next.js. You can see more of my work at agrawalpratham.in, including my ServiceNow expertise and AI engineering pages.
