Building a Multi-Agent AI IT Service Desk Assistant on AWS with Strands Agents SDK and Amazon Bedrock

Enterprise IT service desks handle thousands of tickets weekly — from password resets to P1 production outages. The challenge isn't just volume; it's the cognitive overhead: triaging severity, diagnosing root cause across sprawling AWS infrastructure, executing the right remediation, managing change records, and communicating status to users and stakeholders — all under SLA pressure.

sweta jha

Published Jun 26, 2026

Last modified Jun 26, 2026

Building a Multi-Agent AI IT Service Desk Assistant on AWS with Strands Agents SDK and Amazon Bedrock

GitHub: https://github.com/its-me-sweta/IT_Service_Disk_AI_Assistant.gits

Introduction

In this post I'll walk through a production-ready, six-agent AI pipeline that automates the full ITIL service management lifecycle using:

Strands Agents SDK with @tool decorators
Amazon Bedrock Nova Pro for AI-driven diagnosis and response generation
AWS Systems Manager Automation for automated EC2 remediation
Amazon CloudWatch Metrics + Logs Insights for root cause analysis
FAISS + Amazon Titan Embed v2 for runbook RAG retrieval
Amazon ECS, ASG, Lambda for automated service remediation
Amazon DynamoDB for CMDB, KEDB, tickets, changes, and ITIL audit trail
Amazon SNS for P1 bridges, on-call paging, and stakeholder alerts
Amazon SES for user updates, resolution confirmations, and CSAT surveys
AgentCore Runtime for serverless deployment

Architecture Overview

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
                   ┌──────────────────────────────────────┐
                   │       FastAPI / REST Layer            │
                   │   POST /itsm/ticket                  │
                   └─────────────────┬────────────────────┘
                                     │
                   ┌─────────────────▼────────────────────┐
                   │         Orchestrator Agent            │
                   │  ITIL Triage · P1 Bridge · Audit     │
                   └──┬───────────────────────────────┬───┘
                      │                               │
         ┌────────────▼────┐             ┌────────────▼──────────┐
         │  Triage Agent   │             │   Diagnosis Agent     │
         │  CMDB · KEDB    │             │  CloudWatch · Logs    │
         │  Dedup · SLA    │             │  Runbook RAG · RCA    │
         └────────────┬────┘             └────────────┬──────────┘
                      └──────────┬────────────────────┘
                                 │
                   ┌─────────────▼────────────────────────┐
                   │      Auto-Remediation Agent           │
                   │  SSM · ECS · ASG · Lambda · Cache     │
                   │  Validate → Rollback if failed        │
                   └─────────────┬────────────────────────┘
                                 │
              ┌──────────────────┼──────────────────────┐
              │                  │                      │
   ┌──────────▼──────┐  ┌────────▼───────┐  ┌──────────▼──────┐
   │ Escalation      │  │ Change Mgmt    │  │ Notification    │
   │ Agent           │  │ Agent          │  │ Agent           │
   │ L2/L3 · On-call │  │ RFC · CAB · ERP│  │ SES · SNS       │
   │ War Room · SLA  │  │ Maintenance    │  │ Status Page     │
   └─────────────────┘  └────────────────┘  └─────────────────┘

The Six Agents

Agent	Role	AWS Services
Orchestrator Agent	ITIL triage, routing, P1 bridge	DynamoDB, SNS
Triage Agent	CMDB lookup, KEDB, dedup, SLA, impact	DynamoDB
Diagnosis Agent	CloudWatch, Logs, topology, runbook RAG, RCA	CloudWatch, Titan Embed v2, FAISS
Auto-Remediation Agent	SSM, ECS restart, ASG scale, cache flush, credential rotation	SSM, ECS, ASG, Lambda, Secrets Manager
Escalation Agent	L2/L3 routing, war room, on-call paging, Problem tickets	SNS, Lambda, DynamoDB
Change Management Agent	RFC, risk matrix, CAB approval, maintenance windows	DynamoDB
Notification Agent	User updates, Status Page, stakeholder briefs, CSAT	SES, SNS

ITIL Priority Framework

