Limit Assist Consumption by Designing AI Agents which Avoid Loops

[TJL]

Introduction:

Welcome! This article is part of a series from the ServiceNow AI Center of Excellence (CoE) team. Our goal is to help customers implement and adopt AI Agents on ServiceNow. One key challenge when designing AI Agents is eliminating recursive loops – when an agent's actions cause it to re-trigger itself repeatedly. Architects must ensure autonomous AI Agents are triggered only when they add value and avoid unnecessary invocations that consume Assists without benefit.

This article teaches three complementary strategies for loop prevention. Part 1 explains how to choose and configure triggers that avoid cascading executions. Part 2 demonstrates filter condition patterns that naturally break loops, including the Assignment Group approach. Part 3 reveals built-in recursive check properties that act as safeguards when loops occur despite careful design.

For Simplicity:

Both Agentic Workflows and AI Agents use the same trigger system so throughout the remainder of the article, we’ll use “AI Agent” as shorthand for both. See the FAQs for more details on terminology.

Choosing When Your AI Agent Runs (Trigger Configuration)

Architects have several choices when selecting triggers for their AI Agents. You’re likely already familiar with many of these options because they exist in other places within the platform – like Workflow Studio – so are not unique to Agentic Workflows. In a flow or a script, creating an undesirable loop can diminish performance. With AI Agents, you also must consider limiting Assist consumption, which is the unit of measure for metering GenAI capabilities.

When building an AI Agent, you can choose from several trigger types:

• Record-Based Triggers
  • On Record Created
  • On Record Updated
  • On Record Created and Updated
• Time-Based Triggers
  • Scheduled (e.g., Daily, Weekly, Monthly)
• Application-Based Trigger
  • Inbound Email

Using Multiple Triggers Carefully:

You can add multiple triggers to the same AI Agent but exercise caution to avoid cascading executions. If your AI Agent modifies a record, ensure that the update doesn’t satisfy the condition filters on other triggers.

A Common Loop Scenario:

Consider an AI Agent that adds resolution plans to an incident’s work notes. If this agent uses both "On Record Created" and "On Record Updated" triggers, without proper filter conditions, the following loop occurs:

1. New incident creation fires the AI Agent
2. The AI Agent adds a resolution plan to work notes
3. Updating the work notes fires the "On Record Updated" trigger
4. The AI Agent is invoked again, adding another resolution plan
5. Loop continues repeatedly

Legitimate Use Cases for Multiple Triggers:

There are scenarios where you need to layer both “On Record Created” and “On Record Updated” triggers. For example, if in our scenario, the employee adds clarifying information about the nature of their request, you may want to refire the AI Agent to integrate the new details into the resolution plan.

This is acceptable if your filter conditions prevent loops – more details on how to design your filter conditions are covered in Part 2.

Use Caution When Leveraging an Inbound Email Trigger:

Avoid combining an Inbound Email trigger with "On Record Created" or "On Record Updated" triggers. When an email creates or updates a record, both triggers may fire, causing duplicate agent executions.

When to Use Scheduled Triggers:

Scheduled triggers should be used in AI Agents that analyze data across multiple records. For example, evaluating the short description and description fields across many incidents can help identify major incidents early. An AI Agent with a scheduled trigger could detect patterns like an influx of incidents that mention VPN connection issues and raise those incidents as candidates for major incident management.

Scheduled Trigger Limitations:

Do not perform looping within your Agentic Workflow. Instead, use a scheduled Flow or script (API Pathway) for looping and call the AI Agent to process each record. This is one area where the capabilities between AI Agents and Agentic Workflows differ – AI Agents can be invoked from flow actions or subflows in Workflow Studio, but Agentic Workflows cannot.

Architecting Trigger Condition Filters

Condition filters on a trigger determine which records activate your AI Agent. A well-designed filter acts as the first line of defense against loops by ensuring agents only process records meeting specific criteria.

If an autonomous AI agent logs activity to the work notes, like in the use case earlier, a simple filter like “Active is True AND State is Work in Progress” may invoke looping behavior. Since the record remains active and the state isn’t likely to advance, the filter condition stays true, causing the agent to retrigger continuously. To avoid this, ensure your AI Agent modifies a field that causes the filter condition on a “Record Updated” trigger to resolve as false.

Recommended Pattern: Filter using Assignment Group:

The Assignment Group pattern prevents loops by leveraging ownership transfer:

1. Assign the record to an assignment group with virtual workers
2. Configure the filter condition to activate AI Agents only for that specific group
3. Use an AI Agent tool to reassign the record to an assignment group with human fulfillers
4. The AI Agent processes the record, adding its recommendations to the work notes
5. Changing the assignment group causes the trigger condition to become false, preventing retriggering

