AWS Builder Center

Builder Center

What is Bedrock Managed Agent (powered by OpenAI)?

Amazon Bedrock Managed Agents powered by OpenAI combines the reasoning capabilities of OpenAI models with AWS-managed agent infrastructure. Instead of building a traditional application where every step of an investigation has to be explicitly coded, a managed agent can understand an objective, reason through the problem, select the appropriate tools and skills, execute those tools, evaluate the results, and continue the investigation until it has enough evidence to provide an answer.

Kumar, Gyanesh

Bedrock Managed Agents (Powered by OpenAI)

Amazon Bedrock Managed Agents, powered by OpenAI, enable AI agents to reason, use tools, analyze data, and take action within an AWS-managed environment.
 
Amazon Bedrock AgentCore Runtime provides the execution environment for that agent. It gives the agent an isolated runtime with controlled IAM permissions, VPC connectivity, session context, observability, and access to enterprise tools and data. This makes it possible to bring agent-based AI into operational environments without giving an AI model unrestricted access to production systems.
 
 

Lets dive deep into how we could use Bedrock Managed Agent in a real world Use Case?

Today, investigating a database incident often requires an engineer to manually move between multiple systems—PagerDuty, CloudWatch, OpenSearch APIs, Grafana, database metrics, logs, runbooks, and change history. The engineer has to gather the evidence, correlate the signals, determine the likely root cause, and document the findings.
 
We can build a DBOps Agent changes this workflow from:
Alert → Human manually gathers evidence → Human correlates data → Human determines RCA
to:
Alert → AI Agent investigates → Tools gather evidence → Agent correlates signals → Evidence-backed RCA → Human reviews
 
The agent does not replace the DB engineer. Instead, it acts as an AI investigation assistant that performs the repetitive evidence-gathering and analysis while keeping production decisions and remediation under human control.

What is the expected outcome?

The initial outcome is an AI-powered Database Incident Investigator that can take a database or OpenSearch alert and autonomously perform a structured, read-only investigation.
For example:
"Investigate why OpenSearch search latency increased between 2:00 PM and 2:30 PM."
The agent can:
  1. Identify the affected OpenSearch domain.
  2. Establish the normal baseline.
  3. Query CloudWatch metrics.
  4. Inspect cluster health and node health.
  5. Check JVM and heap utilization.
  6. Inspect search/write thread-pool queues and rejections.
  7. Check shard allocation and cluster state.
  8. Analyze workload changes.
  9. Search the applicable DB runbooks.
  10. Correlate the evidence.
  11. Determine the most likely root cause.
  12. Assign a confidence level.
  13. Recommend next steps.
  14. Generate a standardized incident/RCA report.
 
The expected outcome is:
Less manual investigation → faster diagnosis → more consistent troubleshooting → better evidence → lower MTTR.
 
The agent is intentionally read-only. It can investigate and recommend actions, but it cannot modify production infrastructure or databases. This creates a safe path to validate the technology before considering controlled, human-approved remediation automation.

The bigger vision

The long-term goal is to create a reusable AI DBOps platform rather than a single chatbot:
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
32
33
┌─────────────────────┐
│ DB Engineer │
└──────────┬──────────┘
│
Incident / Alert
│
▼
┌──────────────────────────┐
│ DBOps AI Agent │
│ │
│ Reason • Plan • Execute │
│ Correlate • Explain │
└────────────┬─────────────┘
│
┌───────────────────┼───────────────────┐
│ │ │
▼ ▼ ▼
OpenSearch Aurora MySQL CloudWatch
│ │ │
└───────────────────┼───────────────────┘
│
▼
Runbooks / Knowledge
│
▼
Evidence-backed RCA
│
▼
Human Approval
│
┌────────┴────────┐
│ │
Stop Future: Remediate
This allows the same architecture to evolve from incident investigation into a broader AI-assisted DB operations platform covering OpenSearch, Aurora, performance analysis, capacity analysis, runbook execution, incident management, and eventually controlled remediation.
 

Detailed Use Case

