Datadog and AWS Shipped Ops Agents on the Same Day. What Are They Fighting Over?

On June 9, 2026 (US time), two big announcements landed on the same day.

At the keynote of Datadog's annual event DASH 2026 in New York, the Bits AI family expanded significantly: Detection, Investigation, Remediation, Infrastructure, Code, Release, Testing, Data Analysis, Chat, Memories, and Evals. Counting by agent, that is more than ten, with over 100 new features announced together. The full picture is laid out in the keynote roundup.

https://www.datadoghq.com/blog/dash-2026-new-feature-roundup-keynote/

The same day, AWS announced FinOps Agent as a public preview. It bundles four data sources, Cost Explorer, Cost Anomaly Detection, Cost Optimization Hub, and Compute Optimizer, and delivers automated cost-anomaly investigation, natural-language cost questions, periodic cost reports, and aggregated optimization opportunities straight into Slack and Jira. The details are in the AWS blog.

https://aws.amazon.com/blogs/aws-cloud-financial-management/aws-finops-agent-is-now-public-preview/

AWS DevOps Agent had already gone GA in March, handling incident response. With FinOps Agent now added, AWS-built standard agents line up across the main operational domains. That said, DevOps Agent also covers multicloud and on-premises environments, so its scope differs from FinOps Agent, which targets AWS cost data.

https://aws.amazon.com/blogs/mt/announcing-general-availability-of-aws-devops-agent/

On the surface, this looks like two separate stories: Datadog the monitoring platform, AWS the cloud provider. But read the two announcements side by side, and you see both reaching for the same territory, Ops, through different entrances. Line up their features and most of them overlap, so a surface spec comparison won't show the difference. This article sorts out the same-day releases by the two companies' positioning, asks what these very similar agent lineups are actually fighting over, and goes as far as the axes for telling them apart and the predictions that follow.

This is written for people working in SRE, FinOps, and Platform Engineering.

Why the "Ops Agent" Category Is Taking Shape Now

FinOps, DevOps, and SRE go by different names, but they share the same structural problem: the round-trip cost between the operator who notices an anomaly and the developer who actually fixes it.

Concretely, this kind of flow happens every day. Take cost management. Cost Anomaly Detection raises an alert about a cost anomaly. Someone opens a dashboard and looks at the per-service breakdown. They isolate whether the spike came from EC2 or RDS, open CloudTrail, and cross-check who deployed what. They confirm with stakeholders on Slack, then open the repository to find the relevant IaC code. By this point you have moved back and forth across many screens and tools. Writing the fix and opening a PR comes after all that.

Incident response follows the same flow. An alert fires, you open a dashboard, read logs, follow APM traces, pull stakeholders into Slack, and apply a fix. It is a chain of context switches, and it wears you down even more when the response runs into the middle of the night.

What changed over the past year or so is that LLM accuracy reached a level where it can take on this interpretation-and-round-trip work. Reading monitoring data, interpreting the cause, and proposing a fix can now be run on your behalf. The desire to make monitoring and action seamless has been around for a while; the shift is simply that it can finally be shipped in the form of an autonomous agent. In fact, AWS started lining up its operational agents around re:Invent 2025 late last year, when it previewed DevOps Agent and Security Agent.

https://aws.amazon.com/about-aws/whats-new/2025/12/devops-agent-preview-frontier-agent-operational-excellence/

That DASH 2026 and AWS FinOps Agent landed on the same day is probably not a coincidence. Two companies from different territories are evolving in the same direction at the same time. It was a day that showed exactly that.

How Datadog and AWS Differ in Strategy

Let's compare the two strategies along three axes: data source, coverage, and how each positions its agents.

Data Source

AWS owns cost data and CloudTrail as first-party data. This is data that only AWS holds completely.

AWS FinOps Agent's anomaly investigation is designed to leverage this directly. It starts from a Cost Anomaly Detection event and correlates the CloudTrail events around it. Because CloudTrail records who called which API and when, it can automate all the way to identifying the operation that drove the cost change and the IAM user or role behind it, the owner who bears responsibility. The output is not interpretation that reaches into business factors, but a Jira ticket or Slack notification delivered straight to the responsible engineer.