1
2
3
4
5
6
ITIL_PRIORITIES = {
    "P1": {"label": "CRITICAL", "response_min": 15,  "resolution_min": 60},
    "P2": {"label": "HIGH",     "response_min": 60,  "resolution_min": 240},
    "P3": {"label": "MEDIUM",   "response_min": 240, "resolution_min": 480},
    "P4": {"label": "LOW",      "response_min": 480, "resolution_min": 4320},
}

P1 triggers an immediate Major Incident Bridge — an SNS broadcast that creates a war room, pages the on-call engineer, and notifies C-suite stakeholders before any other processing continues.

Stage 1 — Triage Agent

CMDB Lookup — Every ticket is linked to a Configuration Item (CI) in DynamoDB, retrieving the CI's tier (TIER1/TIER2/TIER3), owner team, business service, and dependencies.

Known Error Database (KEDB) — If a matching known error exists, the workaround is returned immediately, potentially resolving the ticket before any diagnosis is needed.

Deduplication — Checks for open incidents on the same affected system. Duplicate tickets are linked to the parent and closed automatically.

Business Impact Assessment:

1
2
composite = (tier_score * 0.4) + (user_score * 0.4) + (env_score * 0.2)
revenue_risk = is_customer_facing and environment == "PRODUCTION" and ci_tier == "TIER1"

SLA Assignment — TIER1 CIs receive tighter SLAs than the base ITIL priority:

1
2
if ci_criticality == "HIGH" and priority != "P1":
    resp_min = max(resp_min // 2, 15)   # Minimum 15-minute response regardless

Stage 2 — Diagnosis Agent

The Diagnosis Agent performs AI-driven Root Cause Analysis across four data sources:

1. CloudWatch Metrics (30-minute pre-incident window):

1
2
3
@tool
def pull_cloudwatch_metrics(ci_name, namespace="AWS/EC2", lookback_minutes=30) -> dict:
    # CPU, memory, error rate — flags anomalies automatically

2. CloudWatch Logs Insights — Queries for ERROR/CRITICAL/FATAL log entries correlated with the incident timestamp:

1
2
3
query = """fields @timestamp, @message
           | filter @message like /ERROR|CRITICAL|FATAL|Exception/
           | sort @timestamp desc | limit 20"""

3. Topology Analysis — Checks upstream and downstream CI dependencies. Often the root cause is in a dependency rather than the reported CI.

4. Recent Change Correlation — Checks for deployments, config changes, or patches in the 24 hours before the incident:

1
causal_change_probability = 0.75 if recent_changes else 0.10

Confidence-based routing:

= 0.85: High confidence → proceed to auto-remediation
0.60–0.85: Medium → attempt remediation with monitoring
< 0.60: Low → escalate to L2 engineer

Runbook RAG uses FAISS + Titan Embed v2 to retrieve the most relevant troubleshooting runbook from the knowledge base.

Stage 3 — Auto-Remediation Agent

Six automated remediation actions available:

Root Cause	Tool	AWS Action
Capacity exhaustion	`scale_asg_capacity`	EC2 Auto Scaling Group scale-out
Service crash	`restart_ecs_service`	ECS force new deployment
EC2 issue	`run_ssm_automation`	SSM Automation document
Cache poisoning	`flush_cache`	ElastiCache flush via Lambda
App-level fix	`execute_lambda_fix`	Lambda remediation function
Credential compromise	`rotate_credentials`	Secrets Manager rotation

Safety rules:

1
2
3
4
if ci_tier == "TIER1":
    return {"requires_human_confirmation": True}   # NEVER auto-remediate Tier 1 without human
if confidence < 0.60:
    return {"escalation_required": True}           # Low confidence → human diagnosis

Validation + Rollback:

1
2
3
4
@tool
def validate_remediation(ticket_id, ci_name, expected_metric, threshold) -> dict:
    # 3-minute observation window + CloudWatch health check
    # If validation FAILS → rollback_remediation() is called immediately

Stage 4 — Escalation Agent

When auto-remediation fails or is not appropriate:

Team routing by category:

1
2
3
4
5
6
team_map = {
    "network":   "network_ops_team",
    "security":  "security_ops_center",
    "cloud_infra":"cloud_platform_team",
    "access":    "identity_access_team",
}

P1/P2 Escalation Protocol:

page_on_call() — SNS broadcast to the on-call engineer
open_war_room() — Creates dedicated Teams/Slack channel
create_incident_bridge() — Conference call for live coordination

Problem Management — If the same CI has had 3+ incidents in 30 days, a Problem ticket is automatically created and linked to all related incidents.

SLA Breach Alarm — A CloudWatch alarm fires 30 minutes before SLA breach:

1
2
cw.put_metric_alarm(AlarmName=f"SLA-BREACH-{ticket_id}",
                    AlarmActions=[ON_CALL_TOPIC], ...)

Stage 5 — Change Management Agent

When remediation requires a production change, the Change Management Agent:

Risk Matrix:

1
2
3
4
Risk Score = Impact (1-5) × Likelihood of failure (1-5)
 1–8:  Standard Change  (pre-approved, no CAB)
 9–15: Normal Change    (CAB approval, Wednesday 14:00 UTC)
16–25: Emergency Change (immediate, Emergency CAB notification)

TIER1 CIs automatically set Impact=5. Schema migrations, data migrations set Likelihood=4.

The RFC is linked to the originating incident ticket, and the change window is scheduled in the next available maintenance slot (Tuesday/Thursday 02:00–04:00 UTC for standard changes).

Stage 6 — Notification Agent

Status Page — P1/P2 incidents automatically post to the Status Page via SNS → webhook:

1
2
status_categories = ["operational", "degraded_performance",
                     "partial_outage", "major_outage", "maintenance"]

P1 Stakeholder Briefings — Sent every 30 minutes until resolution, including:

Current status and ETA
Actions taken so far
RCA summary (preliminary or confirmed)

Resolution Confirmation — Users receive a structured post-mortem summary:

1
2
Root Cause: Change-induced regression from RFC-2025-A1B2C3
Prevention: Automated regression tests added to deployment pipeline

KB Self-Learning — Resolved incidents that uncovered new known errors automatically update the KEDB, and runbooks that needed new steps are flagged for review.

AWS Infrastructure Summary

Resource	Purpose
Amazon Bedrock Nova Pro	AI diagnosis, response generation
Amazon Titan Embed v2	Runbook RAG embeddings
CloudWatch Metrics + Logs Insights	Anomaly detection and log correlation
AWS Systems Manager Automation	EC2 automated remediation
Amazon ECS	Container restart remediation
EC2 Auto Scaling	Capacity scaling remediation
AWS Lambda	App fixes, cache flush, war room, ERP sync
AWS Secrets Manager	Credential rotation
DynamoDB (10 tables)	Tickets, CMDB, KEDB, changes, problems, users, runbooks, comms, escalation log, analytics
Amazon SNS	P1 bridge, on-call paging, stakeholder alerts, Status Page
Amazon SES	User updates, resolution emails, CSAT surveys
AgentCore Runtime	Serverless agent deployment

Try It Yourself

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
git clone https://github.com/its-me-sweta/IT_Service_Disk_AI_Assistant.git
cd it-service-desk-assistant
pip install -r requirements.txt
uvicorn main:app --reload

curl -X POST http://localhost:8000/itsm/ticket \
  -H "Content-Type: application/json" \
  -d '{
    "requester_id": "EMP-001",
    "requester_name": "Sweta Jha",
    "requester_email": "sweta@company.com",
    "title": "Production API returning 503 errors",
    "description": "Users are getting 503 Service Unavailable on checkout API since 14:32 UTC. ~500 affected users.",
    "category": "application",
    "affected_system": "checkout-api-prod",
    "affected_user_count": 500,
    "channel": "monitoring"
  }'

Built with Strands Agents SDK · Amazon Bedrock Nova Pro · AgentCore Runtime

# aws-community-builders # aws-builders # ai-agents # strands

Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.

Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article

Builder Center

Building a Multi-Agent AI IT Service Desk Assistant on AWS with Strands Agents SDK and Amazon Bedrock

sweta jha

Building a Multi-Agent AI IT Service Desk Assistant on AWS with Strands Agents SDK and Amazon Bedrock

Introduction

Architecture Overview

The Six Agents

ITIL Priority Framework

Stage 1 — Triage Agent

Stage 2 — Diagnosis Agent

Stage 3 — Auto-Remediation Agent

Stage 4 — Escalation Agent

Stage 5 — Change Management Agent

Stage 6 — Notification Agent

AWS Infrastructure Summary

Try It Yourself