When an Aurora MySQL or OpenSearch production alert fires, a DB engineer typically has to:
  1. Read the PagerDuty alert.
  2. Identify the affected cluster/domain.
  3. Check CloudWatch metrics.
  4. Check DB load / CPU / connections / memory / I/O.
  5. Check recent changes.
  6. Look at slow queries or OpenSearch thread pools.
  7. Search the runbook/Confluence.
  8. Compare against known thresholds.
  9. Form a hypothesis.
  10. Run additional diagnostic commands.
  11. Determine severity.
  12. Produce an incident summary.
  13. Recommend next actions.
A lot of this is structured investigation, but it still requires a human to jump between 5–10 systems.

The AgentCore use case

“Given a database alert, autonomously investigate the incident using approved read-only tools, correlate metrics/logs/configuration/runbooks, identify the most likely root cause, and produce an evidence-backed incident report with recommended remediation.”
For example:
PagerDuty alert
OpenSearch search thread pool queue > threshold for 10 minutes.
Engineer asks:
“Investigate OPENSEARCH-PROD-1234 and tell me what is happening.”
The agent could:
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
32
33
34
35
36
37
38
39
40
41
42
PagerDuty Alert
│
▼
AI DB Incident Investigator
│
├── CloudWatch
│ ├── CPU
│ ├── JVM
│ ├── heap
│ ├── disk
│ └── network
│
├── OpenSearch APIs
│ ├── cluster health
│ ├── thread pools
│ ├── shard allocation
│ ├── nodes
│ └── pending tasks
│
├── Logs
│ └── CloudWatch/OpenSearch logs
│
├── Runbooks
│ ├── L2 SOP
│ ├── L3 SOP
│ └── known issues
│
├── Recent changes
│ └── deployments/configuration
│
▼
Correlation / Reasoning
│
▼
Incident Report
├── What happened
├── Evidence
├── Likely root cause
├── Impact
├── Confidence
├── Recommended actions
└── Commands/actions requiring human approval
The reason this fits AgentCore particularly well is that the Runtime gives each session its own microVM and can connect to private resources through a VPC, while the Runtime execution role controls what the agent can access.

Proposed Solution

DBOps Agent — Autonomous Database Incident Investigation

Solution objective

Demonstrate that an engineer can give the agent one incident/question and receive a structured investigation without manually navigating multiple systems.
Example:
“Investigate why OpenSearch search latency increased for domain metrictestopenai between 14:00 and 14:30. Determine whether this is CPU, JVM pressure, thread-pool saturation, shard imbalance, or query load.”
The agent should return something like:
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
Incident Investigation

Severity:
SEV-2

Finding:
Search latency increase is most likely caused by search thread-pool
queue saturation on 2 data nodes.

Evidence:
• Search queue increased from ~20 → 850
• CPU increased from 42% → 78%
• JVM heap remained below 65%
• Cluster remained green
• No unassigned shards
• Search request rate increased ~2.4x
• No corresponding disk I/O anomaly

Root Cause:
Increased search workload caused thread-pool saturation.

Confidence:
High

Recommended Action:
1. Identify top search queries.
2. Validate whether traffic increase is expected.
3. Evaluate query optimization.
4. Consider capacity increase if workload is sustained.

No infrastructure changes were performed.
 

Architecture

 
The proposed architecture is:
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
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
┌───────────────────────┐
│ Engineer / SRE │
│ Slack / CLI / Portal │
└───────────┬───────────┘
│
▼
┌──────────────────────────┐
│ Bedrock Managed Agent │
│ │
│ Reasoning / Planning │
│ Session / Context │
└────────────┬─────────────┘
│
│ AgentCore Runtime
▼
┌────────────────────────────────────────────┐
│ AgentCore Runtime │
│ │
│ Dedicated session microVM │
│ │
│ ┌──────────────────────────────────────┐ │
│ │ DBOps Skills │ │
│ │ │ │
│ │ • incident-investigation │ │
│ │ • opensearch-diagnostics │ │
│ │ • aurora-diagnostics │ │
│ │ • cloudwatch-analysis │ │
│ │ • runbook-search │ │
│ │ • incident-report │ │
│ └──────────────────────────────────────┘ │
│ │
└───────────────────┬─────────────────────────┘
│
VPC / IAM controlled
│
┌────────────────────┼──────────────────────┐
│ │ │
▼ ▼ ▼
┌───────────┐ ┌──────────────┐ ┌────────────┐
│CloudWatch │ │ OpenSearch │ │ Aurora │
│Metrics │ │ APIs │ │ MySQL │
│Logs │ │ Cluster │ │ Metrics │
└───────────┘ └──────────────┘ └────────────┘
│ │ │
└────────────────────┼──────────────────────┘
│
▼
┌──────────────┐
│ Runbooks / │
│ Confluence / │
│ S3 │
└──────────────┘
AgentCore supports VPC deployment, and AWS explicitly notes that the Runtime can connect to private resources.

