Skip to main content

Episode #080: AWS DevOps Agent - Promises vs Reality

Edit on GitHubStar

Duration: 26 minutes | Speakers: Jordan & Alex | Target Audience: Platform engineers, SREs, DevOps leads evaluating AI ops tooling

đź“° News Segment: This episode covers KubeCon Europe 2026 schedule and Platform Engineering 2026 predictions before the main topic.

News Segment​

KubeCon + CloudNativeCon Europe 2026 - CNCF unveiled the full schedule for KubeCon Europe 2026, running March 23-26 in Amsterdam with 224 sessions across five main tracks: AI, Observability, Platform Engineering, Security, and Emerging + Advanced. The Platform Engineering track addresses the 56% of organizations reporting platform engineer understaffing. Standard registration closes February 4, 2026.

Platform Engineering 2026 Predictions - The Platform Engineering community released their 10 predictions for 2026. The headline prediction: "Agentic infrastructure becomes standard." AI agents will transition from experimental tools to core platform components with RBAC permissions, resource quotas, and governance policies built in—directly relevant to today's AWS DevOps Agent analysis.

Episode Summary​

Every SRE's fantasy: an AI that handles the 2 AM page so you don't have to. At re:Invent 2025, AWS announced the DevOps Agent—a "frontier agent" positioned as an autonomous on-call engineer. But before you cancel your PagerDuty subscription, we separate the marketing from the mechanics. This episode explores what AWS DevOps Agent actually delivers today, its technical architecture, real demo results, honest limitations, and a practical evaluation framework for your team.

Key Takeaways​

  • Agent Spaces architecture: Logical containers defining scope, permissions, and integrations. Each space has its own AWS account configurations, third-party tool integrations, and user permissions—providing isolation for multi-tenant security
  • Automatic topology building: The agent maps your resources and their relationships without upfront configuration, understanding blast radius and dependency chains during investigations
  • Broad integration support: CloudWatch, Datadog, Dynatrace, New Relic, Splunk for observability; GitHub Actions, GitLab CI/CD for deployments; ServiceNow built-in, PagerDuty via webhooks
  • Cannot execute fixes: Generates detailed mitigation plans with specific steps and rollback procedures, but humans must approve and execute every action—"humans remain the gatekeepers"
  • Demo results: 42 resources discovered automatically, imagePullBackError correctly diagnosed in EKS, >40 minute gaps between alarms cause correlation struggles
  • MTTR improvements: 45 min → 18 min (60% reduction) when properly configured, with 40% auto-diagnosed and 20% auto-remediated (with human approval)
  • Preview limits: 10 Agent Spaces, 20 incident response hours/month, 10 prevention hours/month, 1000 chat messages, US-East-1 only, English-only, no SOC 2/ISO 27001 yet

Five-Question Evaluation Framework​

  1. Are you primarily AWS? If less than 70% of infrastructure is AWS, value proposition weakens significantly
  2. What's your current MTTR? Need a baseline before evaluating improvement potential
  3. Can you invest in training the agent? Budget 2-4 weeks of active engagement from senior SREs
  4. Is 20 incident hours/month enough to evaluate? Calculate your current incident volume
  5. What's your tolerance for preview-stage tooling? No SLAs, no compliance certifications yet

Ideal vs Wait-and-See Scenarios​

ScenarioRecommendation
Mid-size fintech, 100% AWS, EKS/Aurora/CloudWatch, 3-4 incidents/night, 90-min MTTRPilot now - ideal candidate
Enterprise multi-cloud (AWS/Azure/GCP), hybrid on-prem, multiple observability vendors, SOC 2 requirementsWait for GA - compliance and multi-cloud limitations

Resources​

Transcript​

Alex: This is the Platform Engineering Playbook Daily Podcast—today's news and a deep dive to help you stay ahead in platform engineering.

Jordan: Before we dive into today's main topic, we have two quick news items. First, CNCF unveiled the full schedule for KubeCon plus CloudNativeCon Europe 2026. The event runs March 23rd through 26th in Amsterdam with 224 sessions across five main tracks. The tracks are AI, Observability, Platform Engineering, Security, and Emerging plus Advanced. The Platform Engineering track addresses the 56% of organizations reporting platform engineer understaffing. Standard registration closes February 4th.

