AI Agents for Service Mapping
The Service Mapping AI agents automate the creation and maintenance of service maps in the Configuration Management Database (CMDB), reducing manual effort for Service Mapping administrators.
AI Agents for Service Mapping include three AI Agents that automate key parts of the Service Mapping workflow. After activation, all agents run autonomously in the background on a recurring schedule, processing all relevant records without requiring administrator input for each one.
Available AI Agents
The ITOM AI Agents for Service Mapping application [sn_sm_gen_ai] provides three AI Agents:
- Service Mapping AI Agent
-
Automatically creates ML-based service maps from Application Service Candidates (ASCs) and persists the full service topology in the CMDB. This Agent evaluates ML-powered candidates, focuses on those with a high-confidence name suggestion source such as Service Fingerprints (SFPs), filters out noise (such as monitoring clients, security clients, and operating system processes), and creates the service topology. Created service maps are set to non-operational by default so that the Service Mapping administrator can review them before making them operational.
- Business App Mapping AI Agent
-
Automatically creates Common Service Data Model (CSDM) "Uses::Used by" relationships between Business Applications [cmdb_ci_business_app] and discovered Application Services [cmdb_ci_service_discovered]. This Agent uses AI semantic search to find the best-matching discovered services for each business application and writes the relationship to [cmdb_rel_ci]. High-confidence matches are connected automatically. Medium-confidence matches are saved to a staging table for administrator review.
- Tag-Based Service Map Creation AI Agent
-
Automatically creates service maps from tag-based candidates generated by cloud infrastructure metadata. This Agent analyzes cloud tags (such as Application and Environment) applied to virtual machines and determines whether they represent real, coherent business services. The Agent performs two critical evaluations:
- It signals whether the tag represents a meaningful business service using both the tag name and running process evidence.
- It verifies that all virtual machines (VMs) grouped under the tag actually belong to the same application service rather than multiple unrelated systems that share a tag. Created service maps are set to non-operational by default.
Why these AI Agents are needed
Without these AI Agents, Service Mapping administrators have to manually review each ML-powered candidate or tag-based candidate and decide whether to create a service map. Similarly, connecting discovered application services to their business application context in the CSDM required manual one-to-one or one-to-many mapping. Using the AI Agents makes these processes significantly less time-consuming and enables processing at a much larger scale.
The following examples illustrate the challenges these AI Agents solve.
Consider a bank that has a payment application defined as a business application. Under it, Service Mapping discovers many application services: online payment processing, cash payment handling, net banking, and mobile payment systems. Business stakeholders are only concerned with the payment application at the top level and need it connected to all the relevant discovered services so they can monitor health and impact. Manually maintaining these connections as new application services are created is impractical. The Business App Mapping AI Agent solves this by iterating over all business applications and automatically finding and connecting the matching discovered services, working top-down from the smaller set of business applications to the larger set of discovered application services.
In a typical scenario, an organization runs hundreds of servers and generates a large number of ML-powered candidates daily. A Service Mapping administrator who previously had to manually evaluate each candidate and create a service map can instead activate the Service Mapping AI Agent, which processes all high-confidence candidates automatically, creates service maps, and sets them to non-operational for administrator review.
Organizations using cloud infrastructure often apply metadata tags (such as Application and Environment) to virtual machines for organization and governance. However, manual service creation from these tags is time-consuming and error-prone, especially at scale. The Tag-Based Service Map Creation AI Agent solves this by automatically analyzing tagged infrastructure, detecting when multiple unrelated systems are incorrectly grouped under a single tag, and creating service maps only when the tag represents a real, coherent business application.
How AI Agents work
All agents use a ReAct (Reasoning and Acting) strategy. The agent reasons about each step before deciding which tool to invoke. After activation, a script runs every 15 minutes. On each run, the agent processes all relevant records in a single batch — for example, all business applications in the system — without any per-record input from an administrator.
Service Mapping AI Agent process:
- The agent retrieves full ML candidate data from the Application Service Candidate (ASC) record, including the candidate name, process name, and server count.
- The agent performs a noise check. If the candidate is flagged as noise, such as monitoring clients, security clients, or operating system processes, the agent skips it.
- The agent retrieves all running processes associated with the candidate.
- The agent analyzes the data and reasons about what the actual service is, prioritizing candidates with a high-confidence name suggestion source such as Service Fingerprints (SFPs).
- The agent creates the service topology in the CMDB and sets the service to non-operational. If a topology for the same candidate already exists, the agent skips creation.
Business App Mapping AI Agent process:
- The agent retrieves all Business Application records from [cmdb_ci_business_app].
- For each business application, the agent runs an AI semantic search against [cmdb_ci_service_discovered] using the application name and description as the query. The search returns up to 30 candidates, ordered by relevance score (0–1).
- Candidates with a score of 0.3 or higher are automatically connected. The agent creates a Uses::Used by relationship in [cmdb_rel_ci]. A business application can be linked to multiple services if multiple candidates qualify.
- Candidates with a score of 0.1–0.29 are saved to the staging table [sn_sm_gen_ai_ba_candidate_rel] for administrator review. No relationship is created automatically for these.
- Candidates below 0.1 are filtered out. The agent does not create a record or a relationship for these.
- The agent retrieves a tag-based candidate record from [svc_by_tags_candidates], including the cloud tags (such as Application and Environment) and the set of member virtual machines.
- The Agent validates the candidate through prerequisite checks: confirming it is not hidden, ensuring at least 2 configuration items (CI) exist to form a topology, and verifying no existing service already maps it.
- The agent performs a coherence evaluation by analyzing the running processes and process groups (AFP groups) across all member VMs. It determines whether all VMs running under this tag belong to the same application service or whether multiple unrelated systems are incorrectly grouped.
- If the candidate is incoherent (containing multiple distinct business systems), the agent records the outcome and skips service creation, flagging the candidate for administrator review.
- If the candidate is coherent or uncertain, the agent evaluates the signal strength by combining the cloud tag name (for example, "order-management") with running process evidence to determine whether a real business service exists.
- If the signal is strong enough, the agent derives a service name using this priority order:
- Service Fingerprint (SFP) name if the candidate's CIs match an Application Service Fingerprint in the Discovery Content Library.
- Strong cloud tag value if no service fingerprint exists.
- AFP process-derived name if the tag signal is weak and no fingerprints exist.
Activation and monitoring
All agents are inactive by default. A user who has the Service Mapping admin role activates them from the Service Mapping home page. For procedural information, see Activate AI Agents for Service Mapping.
The Service Mapping AI Agent and Tag-Based Service Map Creation AI Agent are activated together through a single workspace activation button. The Business App Mapping AI Agent is activated independently.
No configuration in AI Agent Studio is required for Service Mapping administrators; AI Agent Studio is used by platform administrators or users who have the AI admin role to manage agent definitions and token usage.
After activation, administrators can monitor activity and review results in the AI Activity section of the Service Mapping list navigation. For more information, see Service Mapping AI Agent activity list tables.
Service maps created by any AI Agent are non-operational by default and can be made operational from the application service record in the Mapped Application Services list.
AI Agent processing quota
Each AI Agent can process up to 100 records by default. When an AI Agent reaches this limit, it stops processing and its status is set to Paused.
- For the Service Mapping AI Agent: sn_sm_gen_ai.agent_invocation_limit.ServiceMapCreationAISpecialist
- For the Business App Mapping AI Agent: sn_sm_gen_ai.agent_invocation_limit.CSDMBusinessApplicationtoInfrastructureAISpecialist
- For the Tag-Based Service Map Creation AI Agent: sn_sm_gen_ai.agent_invocation_limit.TagBasedServiceMapCreationAISpecialist