Why AgentCore Runtime is useful here

There are four particularly relevant pieces.

1. Private DB environment

The agent doesn't need your engineer's laptop to have access to production systems.
The Runtime can run in your VPC:
1
2
3
4
5
6
7
8
9
AgentCore Runtime
│
▼
VPC
│
├── OpenSearch
├── Aurora
├── internal APIs
└── internal observability
AWS provides VPC configuration directly through agentcore create, including VPC, subnet and security-group parameters.

2. Skills

This is the most interesting part of the use case.
We can create domain-specific skills such as:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
plugins/
dbops/
.codex-plugin/
plugin.json

skills/
incident-investigation/
SKILL.md

opensearch-diagnostics/
SKILL.md

aurora-diagnostics/
SKILL.md

performance-analysis/
SKILL.md

incident-report/
SKILL.md
Skills are packaged into the Runtime image, or they can be provided through an S3 Files mount so that skills can change without rebuilding the image.

3. Enterprise tools

For example:
1
2
3
4
5
6
7
8
9
Agent
│
├── CloudWatch
├── OpenSearch API
├── AWS CLI
├── PagerDuty
├── Grafana
├── Runbook
└── ticketing system
 

4. Observability

The agent itself becomes observable.
 
That is important for a DB engineering organization because you can answer:
What did the agent do?
 

Design Specification

DBOps Agent — AI Database Incident Investigator Design Specification

DBOps Agent — AI Database Incident Investigator

1. Purpose

Build an AI-powered database operations assistant that can autonomously investigate database and search-platform incidents using approved read-only operational tools, observability data, runbooks, and historical context.
 
The initial implementation will target Amazon OpenSearch and Aurora MySQL.
The system will analyze an alert or engineer-provided problem statement, collect relevant evidence, correlate metrics/logs/configuration, identify the most likely cause, and produce an evidence-backed investigation report.
 
The first phase will be strictly read-only. No infrastructure or database changes will be performed automatically.

2. Problem Statement

Database engineers currently investigate incidents by manually navigating multiple systems:
  • PagerDuty
  • CloudWatch
  • OpenSearch APIs
  • Aurora/MySQL
  • Grafana
  • CloudWatch Logs
  • Runbooks
  • Confluence
  • Deployment/change history
 
This creates several problems:
  • High mean time to investigate
  • Repetitive diagnostic work
  • Different engineers follow different investigation procedures
  • Important evidence can be missed
  • Incident documentation is inconsistent
  • Senior engineers spend time performing routine diagnostics
 
The DBOps Agent will automate the evidence-gathering and correlation portion of this workflow while keeping remediation decisions under human control.

3. Goals

Primary goals

  1. Automatically investigate database incidents.
  2. Gather evidence from multiple observability systems.
  3. Follow approved DB engineering runbooks.
  4. Correlate metrics, logs and configuration.
  5. Explain the reasoning behind the conclusion.
  6. Provide confidence levels.
  7. Generate a standardized incident report.
  8. Preserve investigation context within a session.
  9. Maintain complete observability of agent activity.

Secondary goals

  • Reduce L1/L2 investigation time.
  • Improve consistency of incident investigations.
  • Reduce repetitive operational work.
  • Capture institutional DB engineering knowledge in reusable skills.

4. Non-Goals

