Hands-On with AWS DevOps Agent: Changing DevOps Work Without Replacing Engineers

Introduction

When an AI agent can investigate incidents, read operational context, query systems, and suggest what might be wrong, it is natural to ask whether this kind of capability will eventually replace part of the work DevOps engineers do today.

In this article, I will share how we experimented with AWS DevOps Agent, why we wanted to bring the investigation flow closer to engineers through Slack. The goal is not to argue that AI agents should replace DevOps engineers, but to show how they can change the type of work engineers spend time on.

The most important part is: what the engineer asks, what context the agent needs, which skills make the investigation useful, and where human judgment should remain in control.

The turning point

Generative AI focuses on creating new content based on an input. The output can be text, images, audio, video, software code, or any other artifact generated from a prompt. That is already useful in many engineering workflows, especially when the task is about explaining, summarizing, drafting, or creating something from existing context.

Agentic AI has a different goal. Instead of only generating content, an agent is expected to work toward an outcome. In the DevOps context, this means the agent needs to understand what is happening, use tools, inspect data, reason over the environment, and come back with findings that help the engineer decide what to do next.

This difference becomes important when the problem is not “write me a summary,” but something closer to “investigate why this service is failing.” In that case, the useful output is not only a nice explanation. The useful output is a hypothesis supported by evidence from logs, metrics, topology, recent changes, known incidents, and operational knowledge.

The DevOps problem we wanted to solve

At the AI Center of Excellence team at PostNL, we build and operate AI capabilities used by multiple teams and applications. These services do not live in a single cloud environment. A single user-facing capability can depend not only on AWS services, but also services in other cloud providers, services, external APIs, networking, authentication, model providers, and internal platform components.

The complexity is not necessarily the number of services involved. The real complexity appears when something goes wrong, and the engineer needs to understand where to look first. During an incident, this can easily become a manual process of opening dashboards, checking the AWS Console, searching logs, inspecting metrics, comparing timestamps, and trying to form a hypothesis from many disconnected signals.

This is especially painful during on-call situations. When an engineer is woken up at night, the first minutes are often spent collecting evidence instead of making decisions. The engineer still needs to own the decision, but there is a lot of repetitive investigation work before reaching the point where human judgment is most valuable.

Why we chose AWS DevOps Agent

When you look at this kind of problem, it is tempting to say that you should simply build an agent. However, building an agent is not only about sending a prompt to a model. You need to define, among other things:

• What the agent should achieve;
• Which systems it can access;
• Which tools it can use;
• What information it should remember;
• How much autonomy it should have;
• Which actions require approval;

In our case, we wanted the benefit of an operational investigation agent, but we did not want to become the team responsible for maintaining the entire investigation engine ourselves. We needed something that could understand resources, dependencies, operational patterns, and topology, while still allowing us to shape the workflow around our own environment.

This is where AWS DevOps Agent became interesting. Instead of building the investigation engine from scratch, we could use the managed capability as the core and focus on the thin layer around it. That layer was still important, but it was much closer to our actual problem: making the investigation accessible from where engineers already work and giving the agent the right operational context.

What we built around it

One of the decisions we made early was that we did not want another dashboard. During incidents, engineers are already communicating in Slack, so asking them to open another tool just to start the investigation did not feel like the right experience.

The idea was to create a Slack bot that could act as the entry point for investigations. An engineer could ask something like /watchdog investigate the 429s we are seeing, and the bot would trigger the investigation flow with AWS DevOps Agent. The result was not meant to remove the engineer from the process, but to reduce the amount of manual evidence gathering before the engineer could make a decision.

The architecture was intentionally thin around the managed capability:

• Slack was the interface where engineers already worked.
• The /watchdog command was the trigger for the investigation.
• A small Lambda function behind an API Gateway translated the Slack request into an investigation request.
• AWS DevOps Agent performed the investigation using the operational context available to it.
• The Slack thread became the place where findings and updates were shared back with the engineer.