This is a flow you cannot build unless you hold both the place where cost is generated and the place where resources are operated. Third-party FinOps SaaS can ingest the CUR (Cost and Usage Report), but matching it against CloudTrail at the same precision is not as easy as it is for AWS itself, given data lag and permissions. AWS can capture its own API calls in near real time, and there lies a structural advantage.

Datadog owns the telemetry of APM, logs, traces, RUM, and profilers as first-party data. Bits Detection looks at real-time metrics and logs plus historical baselines, service topology, ownership information, and source-code context, and continuously judges whether the current state is healthy. Bits Investigation traces the root cause, and Bits Code takes on the fix, producing a production-ready PR on GitHub.

Because the kind of data at the source differs, the anomalies each is good at differ too. AWS is strong at "money anomalies," Datadog at "performance and behavior anomalies." Both call themselves general-purpose Ops agents, but as long as the underlying data source differs, the center of gravity of what they are good at naturally differs.

Coverage

AWS stays within its own cloud. It does not cover multicloud or SaaS.

This is a weakness and a strength at once. For an organization that runs entirely on AWS, everything from cost to execution logs sits inside the same cloud. Conversely, for an organization where Snowflake, Databricks, Google Cloud, Vercel, and others are mixed in, AWS FinOps Agent alone cannot see the organization-wide cloud cost anomalies.

Datadog spans multicloud and SaaS, and on top of that pulls in log infrastructure placed on your own infrastructure. In addition to BYOC Logs, which lets you search logs while keeping them in your own cloud environment, DASH 2026 introduced Federated Logs, which lets you search across external data stores like Databricks and ClickHouse from Log Explorer using the same syntax. It is expanding in the direction of searching from Datadog no matter where logs are scattered.

https://www.datadoghq.com/blog/introducing-datadog-byoc-logs/

Which side you choose depends on how far your operation spans. For an organization that is 100% AWS, the former is enough; for one with multiple clouds or SaaS mixed in, you need the latter's reach. Even an organization using both can land on a split: AWS FinOps Agent for cost optimization, Datadog Bits for performance and availability.

How Each Positions Its Agents

This difference is what I most want to convey in this article.

AWS is trying to treat AI agents as building blocks that run on its own platform. Bedrock AgentCore is that foundation, with components coming together: Memory, Identity, Observability, Gateway, Runtime, and built-in tools like Browser Tool and Code Interpreter. DevOps Agent and FinOps Agent are positioned as AWS-built standard agents that ride on top of this layer.

In other words, AWS holds the execution environment for agents itself and rolls out concrete agents on top of it over time. AgentCore also supports third-party frameworks like LangGraph and CrewAI, so third-party agents are expected to ride the same foundation.

Datadog is trying to look at AI agents from the outside, as objects to monitor. The Datadog Agent Console announced the same day is a mechanism that gives a cross-cutting view of the coding agents used across an organization (Claude Code, Cursor, GitHub Copilot, and so on) alongside Datadog's own Bits AI. It answers, in a single UI, questions like who is using which agent and how much, whether it is paying off compared to not using AI, and where cost is being wasted and what can be fixed.

What matters here is that Datadog's own Bits AI is also among the monitored targets. Your own agents and competitors' agents can be compared side by side in the same UI. The stance is not "use our agent," but "we'll give you visibility into your organization's agent operations themselves."

AI Guard sits in the same line of thinking. It protects AI agents from attacks like prompt injection, tool misuse, and data exfiltration, but the protection is not limited to Datadog-made agents. It discovers unprotected agents in the environment and includes externally built agents as targets. Datadog is positioning itself to monitor, protect, and govern agents.

AWS, which tries to own agents, and Datadog, which tries to monitor them. This difference is the core of the two strategies.

A Mapping of the Territory Agents Cover

Here is how each company realizes the territory that AI agents cover, from operations through development. This is not a comparison of the clouds as a whole. The top half is the day-to-day work of operations and development (from detection, investigation, and remediation through code change, release, and testing); the bottom half is the foundation that supports it (memory, evaluation, monitoring, protection, and execution environment). In this table, a slash means multiple products are candidates, and a plus means several are combined.

Most of the roles overlap. The strengths show up in the areas that don't overlap, or where the strength clearly differs.

Datadog has the reach to bring even external agents under its monitoring, plus a design, via Bits Code and Bits Release, that closes the loop from detection through fix and validation inside Datadog.