The first version will NOT:
  • Modify production infrastructure.
  • Restart databases.
  • Change OpenSearch configuration.
  • Change shard allocation.
  • Modify Aurora parameters.
  • Kill queries.
  • Scale clusters automatically.
  • Execute destructive SQL.
  • Perform production remediation without explicit human approval.
The agent is an investigator, not an autonomous production operator.

5. User Experience

Engineer:
"Investigate why OpenSearch search latency increased for domain X between 2 PM and 2:30 PM."
Agent:
  1. Identify the domain.
  2. Determine relevant nodes.
  3. Query CloudWatch metrics.
  4. Query OpenSearch cluster health.
  5. Inspect search thread pools.
  6. Inspect JVM/heap.
  7. Inspect shard allocation.
  8. Inspect pending tasks.
  9. Analyze query/request volume.
  10. Search applicable runbooks.
  11. Correlate findings.
  12. Produce investigation report.
Example response:

Finding

Search latency increased primarily because search thread-pool queues saturated on two data nodes.

Evidence

  • Search queue increased significantly.
  • Search request volume increased.
  • CPU increased concurrently.
  • JVM heap remained within baseline.
  • Cluster remained green.
  • No unassigned shards were observed.
  • Disk utilization was normal.

Root Cause

Increased search workload resulted in search thread-pool saturation.

Confidence

High

Recommended Actions

  1. Identify top search queries.
  2. Validate whether traffic increase was expected.
  3. Review query efficiency.
  4. Evaluate capacity if the workload remains elevated.
No changes were performed.

6. High-Level Architecture

Components

A. User Interface

Initial POC:
  • CLI
Future:
  • Slack
  • Internal operations portal
  • PagerDuty integration
  • ChatOps

B. Bedrock Managed Agent

Responsible for:
  • Reasoning
  • Planning
  • Tool selection
  • Session management
  • Context management

C. AgentCore Runtime

Provides:
  • Isolated execution environment
  • Session-specific microVM
  • IAM execution role
  • VPC connectivity
  • Workspace
  • Skills/plugins
  • Logging and observability

D. DBOps Skills

Initial skills:
  • Incident Investigation
  • OpenSearch Diagnostics
  • Aurora Diagnostics
  • CloudWatch Analysis
  • Runbook Search
  • Incident Report Generation

E. Tool Layer

Read-only tools:
  • CloudWatch API
  • CloudWatch Logs
  • OpenSearch REST API
  • Aurora/RDS APIs
  • AWS Resource APIs
  • Grafana API
  • PagerDuty API
  • Runbook/knowledge repository

F. Knowledge Layer

Sources:
  • DB runbooks
  • L2/L3 SOPs
  • OpenSearch troubleshooting guides
  • Aurora troubleshooting guides
  • Known issues
  • Architecture documentation
  • Historical incident reports

7. Security Architecture

Principle

Least privilege by default.
The Runtime execution role should only have the permissions required for investigation.
Example:
1
2
3
4
5
6
7
8
9
10
11
12
13
Allow:
cloudwatch:GetMetricData
cloudwatch:GetMetricStatistics
logs:FilterLogEvents
rds:Describe*
opensearch:Describe*
required OpenSearch read-only APIs

Deny:
infrastructure modification
cluster deletion
parameter modification
destructive SQL
The session role and Runtime execution role should be treated separately.
The Runtime execution role controls what the execution environment can access.
The session role controls what Bedrock Managed Agents can use to invoke the Runtime/session.
This separation should be preserved in the production design.

8. Network Design

Deploy AgentCore Runtime in VPC mode.
1
2
3
4
5
6
7
8
9
10
AWS Account
│
AgentCore Runtime
│
Private Subnets
│
┌─────────────┼─────────────┐
│ │ │
▼ ▼ ▼
OpenSearch Aurora Internal APIs
Required network connectivity:
  • AgentCore Managed Agents endpoint
  • Internal OpenSearch endpoint
  • Aurora endpoints where applicable
  • CloudWatch/AWS APIs
  • Knowledge repositories
  • MCP Gateway if used
Security groups should allow only required outbound/inbound traffic.
VPC Runtime deployments require routing to the Bedrock Managed Agents endpoint.