The agent itself was also defined as infrastructure. The important part was to define the AWS DevOps Agent space and the role it could assume to investigate the AWS account. The cool thing is that you can control exactly what resources the agent is allowed to investigate. 

One limitation we had to account for is that not everything in AWS DevOps Agent was available through CDK or CloudFormation. The Agent Space and AWS account association could be defined as infrastructure, but skills still had to be configured outside CDK at that point. That means the infrastructure could create the managed agent foundation, while the operational knowledge attached to the agent still required a separate setup step in the console.

In a simplified version of the CDK code, the core definition of the AWS DevOps Agent space looked like this:

import * as cdk from 'aws-cdk-lib';
import * as iam from 'aws-cdk-lib/aws-iam';
import { Construct } from 'constructs';

export class DevOpsAgentStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    const agentSpaceArnPattern = `arn:aws:aidevops:${this.region}:${this.account}:agentspace/*`;

    const monitorRole = new iam.Role(this, 'MonitorRole', {
      assumedBy: new iam.ServicePrincipal('aidevops.amazonaws.com', {
        conditions: {
          StringEquals: { 'aws:SourceAccount': this.account },
          ArnLike: { 'aws:SourceArn': agentSpaceArnPattern },
        },
      }),
      managedPolicies: [
        iam.ManagedPolicy.fromAwsManagedPolicyName('AIDevOpsAgentAccessPolicy'),
      ],
    });

    monitorRole.addToPolicy(
      new iam.PolicyStatement({
        actions: ['iam:CreateServiceLinkedRole'],
        resources: [
          `arn:aws:iam::${this.account}:role/aws-service-role/resource-explorer-2.amazonaws.com/AWSServiceRoleForResourceExplorer`,
        ],
      })
    );

    const agentSpace = new cdk.CfnResource(this, 'AgentSpace', {
      type: 'AWS::DevOpsAgent::AgentSpace',
      properties: {
        Name: 'example-devops-agent',
        Description: 'DevOps investigation agent',
      },
    });

    new cdk.CfnResource(this, 'AwsMonitorAssociation', {
      type: 'AWS::DevOpsAgent::Association',
      properties: {
        AgentSpaceId: agentSpace.ref,
        ServiceId: 'aws',
        Configuration: {
          Aws: {
            AccountId: this.account,
            AccountType: 'monitor',
            AssumableRoleArn: monitorRole.roleArn,
          },
        },
      },
    });
  }
}

This gave us a workflow where the agent could do the first investigation pass, but the engineer still owned the interpretation and the next step. That distinction was important because the goal was not to create a fully autonomous incident response system, but to reduce the repetitive work required to understand what was happening.

The skills we defined for the agent

The Slack bot request handler was only one part of the solution. The more important part was the context we provided to the AWS DevOps Agent space. A generic investigation agent can be useful, but real environments have details that are specific to the organization, the platform, the architecture, and the way teams operate.

For that reason, we defined custom skills and knowledge sources to help the agent understand our environment better. This can be easily created in the AWS DevOps agent space web app. Some examples were:

• sample-skip-scheduled-maintenance: used to skip low-priority incidents during a scheduled maintenance window and avoid unnecessary investigations for expected disruptions.
• azure-troubleshooting-guide: used to give the agent troubleshooting context for Azure-related incidents, performance issues, and dependencies.
• understanding-ai-toolkit-architecture: used to document the architecture on Azure, workloads, resource groups, Function Apps, Cognitive Services, networking, and related components.
• understanding-lpe-architecture: used to document the LandingZone PostNL Engineering infrastructure, including networking, IAM, monitoring, and alerting context.

These are the kinds of details that an engineer usually learns over time, but that an agent also needs if we expect it to produce useful findings.

This is where DevOps engineers still play a critical role. The value is not only in connecting an agent to tools, but in deciding which context the agent needs, which operational assumptions are safe, which sources of information are reliable, and which parts of the investigation should remain read-only or require approval.