AWS has root-cause identification for cost anomalies, sourced from data it owns in CloudTrail, plus AgentCore Runtime as a foundation for pulling third-party agents onto its own platform. The latter is a device for inviting third-party developers to "run your agents on AWS."

The Tipping Point Is "Who Changes the Code"

Look at the mapping and one point of contention surfaces: how much of the flow from detection through investigation, code change, and release validation each company completes inside its own UI. That is where the turf war between the two lies.

Datadog's Bits Code is the emblematic product on this front. According to the official description, Bits Code takes signals from Error Tracking, APM Recommendations, Continuous Profiler, Test Optimization, Code Security, and Bits Investigation, and takes over the chain of work an engineer usually does by hand: triaging the problem, locating the relevant code, writing the fix, running tests, and opening the PR. It handles all of it in one stroke.

In other words, it is trying to pull into Datadog the division of labor that used to be "monitoring tools alert you, fixes are the job of the IDE and GitHub." The repository itself lives on GitHub or GitLab, but the entity generating the PR is Datadog.

AWS DevOps Agent also goes from root-cause identification through fix proposal. But when the fix reaches into application code, the main stage for that code is not necessarily on AWS's own services, so the degree of closure here is weaker. AWS's main horse for coding is Kiro, which is good at spec-driven development, or third-party agents via Bedrock, and DevOps Agent ends up on the side that coordinates with them. AWS's strategy is a different path: hold AgentCore as the agent execution environment, and put everything, including third parties, onto its own platform.

This is where the Datadog Agent Console comes in. By bringing the Claude Code, Cursor, and GitHub Copilot that an organization uses under monitoring, even the activity of coding agents running outside Datadog comes into view. Because Bits Code itself is also a monitored target, in-house and third-party can be compared side by side in the same UI.

So Datadog is taking a position where, even without owning the coding agent itself, it can hold the initiative by taking the stance of monitoring it. AWS, on the other hand, takes the stance that if everything is completed on top of AgentCore, monitoring is handled in-house too.

Which strategy works depends on where engineers spend their time. A team that stays long in the AWS console leans AWS; a team whose main stage is the Datadog UI and Slack leans Datadog. For organizations with many resources that can only be touched directly via the AWS console (IAM, VPC, Cost Management), AWS's advantage tends to hold. For organizations whose operations revolve around Slack notifications and PR reviews, the range Datadog can cover keeps extending.

Predictions from the Facts

From the facts laid out so far, here are a few predictions.

Prediction 1: AgentCore Repeats Bedrock's Strategy for Agents

AWS's strategy looks like a replay of its Bedrock strategy. Bedrock grew into a foundation that hosts models from Anthropic, OpenAI, Meta, and others on AWS, places them on the same footing as AWS's own Nova models, and puts everything on the AWS bill. Rather than betting on which model wins, it secures a share of the AI market by holding the execution environment and billing where models run.

AgentCore Runtime is trying to reproduce this same structure in the agent market. Rather than building a large number of agents in-house, it is a device for steering third-party agent developers to "run it on AWS." DevOps Agent and FinOps Agent are positioned as reference implementations that run on top of that foundation. Components like AgentCore Memory, Identity, Observability, and Gateway look like a setup where AWS takes on the common parts that agent developers find tedious to build themselves.

Whether this strategy works hinges on whether agent developers accept AgentCore's constraints. Just as Bedrock succeeded in pulling in model providers, if AgentCore succeeds in pulling in agent providers, AWS can keep monitoring, execution, and billing all inside its own house.

Prediction 2: Bits Code and Bits Release Together Signal Datadog's Closure Strategy

At DASH 2026, Datadog lined up Bits Code, which handles code change, and Bits Release, which handles release validation, in the same family. Bits Release is an agent that analyzes the intended impact of a code change, builds a validation plan, runs checks in staging, and watches the rollout. The two lining up together is itself a sign of strategic intent.

To complete the loop from detection through investigation, code change, and release validation inside your own walls, holding the code change (the fix PR) is the starting point. Once you hold the code change, release validation becomes a natural extension: "Datadog watches over the PR Datadog produced at release time." Conversely, if the code change is taken by another company's IDE-side agent or GitHub Copilot, holding release validation alone in-house does not make a closed loop.