Alex: That Platform Engineering track is significant. And tied to that—the Platform Engineering dot org community just released their ten predictions for 2026. The headline prediction? "Agentic infrastructure becomes standard." They predict AI agents will transition from experimental tools to core platform components with RBAC permissions, resource quotas, and governance policies built in. Which brings us directly to today's main topic.

Jordan: Exactly right. And that prediction perfectly frames what AWS is attempting with their DevOps Agent.

Alex: Every SRE's fantasy: an AI that handles the two AM page so you don't have to. At re:Invent twenty twenty-five, AWS announced exactly that—a quote "frontier agent" that acts as an autonomous on-call engineer. But before you cancel your PagerDuty subscription, we need to separate the marketing from the mechanics. Today we're doing a deep technical dive into what AWS DevOps Agent actually promises, what it delivers today, how it works under the hood, and critically—what it costs.

Jordan: And that's exactly what we're doing today. AWS DevOps Agent launched December second, twenty twenty-five in public preview. It's one of three "frontier agents" AWS announced alongside Kiro—their autonomous coding agent—and the AWS Security Agent. The term "frontier agent" is AWS's branding for what they describe as AI agents that are quote "autonomous, massively scalable, and work for hours or days without constant intervention."

Alex: That's an important framing. They're not calling this a chatbot or an assistant. They're positioning it as something that can work autonomously over extended periods—which is a different value proposition than a copilot you interact with in real-time.

Jordan: The pitch is compelling: an always-on AI that investigates incidents, identifies root causes, and generates mitigation plans. When an alert fires—whether that's two AM or during peak hours—the agent immediately starts investigating. It correlates data across your observability tools, deployment history, and infrastructure topology to identify probable root causes. Then it generates detailed mitigation plans and manages incident coordination through Slack and ServiceNow.

Alex: The key word there is "generates." Not "executes." And that distinction is going to matter a lot as we dig in. But first, let's unpack the architecture because understanding how this works technically helps explain both the capabilities and the limitations.

Jordan: Let's start with what AWS calls Agent Spaces. This is the core abstraction. An Agent Space is a logical container that defines what the DevOps Agent can access when performing tasks. Think of it as a scoped environment with its own permissions, integrations, and boundaries.

Alex: So it's like a project or a namespace for the agent's work?

Jordan: Exactly. Each Agent Space has its own AWS account configurations, third-party tool integrations, and user permissions. The isolation is important—if you set up one Agent Space per application, they can't see each other's data. Some teams align an Agent Space with a single application. Others create one per on-call team managing multiple services. Some organizations use a centralized approach with one Agent Space for everything.

Alex: How does the agent learn about your infrastructure? Because you can't diagnose problems if you don't understand the system.

Jordan: This is where it gets interesting. The agent automatically builds what AWS calls an application topology—a map of your resources and their relationships. It does this without you having to define anything upfront. When an incident hits, it uses that topology to understand blast radius and dependency chains.

Alex: So if my database has a problem, it understands which services depend on that database and can correlate the cascade of failures?

Jordan: That's the idea. And it's not just AWS resources. The topology includes third-party integrations—your Datadog metrics, your GitHub deployments, your ServiceNow tickets. It builds a unified view.

Alex: Let's talk about those integrations. Because this isn't a CloudWatch-only tool.

Jordan: The integration story is surprisingly broad for a version one product. For observability, they support Amazon CloudWatch obviously, but also Datadog, Dynatrace, New Relic, and Splunk. That covers most enterprise observability stacks. For CI/CD and code, they integrate with GitHub Actions, GitLab CI/CD, and both GitHub and GitLab repositories. For incident management, ServiceNow is built-in, and PagerDuty works through configurable webhooks.

Alex: And there's the MCP angle—Model Context Protocol.

Jordan: Right. This is the wildcard that makes it extensible. MCP is the same protocol Anthropic is pushing for Claude, and it's becoming a real standard for agent tool integration. Through what AWS calls "bring your own MCP server," you can connect custom tools. If you've built internal runbooks, custom CLIs, specialized platforms, or even open-source observability tools like Grafana and Prometheus—you can expose them to the DevOps Agent through MCP servers.

Alex: That's significant because every organization has custom tooling. The ability to teach the agent about your specific systems could be the difference between useful investigation and hitting dead ends.

Jordan: Now let's talk about what happens when an incident actually fires. There are two main modes: incident response and incident prevention.

Alex: Walk me through incident response first.