AWS released native Slack support

There is an interesting detail in this story. We built the Slack bot because we wanted to bring the investigation flow to where engineers already work, and at that moment this meant creating our own thin integration between Slack and AWS DevOps Agent.

Later, AWS released native bidirectional Slack communication for AWS DevOps Agent. According to the AWS DevOps Agent What's New page, on September 1, 2026, AWS announced that you can start and continue conversations with AWS DevOps Agent directly from a private Slack channel by enabling bidirectional communication when associating a channel.

At first glance, it might look like this makes the custom Slack bot unnecessary. In practice, it makes the communication layer simpler, which is a good thing. The bot solved the interface gap we had at the time, but the reusable part of the work was not only the bot implementation. It was the understanding of how engineers wanted to interact with an investigation agent during an incident.

We still needed to define what engineers ask during incidents, what the agent should know, which skills improve investigations, and where the boundary between recommendation and action should be. If the native Slack integration covers the communication layer, the surrounding concepts can still help with additional context, specialized knowledge, Bedrock-based extensions, knowledge bases, or other systems that provide the agent with better input for the investigation, for example:

Before and after

The most important change is not that the engineer disappears from the workflow. The change is that the engineer starts from a better point in the investigation.

Before, the engineer had to manually collect evidence across multiple systems. That meant opening dashboards, checking cloud consoles, searching logs, comparing timestamps, and trying to understand whether the issue was related to AWS, Azure, an external dependency, networking, authentication, or something else. This work is important, but it is also repetitive and time-sensitive.

The old flow looked closer to this:

1. Wake up because something might be wrong or the engineer got a phone call.
2. Open dashboards and cloud consoles.
3. Check logs, metrics, alarms, and recent signals.
4. Compare timestamps across systems.
5. Build a first hypothesis manually.
6. Decide what to investigate next.

After introducing the agentic investigation flow, the engineer can ask the agent to investigate and then review the findings. The agent can search logs, query resources, correlate signals, and build an initial hypothesis. The engineer still evaluates the result, considers the business impact, and decides what should happen next.

The new flow became closer to this:

1. Ask the agent to investigate in Slack.
2. Let the agent collect operational signals and context.
3. Review the findings and hypothesis.
4. Decide what action, if any, should be taken.

This is the part of DevOps work that I think is worth changing. We should not try to automate judgment without understanding the risk, but we should reduce the amount of manual work required before judgment can happen.

What should stay human

Even if an agent can investigate an issue, not every action should be delegated without approval. There is a big difference between collecting evidence and changing production systems.

In a DevOps workflow, humans should remain responsible for decisions where context, risk, and business impact matter. For example, I would not put these actions in the same category as querying logs or summarizing metrics:

• restarting critical services
• changing infrastructure
• disabling alarms
• modifying permissions
• applying mitigations that affect customers

These actions require a different level of control.

This is why I believe the most useful agentic workflows are not necessarily the ones with full autonomy. A workflow where the agent investigates, correlates, and proposes a hypothesis can already remove a lot of toil. The engineer can stay responsible for the decision while spending less time collecting the evidence manually.

Conclusion

AWS DevOps Agent is interesting to me because it can change the kind of DevOps work engineers spend time on. The goal is not to remove engineers from the process, but to reduce the repetitive investigation work that happens before engineers can make good decisions.

In our experiment, the Slack bot was a way to bring the investigation flow closer to where engineers already work. With the native bidirectional Slack support now available in AWS DevOps Agent, that communication layer can become simpler, but the core lessons remain useful. The operational context, the skills, the knowledge sources, and the approval boundaries are still the parts that make the workflow valuable.

The opportunity is to let the agent help with logs, signals, topology, and hypotheses while keeping engineers responsible for context, risk, and business impact. In other words, use AWS DevOps Agent to change DevOps work, not to replace DevOps engineers.