Hold the loop's entry point with Bits Code, and pull its exit into your own walls with Bits Release. With these two lined up, a path to completing detection through fix and release inside Datadog's UI has come into view. Some of these features are still in preview, but the odds are high that Datadog finishes building the whole thing end to end.

Prediction 3: Integration into Chat and Tickets Is Part of a Big Shift to "Push UX"

Both companies emphasize chat and ticket-management tools as the output destination for their agents. AWS FinOps Agent lets you specify Slack or Jira as the output destination, and Datadog Bits also delivers investigation results and notifications to tools of the same kind.

This shows a big shift from a "go look at the dashboard" UX to a "delivered where the engineer already is" UX. Until now, both monitoring tools and FinOps tools were built on the premise that the user goes to look at the dashboard. The alert arrives by email, and you check the details on the dashboard.

In the age of agents, this flips. When a problem occurs, the interpretation and recommended action arrive directly in chat. You open the dashboard only when you want to dig deeper, or when you can't accept the agent's judgment. The dashboard drops to the position of a reference that quietly backs up the agent's judgment.

This change is reaching the billing model too. On top of the conventional per-view or per-seat billing, Datadog has already adopted AI credits tied to the agent's workload, and consumption-based billing per investigation. Not how much you look at the dashboard, but how much you put the agent to work. The axis of monitoring billing is starting to move that way.

Prediction 4: Coding-Agent Operations Move from "Individual Tool" to "Organizational Tool"

The very fact that the Datadog Agent Console launched shows that coding-agent operations are taking shape as a genre. When Claude Code, Cursor, and GitHub Copilot are adopted ad hoc, it is easy to end up in a state where no one can see who is using how much.

Each tool, too, is moving to bundle organizational usage, like GitHub Copilot's enterprise management features or Cursor's team features. But an individual tool's management screen is basically closed within that product. The Datadog Agent Console is trying to put a cross-cutting management layer on top of that. It is a different direction from, but close in aim to, GitHub Copilot starting to pull other companies' coding agents onto its own platform.

The category of an "organizational coding-agent operations dashboard" is already taking shape. What isn't visible yet is the next step: industry-standard tags for cost allocation, and per-agent productivity metrics (PR acceptance rate, error rate, cost per accepted PR, and so on).

Prediction 5: The Initiative War Develops into a Three-Way Contest

So far I've written in terms of the two parties, Datadog and AWS, but the real initiative war looks like a three-way contest. GitHub and GitLab, which hold the home of source code; AWS, Google Cloud, and Azure, which hold the execution platform; Datadog, Grafana Labs, and New Relic, which hold the monitoring platform. Each is after the initiative in the age of agents.

GitHub is moving in the direction of completing the loop from code change through release to monitoring inside GitHub, with the combination of Copilot and Actions. GitHub Advanced Security includes Copilot Autofix, which is already built out to the point of opening a PR with a proposed fix for a vulnerability detected by CodeQL.

The repository side, the execution-base side, and the monitoring side are each reaching, from the territory they own, for the loop of detection, fix, and release. Rather than any one of the three winning outright, the using organization picks the lead based on its own scale, industry, and existing stack. The winner splits by organization, that kind of outcome looks likely.

Prediction 6: An Organizational Shift in FinOps

What AWS FinOps Agent changes most may be not the technology but the shape of the organization.

FinOps has so far mostly run on a central FinOps team. A group of specialists builds cost reports and talks with the development teams in a monthly review. In recent years, the central team has been moving toward setting standards and guardrails while delegating responsibility to each team, but the carriers of that work were still people. AWS FinOps Agent is designed so individual engineers can ask about cost in natural language, and so that when an anomaly occurs, a Jira ticket arrives directly to the engineer.

For an organization that wants to lean toward self-service, this is a device that advances that shift a step, because an agent can take on the decentralization that people used to carry. If you take this path, the FinOps team's job moves from teaching everyone toward mapping accounts to owners, setting tag conventions, and designing the context handed to the agent. The FinOps specialist doesn't disappear; the substance of the work changes toward shaping the foundation. The view is that such an option has become realistic.

