For most of the last decade, “managed operations” on AWS meant a familiar bundle: monitoring dashboards, alarms routed to an on-call rota, runbooks in a wiki, and engineers who knew where the bodies were buried. That bundle is now being unbundled. On March 31, 2026, AWS announced general availability of AWS DevOps Agent, an autonomous agent that investigates incidents, correlates telemetry with code and deployment history, and recommends changes to prevent the next outage. Microsoft and Google have shipped comparable agents for their own clouds. The question for every team running production on AWS is no longer whether AI will take part in operations, but how to put it to work without losing control, accountability or cost discipline.
This article explains what AWS DevOps Agent actually does, how it fits next to existing observability and incident tooling, where it changes the economics of operations, and a practical path to adopt it, whether you run operations in-house or with a managed service partner.
What AWS Launched and Why It Matters
AWS DevOps Agent was first previewed at re:Invent 2025 alongside AWS Security Agent, as part of what AWS calls “frontier agents”: agents designed to work for long stretches with a high degree of autonomy rather than answer one-off chat prompts. At general availability, AWS describes the DevOps Agent as an always-available operations teammate that investigates and helps resolve incidents, works to prevent them, and handles on-demand site reliability engineering (SRE) tasks across AWS, other clouds and on-premises environments.
Three things make this launch more significant than earlier “AI assistant in the console” features:
- It reasons over the whole delivery chain, not just metrics. The agent learns your applications and their relationships, then correlates telemetry with code repositories, CI/CD pipelines and runbooks. Most incidents start with a change, and an agent that can see the change is far more useful than one that only sees the symptom.
- It is designed to start on its own. Investigations can be triggered automatically from alerting tools, so the first round of triage can be done before a human has acknowledged the page.
- It reaches beyond AWS. The GA release added investigation of applications running in Azure and on-premises, plus Azure DevOps pipeline integration. For hybrid estates, that matters more than any single feature.
AWS’s own launch materials cite preview results such as a reduction in mean time to resolution (MTTR) of up to 75 percent and investigations that are substantially faster. Those are vendor-reported figures from early adopters, and independent coverage has rightly noted they are unverified. They are still a useful signal of intent: AWS is positioning the agent to take on the most time-consuming part of incident response, which is figuring out what actually went wrong.
How the Agent Works in Practice
Understanding the building blocks helps you design an operating model around the agent instead of bolting it onto an old one.
Agent Spaces and application topology
You start by creating an Agent Space in the AWS Management Console and connecting the tools that hold your telemetry. The agent then builds a picture of your applications and their dependencies. For on-premises workloads, AWS says it discovers resources by analyzing metrics, logs and code to infer a topology. This topology is the foundation for everything else: an agent that knows the checkout service calls the payments API, which depends on a specific database cluster, can test sensible hypotheses instead of grepping logs at random.
Integrations with the tools you already run
The GA announcement lists integrations with CloudWatch, Datadog, Dynatrace, New Relic and Splunk for observability; Grafana through a built-in Model Context Protocol (MCP) server covering Prometheus, Loki and OpenSearch; PagerDuty for automatic incident response from alerts; ServiceNow; GitHub Actions, GitLab CI/CD and Azure Pipelines for deployment history; Slack; and Amazon EventBridge for investigation events. Private connections let the agent reach self-hosted Grafana, Splunk, source control or MCP servers inside a VPC without exposing them to the internet. The practical implication: you do not need to migrate to a new observability stack to benefit, but the quality of the agent’s output will track the quality and coverage of the signals you connect.
Skills, triage and prevention
Two features deserve particular attention from operations leaders:
- Skills. The agent builds learned skills from your team’s investigation patterns, and you can add custom skills that encode investigation procedures and organizational knowledge. Custom skills can target specific agent roles, such as incident triage, root-cause analysis, mitigation and evaluation. In effect, your best engineer’s debugging approach becomes reusable.
- Triage and prevention. A triage agent assesses severity and links duplicate tickets to a primary investigation, which reduces alert-storm noise. Separately, the agent analyzes historical incidents and produces prevention recommendations grouped by category on a dashboard. This is the bridge from reactive firefighting to reliability engineering.
The agent also indexes code repositories so it can point to probable bugs during an investigation and suggest code-level fixes in mitigation plans. On the security side, AWS lists support for customer managed keys and direct identity provider integration with Okta and Microsoft Entra ID for access to the operator portal.
What Changes for AWS Operations Teams
It is tempting to frame AI agents as headcount replacement. That framing is both inaccurate and unhelpful. What changes is the shape of the work.
From triage labor to judgment
In a typical incident, a large share of elapsed time goes to gathering context: which deploy went out, which alarms fired first, what the logs say around the time of the spike, whether a similar incident happened before. An agent that assembles that context in minutes moves the human role toward judgment: validating the hypothesis, deciding on mitigation, communicating with stakeholders, and accepting the business risk of a rollback or failover.
Runbooks become executable knowledge
Static runbooks decay because nobody reads them until 3 a.m. When runbooks are connected to an agent and encoded as skills, they are exercised on every relevant investigation, which surfaces gaps quickly. Teams that invest in clear, structured runbooks will get disproportionately better results.
Observability quality becomes a first-class deliverable
An agent cannot correlate what it cannot see. Missing deployment markers, inconsistent service naming, untagged resources and sparse tracing all degrade investigations. In an AI-assisted model, instrumentation hygiene is no longer a nice-to-have backlog item; it directly determines how much value you get from the agent.
Cost moves from people-hours to agent-seconds
AWS bills the DevOps Agent per second of agent time with no upfront commitment, and AWS Support customers receive monthly credits based on their prior month’s support charge: 100 percent for Unified Operations, 75 percent for Enterprise Support and 30 percent for Business Support+, according to the GA announcement. That makes support tier selection part of the operations cost model. It also means you should watch for runaway automatic investigations triggered by noisy alarms, which is one more reason to fix alert quality first.
AI agents do not remove the need for operational discipline; they reward it. Teams with clean telemetry, clear ownership and structured runbooks will see the biggest gains from AWS DevOps Agent.
Where Humans Remain Essential
Even with strong root-cause accuracy, there are areas where human ownership remains essential:
- Mitigation decisions with business impact. Failing over a region, rolling back a release that includes a regulatory change, or throttling a customer segment are business decisions. The agent can recommend; an accountable person should decide.
- Novel failure modes. Agents learn from patterns. A genuinely new class of failure, such as an unusual interaction between a third-party API change and a caching layer, may still need an experienced engineer’s intuition.
- Communication and coordination. Status pages, customer updates and executive briefings require context and tone that should be owned by people.
- Governance of the agent itself. Someone must decide which data sources it can read, which actions it can recommend, how its findings are reviewed, and how its cost is controlled.
A useful mental model is the aviation autopilot. It flies most of the route and reduces fatigue, but pilots stay trained, briefed and responsible, and they practice taking over.
A Five-Phase Adoption Playbook
The following playbook reflects how we approach AI-assisted operations on AWS. It is deliberately incremental, because trust in an agent is earned through evidence.
- Phase 1: Readiness assessment (2–3 weeks). Inventory your observability coverage, alert quality, deployment tracking and runbook maturity for the top 10–20 business-critical services. Identify gaps such as missing deployment events, inconsistent tags or services without traces. Define the metrics you will use to judge success: MTTR, time to first useful hypothesis, duplicate-ticket rate and on-call load.
- Phase 2: Shadow mode on a pilot scope (4–6 weeks). Create an Agent Space for a contained set of services and connect observability, source control and CI/CD. Let the agent investigate incidents in parallel with your normal process, without acting on its output. After each incident, compare its findings with the human post-incident review. Record where it was right, partially right or wrong.
- Phase 3: Assisted triage. Once shadow results are consistently useful, make the agent’s investigation the starting point for on-call engineers. Trigger investigations automatically from PagerDuty or high-severity alarms. Keep all mitigation decisions human. Start writing custom skills for recurring incident types.
- Phase 4: Prevention loop. Feed prevention recommendations into the engineering backlog with a clear owner and a review cadence. Track how many recommendations are accepted, implemented and correlated with fewer repeat incidents. This is where reliability compounds.
- Phase 5: Scale and govern. Expand to more services and environments, including Azure or on-premises if relevant. Formalize who can change agent configuration, how skills are reviewed, how agent spend is budgeted against support credits, and how investigation records are retained for audit.
A Worked Example: A Latency Spike After a Friday Deploy
Consider a mid-sized e-commerce platform running on Amazon EKS with an Aurora PostgreSQL database, Datadog for application monitoring, GitHub Actions for deployments and PagerDuty for paging. On a Friday afternoon, p99 latency on the checkout API jumps from 300 milliseconds to over three seconds.
In the traditional model, the on-call engineer acknowledges the page, opens three dashboards, checks the deployment channel, notices a release went out 40 minutes earlier, starts reading the diff, and eventually pulls in a database specialist. Context-gathering alone can consume most of the first hour.
In an AI-assisted model, the PagerDuty alert triggers an investigation automatically. Within minutes, the agent reports that latency began rising shortly after a specific deployment, that database CPU and connection counts climbed at the same time, and that the release changed a repository query in the order-history service to drop a filter on an indexed column. It proposes a probable root cause, a full table scan on a large table under peak load, and recommends either rolling back the release or adding the index. The on-call engineer validates the query plan, chooses the rollback because it is lower risk on a Friday, and posts an update. The post-incident review then accepts the agent’s prevention recommendation to add query-plan checks to the pipeline for repository changes.
Note what did not change: a person decided on the mitigation, owned the customer communication and approved the pipeline change. What changed is that the person spent their time on decisions rather than on searching.
Implications for Managed Services Models
For organizations that use a managed service provider (MSP) for AWS, AI-assisted operations reshapes what you should expect and pay for.
- Outcome-based commitments become realistic. When triage is faster and more consistent, it is reasonable to ask for commitments tied to MTTR, repeat-incident reduction and SLO attainment rather than only ticket response times.
- The value shifts to engineering, not eyes-on-glass. An MSP whose main offer is 24/7 monitoring by humans watching dashboards is offering what agents increasingly do. The differentiators become instrumentation design, skill and runbook engineering, prevention backlog delivery and governance.
- Transparency matters more. Ask how the provider uses agents, which data the agents can access, who approves actions, and how investigation records are shared with you. Agent output should be visible to your team, not a black box behind a ticket.
- Commercial alignment. Agent costs, support-plan credits and provider fees interact. Make sure the provider’s model does not quietly shift agent consumption costs to you without the matching reduction in labor charges.
In-house teams face the same shift. The skills to invest in are observability engineering, SRE practices such as SLOs and error budgets, and the ability to write and maintain agent skills as carefully as code.
Checklist Before You Turn It On
- Critical services have consistent names and tags across AWS, observability tools and source control.
- Deployment events from every pipeline are captured and correlated with service names.
- Alerting is tuned so that high-severity alarms are actionable, not noisy.
- Runbooks for the top recurring incident types are current and structured.
- Access for the agent follows least privilege, with private connections for internal tools.
- Success metrics and a baseline are recorded before the pilot starts.
- Agent spend has a budget, an owner and a view of support-plan credits.
- Post-incident reviews include a section comparing agent findings with human findings.
Outlook: Toward Self-Improving Operations
The direction is clear across all three major clouds: operations agents that start investigations on their own, learn from each incident and feed prevention work back into engineering. Over the next 12–24 months, expect deeper autonomy for well-understood, reversible actions such as scaling or restarting, tighter links between security and operations agents, and more cross-cloud investigation as vendors compete for hybrid estates. Expect regulators and auditors to ask how automated operational decisions are logged and reviewed, especially in financial services and other regulated sectors.
The organizations that benefit most will treat the agent as a new member of the team with a defined role, clear permissions, measurable performance and a manager. Those that simply switch it on and hope for the best will get faster noise.
Conclusion
AWS DevOps Agent marks a real shift in how AWS workloads are operated. It compresses the most labor-intensive part of incident response, makes runbooks executable and turns post-incident learning into a continuous prevention loop. Its value depends on the foundations you give it: clean telemetry, structured knowledge, sensible guardrails and people who own outcomes. Start with a readiness assessment, prove value in shadow mode, and scale only when the evidence supports it. Whether you run operations in-house or with a partner, the goal is the same: fewer incidents, faster recovery and engineers who spend their time on work that matters.
How Hanoi Technology Can Help
Hanoi Technology helps teams prepare telemetry, runbooks and guardrails for AI-assisted AWS operations and can run them as a managed service or dedicated team.