From Watchdog to Working Dog: Datadog and the Expanding Control Layer

IT Control Plane Implications Of Datadog DASH 2026

A couple weeks ago, I went to New York where Datadog DASH was held at the Javits Center. My main takeaway: I need to expand my sense of where an IT management platform can come from.

For some years I have argued that two dominant players have emerged in IT management: ServiceNow and Atlassian. I still believe that is correct. There are plenty of best-of-breed and pure-play vendors, and neither ServiceNow nor Atlassian is short on challenges. But on revenue they have pulled ahead of the pack, and they keep expanding in interesting ways. ServiceNow is by now much more than a help desk tool. Atlassian is much more than a backlog manager and developer story tracker. I have watched Dynatrace, Datadog, and Splunk from a greater distance. These vendors are also financially massive. Datadog is at roughly $4bn a year revenue – compared to Atlassian at $5bn and ServiceNow at $10bn.

So, what does it mean for an IT management platform to emerge from the operations and control layer? I have a taxonomy. It distinguishes the resource being controlled from the layer immediately above that does the controlling, and then the human sensemaking and work layers above that. ServiceNow and Atlassian live in those upper layers. Datadog and its peers live at the direct control layer, which carries certain advantages, and which gives them a path to disintermediate the vendors upstairs. Note, this was not an explicit theme at DASH. It was however an adjacency much on my mind, and I could hear it underneath what was said in various ways.

Datadog is, in effect, building what might be called an operational envelope around modern systems and agents: it can observe their behavior, their cost, and their safety characteristics, and increasingly act on those observations. By doing this, it intrudes into the work management layer.

It also is left-shifting: Datadog now can make use of information from the entire software development lifecycle. This means that Datadog can examine source code as part of its automated forensic analysis; it’s part of the context of an incident, to use the trendy term.

I am not sure some readers appreciate how radical this is. When I came of age, production code was compiled, linked, and deployed as opaque binaries. The operations capability had no business looking at the source. The developers had no business logging into operational systems, and often could not even view live monitoring; at best a developer might look over the shoulder of a systems operator.

Some of those protocols still exist, for good reason. But ever since DevOps and Agile took hold we have watched the old norms erode, and it makes sense, because software now evolves so fast that the proximate cause of a major outage is very likely to be found in the source (as opposed to infrastructure failure). GitOps drives this further: operators do not change the running system except by committing new configuration to source at the infrastructure-as-code level, the Terraform templates and Ansible playbooks.

As you would expect in the generative AI era, one key message was the increasing autonomy of modern operations frameworks. Datadog knows full well that this is a minefield and will require careful trust-building over a decade or more. But the Datadog agent is set up to act, to function as an SRE.

(The Datadog agentic family is called Bits, and I did not realize until the conference that the Datadog dog is itself named Bits. I had thought about titling this post “Bits: the tail that wags the dog.”)

There is quite a bit of Bits: Bits SRE, Bits Detection, Bits Remediation, Bits Database Optimization, Bits Code, Bits Evals. Bits Remediation presumably holds the authorizations to do meaningful work, such as restarting a Kubernetes pod.

Autonomy is being introduced first in places where actions are bounded and reversible. At one point a lengthy checklist appeared of everything you can configure Bits to do or not do. Is a pod restart acceptable? Fine. Is a container rebuild acceptable? Fine. And so on down the list. This is the kind of incremental motion into self-healing computing that makes sense, and it is the only way battle-hardened operators will surrender any control to the agentic layer.

Restarting a Kubernetes pod qualifies. Opening a pull request qualifies. In these cases the blast radius cost of a wrong action is (hopefully) limited and recovery is straightforward. More consequential actions remain gated, at least for now, behind explicit human approval and policy.

We have been building self-healing into infrastructure for decades. Memory correction did not used to live in the infrastructure layer; you had to program it in. So the idea that some logic might autonomously call for a pod restart at the behest of Datadog is not remarkable, especially since Kubernetes configured certain ways will restart the pod on its own anyway.

But there is a spectrum. When we get to an AI diagnosing a fault, correlating it to a recent source code change and perhaps an ITSM change ticket, reading the diff, identifying what changed, proposing a fix, testing the fix, satisfying itself that the fix works, and then pushing that fix to production: that is where we move into genuinely new territory.

Anyone who has used Claude Code in a sandbox has already watched Claude do exactly this. Seeing it happen in large-scale production systems is, in my view, a matter of when and not if. There will be incidents, errors, the occasional database blown up. But the benefits probably outweigh the risks, people will put in guardrails and safeguards, humans will stay in the loop, and progress will continue.

There is also a boundary here that should be kept in mind. Datadog appears increasingly capable of governing the operational envelope of these systems—detecting anomalies, prioritizing issues, and orchestrating remediation within defined guardrails. The question of correctness in a business sense, however, remains outside its scope. Determining whether a proposed change actually advances a business outcome, satisfies a regulatory requirement, or aligns with organizational intent is still work that sits above the direct control layer.

Which brings me back to the broader question: what does an IT-derived IT management platform look like? Well, in order to move up the chain, it minimally needs workflow. Which Datadog has. Another key capability, very unsettled right now, is IT visibility – constructing a persistent representation (digital twin if you like) of the estate, now including agents.

Datadog is using AI, clearly. It is also increasingly managing AI, the other side of the coin. It is assembling an operational control plane for agents: a system that can observe their behavior, meter their cost, and constrain their actions. The same telemetry used to diagnose incidents is now applied to agent execution. Decision paths can be traced (via OpenTelemetry) and tool use monitored. However, a tool primarily focused on observability is not going to actually *control* agents in the sense of unified policy enforcement (pre/post hooks, etc).

This control plane governs the operational envelope: behavior, cost, safety, and the immediate consequences of an action. It can detect anomalies, prioritize work, and in some cases act within defined guardrails. It does not own the governance record or determine whether an outcome is correct for the business.

Change control, compliance, and work management remain with ServiceNow, Jira, and their equivalents. Datadog governs execution under policy; it hands off where organizational intent and accountability are defined. This is where we need linkages to FInOps, product portfolio, and architecture.