9. Skill Architecture

Each operational capability is implemented as a reusable skill.
Example:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
dbops/
├── .codex-plugin/
│ └── plugin.json
│
└── skills/
├── incident-investigation/
│ └── SKILL.md
│
├── opensearch-diagnostics/
│ └── SKILL.md
│
├── aurora-diagnostics/
│ └── SKILL.md
│
├── cloudwatch-analysis/
│ └── SKILL.md
│
└── incident-report/
└── SKILL.md

Incident Investigation skill

The skill should define:
  1. Determine affected resource.
  2. Determine incident time window.
  3. Establish baseline.
  4. Collect metrics.
  5. Collect logs.
  6. Inspect resource health.
  7. Compare against thresholds.
  8. Check recent changes.
  9. Search runbooks.
  10. Correlate evidence.
  11. Assign root-cause hypothesis.
  12. Assign confidence.
  13. Produce report.
 

10. OpenSearch Diagnostic Workflow

The OpenSearch skill should inspect:

Cluster

  • Cluster health
  • Cluster state
  • Node count
  • Master status

Shards

  • Unassigned shards
  • Relocating shards
  • Initializing shards
  • Shard imbalance

JVM

  • Heap utilization
  • GC
  • Old-generation pressure

Thread pools

  • Search queue
  • Search rejected
  • Write queue
  • Write rejected
  • Bulk queue

Nodes

  • CPU
  • Memory
  • Disk
  • Network
  • Node-level anomalies

Workload

  • Request volume
  • Search latency
  • Indexing rate
  • Top queries where available

Configuration

  • Relevant index settings
  • Cluster settings
  • Search configuration
  • Capacity configuration

11. Aurora Diagnostic Workflow

The Aurora skill should inspect:

Database health

  • CPU
  • Database load
  • Connections
  • Freeable memory
  • Read/write IOPS
  • Network
  • Storage

Query behavior

  • Top SQL
  • Slow queries
  • Query latency
  • Locking
  • Connection spikes

Capacity

  • Writer instance size
  • Reader instance size
  • Number of readers
  • Autoscaling configuration

Changes

  • Parameter changes
  • Engine version changes
  • Deployment activity
  • Scaling events

12. Evidence Model

Every conclusion should contain evidence.
The agent should never simply state:
"CPU caused the incident."
Instead:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Hypothesis:
CPU saturation

Evidence:
CPU:
baseline: 35%
incident: 88%

Search throughput:
baseline: 2,000 req/min
incident: 5,200 req/min

JVM:
remained below 65%

Thread pool:
queue increased significantly

Conclusion:
CPU saturation is likely a contributing factor.

Confidence:
High
This makes the agent's output auditable.

13. Confidence Model

Each root-cause hypothesis should be assigned:
  • High
  • Medium
  • Low
The agent should explain why.
Example:
1
2
3
4
5
6
7
8
9
10
High confidence:
Multiple independent signals support the hypothesis.

Medium confidence:
Evidence supports the hypothesis but another explanation
cannot be ruled out.

Low confidence:
Insufficient evidence.
Additional investigation required.

14. Human Approval Boundary

The first release must have a hard boundary:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Investigation
│
▼
┌───────────────┐
│ Recommendation│
└───────┬───────┘
│
▼
HUMAN REVIEW
│
┌─────────┴─────────┐
│ │
Reject Approve
│ │
▼ ▼
Stop Future phase
remediation
 

15. Session Management

A single investigation should maintain session context.
Example:
Turn 1:
"Investigate the OpenSearch latency alert."
Turn 2:
"Compare it with the same time yesterday."
Turn 3:
"Now check whether the top queries changed."
The same AgentCore session can maintain workspace/context between turns.
AWS documents session continuation and persistent session storage for the Runtime.

16. Knowledge Management

Runbooks should be treated as agent capabilities rather than simply documents.
Example:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
OpenSearch Runbook
│
├── Cluster health
├── JVM
├── Thread pools
├── Shards
├── CPU
└── Disk