Jordan: When an alert comes in—whether from a CloudWatch alarm, a ServiceNow ticket, or a PagerDuty webhook—the agent automatically starts investigating. It begins by correlating data across all connected sources. It looks at metrics, logs, and traces from your observability tools. It examines recent deployments from GitHub or GitLab—what changed in the last hour, what configurations were modified. It checks the application topology to understand which resources are affected and how they relate.

Alex: And the investigation is conversational?

Jordan: There are two paths. The agent can investigate autonomously—you get notified when it has findings—or you can interact with it through natural language chat in the DevOps Agent web app. You can ask questions like "what happened to the checkout service in the last hour" or "show me deployments that touched the payments module."

Alex: What's the output of an investigation?

Jordan: A detailed mitigation plan. This includes specific actions to resolve the incident—step by step. It includes validation steps to confirm the fix worked. And critically, it includes rollback procedures if the fix makes things worse. The plans are surprisingly detailed based on the demos I've seen.

Alex: You mentioned incident prevention. What does that mean?

Jordan: Beyond reactive investigation, the agent proactively analyzes patterns across historical incidents. It looks for recurring issues, systemic weaknesses, and optimization opportunities. Then it delivers targeted recommendations across four areas: observability—like adding missing metrics or improving alert thresholds; infrastructure optimization—autoscaling adjustments, capacity tuning; deployment pipeline enhancement—testing gaps, validation improvements; and general architectural recommendations.

Alex: So it's trying to prevent future incidents, not just diagnose current ones.

Jordan: Exactly. And it learns from team feedback. If you dismiss a recommendation as not applicable, it factors that in. If you implement a recommendation, it tracks the impact on incident frequency.

Alex: Now let's get to the hands-on reality. Someone ran a demo that walked through two real scenarios. What did we learn?

Jordan: First scenario: CloudWatch alarm investigation. They deployed an EC2 instance with intentional CPU stress testing via CloudFormation. This simulates the classic "CPU spike alert fires" scenario. When the alarm triggered, the agent automatically started investigating. It discovered forty-two resources in the topology—automatically mapping the EC2 instance, its associated security groups, the VPC, connected services. It identified the CPU spike as the root cause. And it generated a mitigation plan with specific steps.

Alex: Forty-two resources discovered automatically. That's the value of the topology awareness—it's not just looking at the one instance that's alerting, it's mapping the entire environment.

Jordan: Right. The demo also noted what the agent couldn't do. When CloudWatch Logs weren't enabled for the instance, the agent flagged that as a gap. It said essentially "I can see there's a CPU problem, but I can't tell you why because logging isn't configured." That's honest about its limitations.

Alex: What about the EKS scenario?

Jordan: Second demo—they introduced a pod failure in EKS. Classic container scenario. The agent identified imagePullBackError as the root cause. The container couldn't pull its image because the registry reference was wrong. The agent recommended correcting the image registry path, provided specific kubectl commands to apply the fix, and included rollback procedures if the new image also failed.

Alex: So it understood the Kubernetes-specific error pattern and generated Kubernetes-specific remediation.

Jordan: Yes. And importantly, the demo required tagging Terraform-deployed resources for discovery. The agent uses AWS resource tags to understand what belongs to which application. If your resources aren't tagged consistently, the topology mapping will have gaps.

Alex: Here's the critical limitation that surprised me from the demo: event correlation has a time window.

Jordan: This is a real constraint. When there was more than forty minutes between related alarms, the agent struggled to correlate the events. It's optimizing for rapid incident response—the "something broke, let's figure out what" scenario. It's not designed for those sneaky slow-burn problems that manifest over hours or days with intermittent symptoms.

Alex: That makes sense architecturally. Real-time correlation is a different problem than historical pattern analysis.

Jordan: And here's the elephant in the room: it cannot execute fixes. The agent generates mitigation plans—detailed, specific, actionable plans—but a human has to approve and execute every action. AWS explicitly states quote "humans remain the gatekeepers."

Alex: So this is a diagnosis and recommendation engine, not an automation engine. At least not yet.

Jordan: Exactly. And I think that's the right call for version one. The consequences of autonomous remediation gone wrong are significant. Imagine the agent decides to roll back a deployment that's actually fine, or scales down instances that are legitimately under load. The blast radius of automated bad decisions is why AWS requires human approval.

Alex: But it does mean you're not replacing your on-call rotation—you're augmenting it. Someone still has to wake up and approve the fix.