A similar structure shows up in other areas. In SRE, there is the choice between watching monitoring directly and shaping the monitoring system. In Platform Engineering, between each team handling its own infrastructure and a team laying down a standard path with guardrails so they can. In security, between a specialist team reviewing one item at a time and embedding policy into the platform's templates. In each, there is a choice: does the specialist team handle the field directly, or move to the side that shapes a system the field can run on its own.

Neither is the right answer. There are organizations where full centralization fits, and organizations that delegate heavily to the field. Many settle in the middle, where a center provides standards and guardrails and the field moves on its own within that range. AI agents have arrived as an option that can realize the "field moves on its own" side at a lower cost than human effort. The self-service shift in FinOps is one example. Adopting AI agents widens not only the how of monitoring and operation, but the very set of options for where an organization places the center of gravity of its roles.

Anticipated Objections

A few objections come to mind against the picture so far. Let me raise them and answer each.

Objection 1: Datadog's Multicloud Advantage

Datadog can see multicloud and SaaS too, so won't it win on coverage in the end?

The breadth of multicloud coverage is indeed Datadog's strength. But AWS has an area, cost data and CloudTrail, where only AWS holds the first-party data. The advantage that AWS itself can trace the basis for a cost change at the highest precision remains. Even a multicloud organization can land on a split where it leans only its AWS cost governance onto AWS FinOps Agent. Unifying monitoring versus precision of the data source: these two hard-to-reconcile axes are what's at stake here.

Objection 2: The Disadvantage of Staying Inside Its Own Cloud

AWS closes itself inside its own cloud. Doesn't the narrow coverage put it at a disadvantage?

Narrow coverage is indeed a disadvantage. But developers who use AWS as their main platform already spend long hours in the AWS console. Being able to slip into the screen engineers already touch is a strong weapon for lowering the cost of behavior change. Not having to move people to a new UI works strongly in the field of tool adoption.

Objection 3: The Both-at-Once Option

Rather than picking one, why not just adopt both?

In fact, this is a realistic option. In coding, the practice of using multiple agents in parallel has already spread: refining the design with Claude Code, handing implementation to Codex, and having one review the other's output. Use agents with different strengths, and have one verify the other's results. For Ops agents too, the same worldview holds up well.

But it holds up because humans have the judgment axis of "which to use for what, and which output to trust." Ops agents overlap heavily in function; anomaly investigation, auto-remediation, and natural-language questions can all be done by both. Put both in without a judgment axis, and all that's left is the cost of carrying the same experience in two places, with engineers wondering which one to ask. It is the same structure as the monitoring-tool sprawl of the past. Whether you make the most of using both comes down to the design of how you divide them.

Objection 4: The Possibility That Datadog Sees Everything Anyway

If agents on AgentCore are visible from Datadog too, won't Datadog hold it all in the end?

This is a future well worth considering. AgentCore Observability is OpenTelemetry-compatible and can already send telemetry to external monitoring tools, including Datadog. Even if AWS holds the execution base and billing, a split where the main stage of monitoring stays on the Datadog side is possible. Holding execution but opening monitoring to the outside: that gradient looks like the long-term fault line for initiative.

Objection 5: GitHub Entering the Field

Won't GitHub, which holds the repository, build the same loop first?

This connects directly to the three-way contest from Prediction 5. GitHub is actually moving in this direction, building a code-origin loop with the combination of Copilot Autofix and Actions. Datadog's Bits Code starts from monitoring, GitHub Copilot Autofix from code, AWS DevOps Agent from the execution base. The same loop, with each reaching from a different entrance, is how it can be organized.

Where to Start

The axes for telling them apart are now in place: data source, coverage, and how each positions its agents. With those three, you can read each agent's character. So let's move to what to actually do first. I'll organize this assuming a common setup: AWS as the execution base, Datadog for monitoring, GitHub for code management.

Step 1: Put into Words What Your Operation Runs "From"

The first thing to do is not tool selection or a proof of concept, but putting the current state into words. When an incident or cost anomaly occurs, where do you look first, where do you identify the cause, and where do you apply the fix? Write out this round-trip path once, and you start to see which vendor your organization is most compatible with.

The judgment axis can be organized like this.

In many organizations, several of these apply at once. If you use AWS as the execution base, Datadog for monitoring, and GitHub for code management, you probably match most rows of the table. That's exactly why, rather than putting everything in at once, you need to prioritize by which path has the highest round-trip cost right now.