Aurora Runbook
│
├── CPU
├── DB load
├── connections
├── memory
└── query performance
The runbooks should explicitly define:
  • Threshold
  • Meaning
  • Diagnostic command
  • Expected result
  • Escalation condition
  • Recommended action
  • L2/L3 ownership
This makes them much more useful to an agent.

17. Observability

Capture:
  • Session ID
  • Incident ID
  • Runtime ID
  • Tool invocation
  • Command execution
  • Tool latency
  • Error rate
  • Investigation duration
  • Final conclusion
  • Confidence
  • Human feedback
CloudWatch GenAI Observability should be enabled for the Runtime.
 

18. Audit Requirements

Every investigation should produce:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Investigation ID
Timestamp
Engineer
Resource
Incident
Time window

Tools used
Commands executed
Metrics queried
Runbooks consulted

Findings
Evidence
Root cause
Confidence
Recommendations

Actions performed
Actions NOT performed
The agent must explicitly state:
"No production changes were performed."
for read-only investigations.

19. Success Criteria

This is successful if the agent can investigate at least five representative incidents.
Example test cases:

Test 1

OpenSearch search thread-pool saturation.

Test 2

OpenSearch JVM pressure.

Test 3

OpenSearch unassigned shards.

Test 4

Aurora CPU / connection spike.

Test 5

Aurora query-performance regression.
For each test:
1
2
3
4
5
6
7
8
9
Human investigation time
vs.
Agent investigation time

Correct root cause?
Evidence completeness?
False conclusions?
Missing data?
Recommended action quality?

20. Target KPIs

Initial targets:
MetricTarget
Investigation time reduction≥50%
Correct root-cause classification≥80%
Evidence-backed conclusions≥95%
Hallucinated metrics0%
Unauthorized production changes0
Investigation report generated100%
Session continuation success≥95%
The most important KPI should be:
Time to actionable diagnosis
 

21. Implementation Phases

Phase 1 — Hello World

Deploy AgentCore Runtime.
Validate:
1
2
3
4
5
6
7
8
9
Engineer
↓
Bedrock Managed Agent
↓
AgentCore Runtime
↓
Command execution
↓
Response
 
1
2
3
4
5
6
7
8
npm install -g @aws/agentcore

agentcore create \
--name DBOpsAgent \
--framework BedrockManagedAgents

agentcore deploy
agentcore status

Phase 2 — Add DB Skill

Create:
1
2
3
4
5
6
plugins/dbops/
.codex-plugin/plugin.json

skills/
opensearch-diagnostics/
SKILL.md
Deploy.
Test:
"Use the OpenSearch diagnostic skill to investigate cluster health."
 

Phase 3 — Add Read-Only OpenSearch Access

Add:
1
OpenSearch REST API
and/or a controlled internal MCP server.
The agent should initially have only:
1
GET APIs
No PUT/POST/DELETE operations.

Phase 4 — Add CloudWatch

Expose controlled read-only functions:
1
2
3
get_metric_data()
get_logs()
get_alarm()
Avoid giving the agent unrestricted AWS CLI access if equivalent narrowly scoped functions can be provided.

Phase 5 — Add Runbooks

Load:
1
2
3
4
5
OpenSearch Runbook
Aurora Runbook
L2 SOP
L3 SOP
Known Issues
Then test whether the agent follows the prescribed diagnostic sequence.

Phase 6 — Incident Correlation

Add:
1
2
3
4
5
6
7
PagerDuty
+
CloudWatch
+
OpenSearch
+
Runbook
The agent receives:
1
2
3
4
5
Incident ID
Resource
Alert
Start time
Severity
and performs the investigation automatically.

Phase 7 — Observability

Enable:
  • CloudWatch logs
  • GenAI observability
  • Agent invocation tracing
  • Tool-call auditing
 

Phase 8 — Production Hardening

Add:
  • IAM least privilege
  • VPC controls
  • Secrets management
  • Network restrictions
  • Audit logging
  • Prompt-injection defenses
  • Tool allowlists
  • Resource allowlists
  • PII/sensitive-data controls
  • Session expiration
  • Cost controls
  • Human approval gates
 