Jordan: True. Though the value proposition is that they wake up to a diagnosis and a fix plan, rather than waking up to a wall of alerts and spending thirty minutes figuring out what happened.

Alex: Let's talk about the results people are seeing when properly configured. What's the improvement potential?

Jordan: AWS's best practices documentation cites specific numbers from early adopters. Before introducing the agent: MTTR was forty-five minutes on average, and a single service-impacting incident generated one hundred twenty alerts. After configuring the DevOps Agent: MTTR dropped to eighteen minutes—a sixty percent reduction. Alert noise reduced to thirty-five alerts per incident. Forty percent of incidents were auto-diagnosed with accurate root cause. Twenty percent were auto-remediated—meaning the fix was applied after human approval.

Alex: Forty-five to eighteen minutes is significant. That's twenty-seven minutes saved per incident.

Jordan: But those numbers come with a caveat. They require quote "significant initial human oversight and training." The agent needs to learn your specific environment. You need to correct false positives, provide context on your architecture, explain why certain recommendations don't apply. It's not deploy-and-done.

Alex: Let's talk about where this shines and where it falls flat. Because I think the use cases are more nuanced than the marketing suggests.

Jordan: The sweet spot is AWS-native environments with high incident volume. If you're running complex applications on EKS, EC2, Lambda, with CloudWatch as your primary observability layer and GitHub for CI/CD—this is built for you. The agent has direct access to the AWS control plane, which means richer context than any third-party tool can achieve.

Alex: And that's the structural advantage AWS has. PagerDuty and Rootly are orchestrating across systems through APIs. They can see the data you send them. AWS can operate directly within the services where incidents originate—seeing internal metadata, resource relationships, and context that isn't exposed through APIs.

Jordan: But here's the flip side: if you're running multi-cloud or hybrid—GCP plus Azure plus AWS—the value drops significantly. The third-party integrations are there, but you're back to API-level access rather than control plane integration. The agent can see your Datadog metrics, but it can't see the internal state of your GCP resources.

Alex: One article put it well: quote "This is only useful for organizations that operate entirely within an AWS ecosystem. Companies that have a more hybrid or multi-cloud setup are unlikely to see that benefit."

Jordan: Which describes a lot of enterprises. Multi-cloud isn't just a strategy for many companies—it's reality born from acquisitions, regulatory requirements, and vendor diversification.

Alex: What about the cost picture? Because free during preview is great, but AWS has a history of pricing surprises at GA.

Jordan: This is the "$600K question" that a Medium article raised—one DevOps lead managing fifty-two thousand dollars per month in AWS infrastructure started asking what this actually costs at scale. The title was literally "AWS DevOps Agent: The $600K Question Nobody's Asking at re:Invent."

Alex: Walk me through the preview limits.

Jordan: During preview, you get ten Agent Spaces maximum. Twenty incident response hours per month. Ten incident prevention hours per month. One thousand chat messages. And three concurrent incident investigations running at once.

Alex: Twenty incident hours per month—what does an "hour" mean here?

Jordan: It's time the agent spends actively investigating. A simple incident might take ten minutes of investigation time. A complex one might take an hour. If you're running a high-incident environment with five to ten incidents per day, you could burn through that quota in a week.

Alex: And critically—while DevOps Agent itself is free during preview, the underlying service calls are still billed.

Jordan: Right. If the agent is querying CloudWatch metrics and logs during an investigation, those API calls hit your bill. If it's pulling data from Datadog's API, you might hit rate limits or metered usage on that side. The agent itself is free, but the infrastructure it queries is not.

Alex: AWS hasn't announced the GA pricing model yet?

Jordan: They've confirmed it will be usage-based, but no details on whether that's per-investigation, per-hour, per-Agent-Space, or some other metric. If you're evaluating this seriously, you need to factor in that unknown. A tool that saves you fifty thousand dollars in reduced MTTR isn't valuable if it costs you sixty thousand dollars in usage fees.

Alex: What about compliance? For enterprises in regulated industries, that matters as much as features.

Jordan: Still preview-stage. No SOC 2 or ISO 27001 compliance documentation yet. AWS says more regions and compliance certifications are coming before GA, but right now it's US-East-1 only and no formal attestations.

Alex: That's a hard stop for a lot of enterprises. You can't send production telemetry to an unattested service.

Jordan: Exactly. Financial services, healthcare, government—they're locked out until compliance arrives.