Step 2: Agentify Just the One Highest-Round-Trip Path First

Try to agentify everything at once and you end up just trying a bunch of agents at once with no settled evaluation axis. The realistic move is to narrow to the one path from Step 1 where the human round-trip happens most.

For example, an organization spending serious hours each month on cost-anomaly investigation could start by trying AWS FinOps Agent's public preview, configured with Slack notifications and a threshold filter (only investigate anomalies above a certain amount). If the initial investigation for incident response has become a late-night burden, pick either AWS DevOps Agent or Datadog Bits Investigation, choosing based on whether your incidents stay inside AWS or reach external SaaS. Narrow to one path, and you can concretely evaluate what got faster compared to doing it by hand, and what you can't yet trust.

Step 3: Sort Out Context and Tag Conventions During the Trial

An agent's accuracy changes greatly with the context you hand it. AWS FinOps Agent is designed to take context files like account-to-owner mappings, team definitions, tag conventions, and review cycles. Whether it can resolve "what is this team's cost" to the right set of accounts hinges on this context work.

What matters here is that sorting out context and tag conventions is an investment that won't go to waste no matter which vendor you choose. The account-to-owner table, tag conventions for cost allocation, and service-to-team mappings are included. These work as the prerequisite information handed to the agent, whether for AWS FinOps Agent or for Datadog. Sort it out while you're still in the trial phase, and it carries over as is, whether you move to full adoption or switch to a different vendor. Sorting out the metadata at your feet before the agent itself is a shortcut that looks like a detour.

Step 4: Start Visibility into Coding-Agent Operations Early, as a Separate Track

This is a slightly different topic from Ops or FinOps, but for running an organization's AI use in a healthy way, it's worth moving on in parallel.

If you use Claude Code, Cursor, and GitHub Copilot across the organization: who uses how much, how much it costs, and how many PRs get accepted. Aren't there many organizations struggling to get these numbers? Use that started as an individual trial eventually spreads to teams and the whole organization. So as not to scramble at that stage, you want to anticipate team and enterprise use from the start. Now that a visibility layer for agent operations like the Datadog Agent Console has appeared, even if adoption is deferred, it's safe to at least start the discussion early on how to make your organization's coding-agent use visible.

The metrics worth tracking are around the number of users and frequency of use, spend per agent, PR acceptance rate, and rework rate of fixes. With those visible, you can judge by the numbers which agent to weight investment toward, and where waste is occurring.

Because It's a Transitional Period, Build Switchability into the Design

What's common across these steps is the stance of not going all-in yet. Most Ops agents are still in preview, and their features and billing models will change.

That's exactly why you should avoid building deeply dependent on a specific vendor's conventions, and instead thicken assets that work no matter where you land, like the context and tag conventions from Step 3. Put the data source and round-trip path into words, sort out the metadata, and validate one path at a time. Proceed in that order, and whether you move from trial to full adoption, or the initiative landscape shifts, you can move without panic.

What's Happening Now

That the two companies' announcements landed on the same day is a signal that the Ops-agent category has entered a phase where multiple vendors reach for the same territory at the same time. Datadog, strong in monitoring, and AWS, with the cloud base, are each reaching for the initiative from the source of their own strength. The structure where the one who holds the most data also holds the action that follows is a movement that applies to AI agents generally.

AWS's strategy is platform-type: hold the lower layer of the agent execution environment, line up the agents that ride on it with its own products over time, and invite outside developers onto the same foundation. Datadog's strategy is meta-platform-type: hold the outer layer of the monitored target, and make both its own and others' products visible in the same UI. And as the third party in the three-way contest, GitHub and GitLab, which hold the home of source code, are entering the same territory.

Which strategy comes out ahead changes with what an organization runs its operations from, so there is no single answer. But the structure of this competition itself is a microcosm of the initiative war in the age of agents. Each reaches, from its own territory, for what lies beyond. The one who owns the infrastructure reaches for the execution environment of the software that runs on it. The one who monitors reaches for the action beyond the expanding monitored target. The one who keeps the code reaches for the loop of code generation and release.

What's being fought over is the initiative of where, in which UI, to complete the loop from detection through fix to release. The same-day release of June 9, 2026 was the day that fight came clearly into the open.