ServiceNow agent targets an 80% cut in catalog development costs

From browser control to API access

The first version, built in early 2025, used browser automation to operate ServiceNow and other enterprise applications through their interfaces. The team later moved to the Model Context Protocol (MCP) to connect directly to APIs and work faster.

A custom orchestration layer combines probabilistic model reasoning with deterministic code. It supports multiple large language models and is meant to make checks and execution more consistent. The agent can answer questions about ServiceNow, but also carry out tasks in the system.

To fit the way each organization works, the team gives the agent context about its knowledge articles, catalog items and naming conventions. Reusable instructions, including SKILL.md files, sit alongside company knowledge and memory. The agent can also review requirements documents and flag missing information before starting.

Human control remains part of the workflow: a person reviews and approves every write. The agent connects through OAuth using a ServiceNow user account and follows that account’s roles and permissions. Update sets let the team deploy configuration changes through its usual process or roll them back.

The team also tracks what the agent did, whether the result worked and what it cost. Those measures, along with tests on real ServiceNow data, are used to assess and improve it.

Two parts proved harder than expected: teaching the agent to interpret organization-specific requirements reliably, and identifying the real pain points in deployment. Those problems were narrower and more repetitive than the roadmap had assumed. The team’s takeaway was to start with one process that is repeatable, rule-based, high-volume, measurable and easy to reverse.

The clearest case: catalog development

A catalog item can take hours or days to build, and a complex one can take one to two weeks. Requirements often arrive in Excel, Word or Jira. A developer must interpret them, create variables and form fields, configure workflows and sometimes write scripts and service-level agreements (SLAs).

With a requirements document in a standard format, the digital worker can prepare an item, including its workflow and related scripts, in about 20 seconds. A user can review the result, such as a request form, inside the worker and then move it into the platform with a few clicks.

The team still uses its existing requirements template. The difference is that staff can run the catalog builder as they gather requirements and see a result almost immediately. That saves several days on a simple item and up to a week on a more complex workflow, allowing the team to review changes with customers sooner and test ideas without a long development cycle.

The company expects to automate more of the catalog-development process and use the worker at scale. Its projected outcome is an 80% reduction in development costs and roughly 25% of team capacity freed for higher-priority platform work.

Beyond building forms

The other use cases are less about creating things and more about making operational data easier to interpret.

The team says an analysis that once took several hours can now take 10–15 minutes of conversation with the worker. Recurring checks can be scheduled, leaving staff less time spent on dashboards and manual interpretation and more time to address the problems those checks uncover.

I think the 80% figure deserves a careful reading: it is a projected saving from scaling catalog automation, not a reported reduction already achieved across the team. The pilot’s more concrete evidence is the roughly 20-second preparation time and the days or week it can save in development. The announcement is quieter about how often the requirements arrive in a format the agent can handle, how much review each result needs, and how the projected saving was calculated.

That distinction matters because the agent still depends on company-specific context and human approval before changes are written. Its strongest case is not that it removes the people who understand ServiceNow, but that it may give them a faster first draft and a quicker way to investigate patterns. If those narrow workflows hold up at scale, the broader promise is less about replacing ITSM expertise than making more of it available for work that needs judgment.