Alex: Let's step back and look at the competitive landscape. Because AWS isn't the only player trying to solve incident response with AI.

Jordan: PagerDuty remains the alerting king—nearly seventy percent of the Fortune 100 uses them. They've built out Event Intelligence with ML-powered noise reduction and pattern detection. Their strength is the ecosystem—over seven hundred integrations—and the maturity of their on-call management workflows. They're the default choice for most enterprises.

Alex: How are they responding to the AWS announcement?

Jordan: They haven't announced specific product responses yet, but the trajectory is clear. They've been adding AI capabilities incrementally—better correlation, smarter alert grouping, predictive insights. Expect them to accelerate.

Alex: Rootly is the interesting challenger.

Jordan: Rootly focuses on the full incident lifecycle rather than just alerting—detection through post-mortem. Transparent pricing, which is a big differentiator. Slack-native experience that feels more modern than PagerDuty's. They've been aggressive about undercutting PagerDuty on cost and emphasizing automation.

Alex: Then you have the newer entrants.

Jordan: Ciroos launched in late twenty twenty-four with an explicitly agentic AI focus for incident management. BigPanda has been doing AIOps-style event correlation and topology awareness for years. Shoreline is doing runbook automation that's closer to the "actually execute fixes" side of the spectrum.

Alex: The key difference with AWS is that control plane access you keep mentioning.

Jordan: PagerDuty can tell you that your CloudWatch alarm fired. AWS DevOps Agent can correlate that alarm with the deployment that happened thirty minutes earlier in GitHub, the configuration change in that deployment, the specific resource relationships in your infrastructure, and the internal state of AWS services that isn't exposed through external APIs. That context density is the real differentiator.

Alex: Let's talk about the skill degradation argument, because this comes up every time AI tooling enters ops.

Jordan: There's a legitimate concern that if AI handles diagnosis, engineers stop learning how to diagnose. The deep system knowledge that makes senior SREs valuable comes from years of hands-on incident response. Fighting fires at three AM teaches you how systems fail in ways that documentation doesn't. If that gets outsourced to an agent, do we end up with teams that can't function when the agent fails or hits an edge case it doesn't understand?

Alex: Counter-argument: the burnout numbers are real. Eighty-three percent of software engineers report burnout. Fifty-seven percent of SREs still spend more than half their week on toil despite AI tool adoption. Alert fatigue is the number one obstacle to faster incident response. If we can automate the repetitive diagnostic work, teams can focus on architecture, reliability engineering, and the creative problem-solving that AI can't do.

Jordan: The middle ground—which is what AWS recommends—is human-in-the-loop during the ramp-up period. You actively steer the agent, correct its mistakes, explain context. The agent learns from that feedback. Over time, you can reduce supervision as it demonstrates accuracy. But you never fully disengage.

Alex: It's the supervised learning approach applied to ops tooling. The agent isn't replacing you day one—it's learning from you.

Jordan: And the best practices documentation is clear: quote "Any remediation action should go through an approval process at the beginning." They're not pretending this is a set-and-forget solution.

Alex: Alright, let's build out an evaluation framework. If someone's listening and considering this for their team, how should they think about it?

Jordan: Five questions to answer honestly before you pilot.

First: are you primarily AWS? If less than seventy percent of your infrastructure is in AWS, the value proposition weakens significantly. The deep integration is the differentiator—without that, you're paying for a diagnosis engine that doesn't have full context.

Alex: Second?

Jordan: What's your current MTTR? You need a baseline before you can evaluate improvement. If you're already at fifteen minutes through good runbooks and experienced team, the improvement headroom is limited. If you're at two hours because diagnosis takes forever, there's substantial room to gain.

Alex: Third?

Jordan: Can you invest in training the agent? This isn't deploy-and-done. The best results come from teams that actively guide the agent, correct false positives, and provide context on their specific environment. Budget two to four weeks of active engagement from your senior SREs during the pilot phase. If you can't dedicate that, you won't see the returns.

Alex: Fourth?

Jordan: Is twenty incident hours per month enough to properly evaluate? Calculate your current incident volume. If you're handling ten incidents per day and each investigation takes thirty minutes, you'll burn through the preview quota in a week. That's not enough time for statistically meaningful evaluation.

Alex: And fifth?