Figure 1: Generic trigger configuration (left) creates infinite loops when agents update the same records they monitor. The Assignment Group pattern (right) resolves this by modifying the assignment group during processing.

Benefits:

• No custom fields are required
• ServiceNow automatically records assignment group changes, creating an audit trail
• If you’re already using Advanced Work Assignment (AWA) or Predictive Intelligence (PI), your existing rules can be leveraged when assigning to human fulfillers

Alternative Pattern: Custom True/False Flag:

Alternatively, add a simple true/false field to the form indicating whether the AI Agent has already processed the record. Note that other Now Assist skills leverage the State field, so avoid modifying the out-of-the-box State selections whenever possible.

AI Agent Properties Preventing Recursive Loops

Despite careful trigger and filter design, recursive loops may still occur. ServiceNow provides two types of built-in protections in AI Agent properties that act as fail-safes. Understanding these properties is essential when designing AI Agents, particularly for API pathway or batch processing scenarios where loops may be intentional. In these cases, it’s critical to understand how and why you’re experiencing rate limiting. You can find these properties by navigating to the sn_aia_property list where you’ll see protections with different default max execution values:

1. Create Record: Create record (recursive_check.query_for_create_record) identifies use cases fitting into the batch or API pathway scenario and counts the number of times that an Agentic Workflow or AI Agent was invoked to reach the same objective.
   • Default Maximums: The max number of executions for this recursive check is 50 executions (recursive_check.create_max_executions) within a 15-minute window (recursive_check.create_time_window).
   • Example: Let’s assume you have a batch use case which was initiated through a flow or script that processes all records created yesterday. If 60 records were created yesterday, then 50 would be processed and 10 would remain unprocessed – assuming they were invoked within the time window.
2. Update Record: Update record (recursive_check.query_for_update_record) identifies use cases where the AI Agent has updated a record but there’s an “On Record Update” trigger on the AI Agent and the filter condition still resolves to true firing additional invocations in perpetuity.
   • Default Maximums: The max number of executions for this recursive check is 5 executions (recursive_check.update_max_executions) within a 15-minute window (recursive_check.update_time_window).
   • Example: In our scenario earlier, let’s imagine that our filter condition was triggered autonomously on:
     • Record Created: Active is True AND State is New
     • Record Updated: Active is True AND State is New OR Work in Progress
     It’s easy to imagine how adding a resolution plan to work notes on record creation would update the record, and the filter condition on the second trigger would resolve as true. With the recursive check in place, the AI Agent will run 5 times and further actions from that AI Agent on the record will be rate limited.

Recursive loops occur for autonomous AI Agents only. If your AI Agent has supervised tools, it requires human approval for certain steps through fulfiller or requester interactions in the Now Assist Panel or in Now Assist for Virtual Agent.

Quick Reference Matrix:

Protection Type	Default Limit	Time Window	Use Cases
Create Record Check	50 Executions	15 Minutes	Scheduled Triggers that process batches of records Flows in Workflow Studio using AI Agents for processing
Update Record Check	5 Executions	15 Minutes	On Record Update Triggers On Record Created and Updated Triggers (monitors the update portion)

Important:

These properties provide safety nets, but proper trigger and filter design (Parts 1 & 2) remain your primary defense against loops.

Version Requirements:

If you are not seeing these properties in your instance, you should upgrade your Now Assist AI Agents plugin (sn_aia) from the ServiceNow Store to the latest or a minimum of v4.0.38. This plugin version is available as of Xanadu Patch 9+, Yokohama Patch 3+ and Zurich releases.

Understanding these built-in protections is essential, but proactive monitoring helps you detect loops before they impact operations.

Monitoring for Loops and Testing Recommendations:

It’s essential that you test AI Agents and their triggers thoroughly before promoting them into production. During your testing, start small to find recursive loops early before scaling up. Monitoring Assist consumption can help you detect loops early:

Navigate to:

Realtime Monitoring: AI Agent Analytics in AI Agent Studio > Status (tab)

Assist Monitoring: AI Agent Analytics in AI Agent Studio > Assist Consumption (tab)

The Status dashboard displays:

• AI Agent Execution Plans and AI Agent Executions and their status over the specified time period

The Assist dashboard displays:

• A graphical representation of Assists consumed over time
• Top 10 Agentic Workflows consuming the most amount of Assists
• The number of Assists consumed per Agentic Workflow/AI Agent

Warning Signs of a Loop:

• Testing a single AI Agent and observing multiple invocations via the Status dashboard
• Sudden spike in Assist consumption
• A single Agentic Workflow or AI Agent consuming an unusually high number of Assists

If you detect a loop, see the FAQ “What if I already have a loop in production?”

Summary and Production Checklist:

The three ways to limit recursive loops in AI Agents are: careful trigger selection, well-designed condition filters and leveraging the built-in AI Agent properties as safeguards. Combined with thorough testing, these approaches will ensure that performance and reliability are maintained while maximizing value. By following these leading practices, you’ll empower your organization to harness the full potential of AI Agents—confidently, efficiently, and without unexpected surprises.

Before Production Checklist:

• AI Agent modifies the loop-breaking field (e.g., Assignment Group or Custom flag field) early in execution
• Tested with at least 5-10 records in sub-production
• Verified recursive properties exist (in AI Agents plugin v4.0.38+)
• Quantified expected Assist consumption rate

If you have questions or thoughts, feel free to drop them in the comments—we’ll respond or update the article as needed. If you found this article helpful, please share your feedback or link to it on your preferred platform. Stay tuned for additional articles from the ServiceNow AI Center of Excellence.

For tailored guidance, reach out to your ServiceNow account team.

PS: Views are my own, and do not represent my team, employer, partners, or customers.

Frequently Asked Questions (FAQs):

What is an AI Agent Trigger?

A trigger starts your AI Agent automatically based upon an event (example: a new incident is created, or an email is received).

What ServiceNow versions does this article apply to?

Parts 1 & 2 discuss leading practices for AI Agent trigger selection and filter conditions so are relevant to any version which supports AI Agents - Xanadu Patch 7+, Yokohama Patch 1+ and Zurich releases.

Part 3 discusses built-in recursive check properties released in Now Assist AI Agents (sn_aia) v4.0.38, available on Xanadu Patch 9+, Yokohama Patch 3+, and all Zurich releases

What is the difference between an Agentic Workflow and an AI Agent?

ServiceNow uses both Agentic Workflows and AI Agents, and it’s important to understand the difference.

An Agentic Workflow is an overall business process or objective which is being automated. As an example, generating a resolution plan and categorizing and triaging incidents are two out-of-the-box (OOTB) Agentic Workflows which delegate tasks to a team of AI Agents.

AI Agents are specialized workers which Agentic Workflows can call when delegating tasks. As an example, you may have a record management AI Agent which reads and writes to a record or an agent which retrieves information from knowledge articles or finds similar resolved incidents/cases.

Where do I configure Triggers for Agentic Workflows?

Configure Triggers for Agentic Workflows by going to: All > AI Agent Studio > Create and Manage > Agentic Workflows > [Your Agentic Workflow] > Add preferred Trigger

Where do I configure Triggers for AI Agents?

Configure Triggers for AI Agents by going to: All > AI Agent Studio > Create and Manage >AI Agents > [Your AI Agent] > Define Trigger

Can AI Agents be triggered outside of an Agentic Workflow?

Yes, AI Agents are designed to be reusable across many Agentic Workflows or can be triggered to run on their own for specific tasks.

Can Agentic Workflows be triggered manually?

Yes, Agentic Workflows can be triggered via the Now Assist Panel, a UI Action or Declarative Actions in a Workspace.

Can AI Agents be triggered manually?

Yes, AI Agents can be called conversationally in Now Assist for Virtual Agent, using a UI Action or a Declarative Action. AI Agents can also be integrated into a flow (in Workflow Studio) to add GenAI capabilities to a workflow.

Do triggers affect Agentic Workflow and AI Agents Differently?

Triggers can be configured on either an Agentic Workflow or AI Agent. The same triggering mechanism and rules apply to both. When triggers are set on an Agentic Workflow it will employ a team of AI Agents to complete its objective. Due to that parent-child relationship you could say that the triggers on an Agentic Workflow apply to all AI Agents within that workflow.

What are the five autonomous trigger types?

ServiceNow provides five trigger types for AI Agents:

• Record-Based: On Record Created, On Record Updated, On Record Created and Updated
• Time-Based: Scheduled
• Trigger: Inbound Email

For detailed explanations and when to use each type, see the section above on Choosing When Your AI Agent Runs (Trigger Configuration)

What if I already have a loop in production?

Emergency steps:

Deactivate the trigger immediately

• Navigate to AI Agent Studio > Create and Manage
• Find your AI Agent or Agentic Workflow
• Go to Trigger tab
• Set trigger to Inactive or delete it

Check for active executions

• Navigate to the sn_aia_execution_plan table
• Sort: Created field (newest to oldest)
• Filter: State = In Progress
• Cancel stuck executions

Analyze the cause

• Review which fields your AI Agent updates
• Check if those updates satisfy trigger conditions
• Identify why conditions on the trigger didn’t become FALSE

Redesign and test

• Add a loop-breaking filter condition (see Part 2)
• Test with 5-10 records in sub-production
• Verify loop is resolved before re-enabling