22. Initial Repository Structure

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
32
33
34
35
36
37
38
dbops-agent/
│
├── agentcore/
│ ├── agentcore.json
│ └── cdk/
│
├── app/
│ └── DBOpsAgent/
│ ├── Dockerfile
│ ├── client.py
│ ├── pyproject.toml
│ │
│ ├── lifecycle/
│ │ └── server.py
│ │
│ ├── otel/
│ │ └── collector.yaml
│ │
│ ├── policies/
│ │ ├── runtime-policy.json
│ │ └── session-policy.json
│ │
│ └── plugins/
│ └── dbops/
│ ├── .codex-plugin/
│ │ └── plugin.json
│ │
│ └── skills/
│ ├── incident-investigation/
│ │ └── SKILL.md
│ ├── opensearch-diagnostics/
│ │ └── SKILL.md
│ ├── aurora-diagnostics/
│ │ └── SKILL.md
│ └── incident-report/
│ └── SKILL.md
│
└── README.md

23. Recommended Demo

The strongest demo would be a deliberately created OpenSearch incident.

Step 1

Generate elevated search workload.

Step 2

Trigger an alert:
1
Search thread-pool queue > threshold

Step 3

Give the agent:
"Investigate this alert and determine the most likely root cause. Do not make any changes."

Step 4

Agent investigates:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
CloudWatch
↓
CPU
↓
JVM
↓
OpenSearch cluster
↓
Thread pools
↓
Shard state
↓
Query workload
↓
Runbook

Step 5

Agent generates RCA.

Step 6

Engineer asks:
"Compare this incident against yesterday's workload."

Step 7

Agent continues the same session and performs the comparison.
This would demonstrate reasoning + tools + private infrastructure + persistent session + domain skills + observability, which is a much stronger showcase of AgentCore than a generic chatbot.

24. Future Evolution

Once read-only investigation is proven, the architecture can evolve:
1
2
3
4
5
6
7
8
9
10
11
12
DBOps Agent
│
┌───────────┴───────────┐
│ │
Investigation Remediation
│ │
Read-only tools Approval required
│
Human approval
│
▼
Controlled action
Examples:
  • Increase OpenSearch capacity
  • Modify shard allocation
  • Scale Aurora reader count
  • Modify autoscaling
  • Create incident ticket
  • Update PagerDuty
  • Execute approved remediation runbook
But those should be Phase 2/3, not part of the initial POC.
 
Implemented the first working repository  for the DBOps AI Incident Investigator.

What is included

  • BedrockManagedAgents / AgentCore Runtime project bootstrap
  • OpenSearch read-only diagnostic layer
    • cluster health
    • nodes
    • JVM
    • thread pools
    • shards
    • indices
  • CloudWatch read-only diagnostics
  • Evidence-backed incident/RCA formatter
  • Four AgentCore/Codex skills:
    • incident-investigation
    • opensearch-diagnostics
    • cloudwatch-analysis
    • incident-report
  • IAM policies for the read-only POC
  • Session-aware AgentCore client
  • VPC bootstrap support
  • Deployment and smoke-test scripts
  • Unit tests
  • Design documentation
 
The bootstrap script therefore invokes the current AWS CLI and brings those generated pieces into the repository.

Validation

All tests pass:
1
2
3
Ran 4 tests in 0.000s

OK
The repository also passes Python compilation.

Download

Download the complete DBOps Agent repository 

To actually deploy it

After extracting:
1
2
3
4
5
6
7
cd dbops-agent

npm install -g @aws/agentcore

export AWS_REGION=us-east-1

./scripts/bootstrap_from_aws.sh
For a VPC deployment:
1
2
3
4
5
export VPC_ID=vpc-xxxx
export SUBNET_IDS=subnet-aaa,subnet-bbb
export SECURITY_GROUP_IDS=sg-xxxx

./scripts/bootstrap_from_aws.sh
Then configure the OpenSearch endpoint:
1
export OPENSEARCH_ENDPOINT=https://your-domain.us-east-1.es.amazonaws.com
Review/tighten the generated IAM policy, then:
1
./scripts/deploy.sh
AWS's current flow uses agentcore deploy, then agentcore status to obtain the Runtime ARN.
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