Jordan: What's your tolerance for preview-stage tooling? Because right now, this is preview. Features may change. Stability isn't guaranteed. Compliance certifications don't exist yet. If you need production-grade with SLAs, this isn't ready. If you're comfortable with early-adopter risk, proceed.

Alex: For teams that pass those filters, what does a good pilot look like?

Jordan: Pick one application or service with high incident volume. Create a single Agent Space with limited scope. Run in parallel with your existing tooling—don't replace PagerDuty or your runbooks. Measure four things: time to diagnosis compared to baseline, accuracy of root cause identification, quality of mitigation plans, and false positive rate. Track where human intervention was still needed despite agent involvement.

Alex: How long should a pilot run?

Jordan: Minimum thirty days of real incidents. You need enough sample size to evaluate accuracy. Ideally sixty to ninety days—that gives you a better picture of edge cases and the slow-burn issues that only manifest over time.

Alex: What should teams watch for when GA is announced?

Jordan: Four things. First, the pricing model—usage-based is confirmed, but the specifics will determine whether this is viable at scale. Second, multi-region availability—US-East-1 only is a non-starter for enterprises with data residency requirements. Third, compliance certifications—SOC 2 and ISO 27001 are table stakes for regulated industries. Fourth, expanded autonomous execution—right now it generates plans but can't execute. That's the next frontier, and it's where the real value will eventually come from.

Alex: And expanded language support. English-only is limiting for global teams.

Jordan: True. The agent currently only supports English-language conversations, which is a real barrier for teams operating across regions with non-English-speaking operators.

Alex: Let me paint two scenarios to crystallize the decision.

Jordan: Go for it.

Alex: Scenario one: You're a mid-size fintech running entirely on AWS. EKS for compute, Aurora for databases, CloudWatch and Datadog for observability, GitHub Actions for CI/CD. Your on-call team is burning out—three to four incidents per night, MTTR averaging ninety minutes. You've got engineering capacity to dedicate to tooling evaluation.

Jordan: That's the ideal candidate. You have the AWS density for full integration value. You have the incident volume for meaningful evaluation. You have the MTTR headroom for measurable improvement. And you have the capacity to invest in the learning curve. Sign up for the preview, run a focused pilot, and measure results.

Alex: Scenario two: You're an enterprise running workloads across AWS, Azure, and GCP. Hybrid on-prem and cloud. Multiple observability vendors—Dynatrace for APM, Splunk for logs, custom Prometheus stacks. Complex compliance requirements including SOC 2 for your AWS footprint.

Jordan: Wait and see. The multi-cloud reality means you're not getting the full control plane advantage. The complexity of your environment will stress the agent's correlation capabilities. The compliance requirements mean you can't put preview software anywhere near production data until certifications are available. Better to let this mature, watch the GA announcement, and evaluate then.

Alex: Let me bring it home.

Jordan: The dream of autonomous on-call isn't fully here yet. AWS DevOps Agent represents a real step forward in AI-assisted incident response—the investigation capabilities are genuinely impressive, and the integration depth is something only AWS can achieve with their control plane access.

Alex: But it's important to understand what quote "autonomous investigation" means versus quote "autonomous remediation." Today, this is a very capable diagnostic assistant that still needs you to pull the trigger on fixes. It won't replace your on-call rotation. It will—potentially—make that rotation less painful by doing the initial investigation work that currently takes thirty to sixty minutes of manual correlation.

Jordan: The numbers are promising. Teams properly configured are seeing MTTR drop from forty-five to eighteen minutes. Forty percent auto-diagnosis rate. Significant alert noise reduction. But those results require investment—in Agent Space configuration, in training the agent, in providing feedback.

Alex: For AWS-heavy shops with high incident volumes, it's worth a pilot. You have the right environment to see real value. For everyone else, watch the GA announcement closely—especially the pricing and the compliance certifications. Those will determine whether this becomes enterprise-ready or remains a sophisticated demo.

Jordan: And keep an eye on the competitive responses. PagerDuty, Rootly, and the AIOps vendors aren't going to cede this ground. AWS just raised the bar for what incident response tooling should look like. The whole category is going to evolve rapidly in twenty twenty-six.

Alex: That's the show for today. AWS DevOps Agent—real capabilities, real limitations, and a framework for evaluating whether it fits your environment.

Jordan: Tomorrow we'll be back with more platform engineering insights. Until then, keep building, keep questioning the hype, and remember: the best tooling is the tooling that actually ships production value, not the tooling that sounds best in a keynote.