Should Datadog pivot from agent-based to agentless?

The outcome you should expect

If Datadog commits to a dual-mode architecture rather than a wholesale pivot, the outcome over a two-to-three-year horizon is fairly predictable, and it looks less like a dramatic product reinvention than like a widening of the funnel at the top and a hardening of the moat at the bottom.

The first thing that changes is time-to-first-value. Agent deployment is the single most common stall point in an observability rollout. A prospect signs, then discovers they need a change ticket to push a DaemonSet into a production Kubernetes cluster, or a security review for a package that runs as root on a hardened Linux image, or a Chef/Ansible/Terraform change that has to wait for the next release window. That is not a two-hour delay; in regulated enterprises it is routinely a four-to-eight-week delay, and it happens *after* the contract is signed, which means the revenue is booked but the usage — and therefore the expansion and the renewal case — is not. An agentless on-ramp that reads AWS CloudWatch, Azure Monitor, or Google Cloud Monitoring through a cross-account IAM role turns that first mile into an afternoon. The customer sees their infrastructure inventory populated before the security team has even scheduled the agent review.

The second change is coverage of workloads where the agent is not an option at all. AWS Lambda functions that run for 120 milliseconds cannot host a persistent collector in any meaningful sense; Datadog's Lambda extension is a clever workaround, but it is still a layer the customer has to attach to every function and it adds cold-start weight. Fargate tasks give you no host to install onto. Managed database services — RDS, Cloud SQL, Azure SQL — hand you a connection string and nothing else. SaaS applications your customer runs but does not own (the CRM, the ticketing system, the identity provider) will never accept a third-party binary. Each of these is a place where "agentless" is not a philosophical preference but the only physically available mechanism.

The third change — and this is where the RevOps consequence lives — is what happens to the shape of the account. Agentless coverage is broad and shallow: it inventories everything, it alerts on the obvious, and it costs comparatively little per resource. Agent coverage is narrow and deep: it goes on the systems that actually matter and it carries the higher per-host price. A dual-mode platform lets the land motion be agentless and cheap across the whole estate, and the expand motion be agent-based and expensive on the tier-one services. That is a materially better commercial structure than "install the agent or get nothing," because it converts the agent from a barrier to entry into an upsell trigger. The customer who has agentless visibility into 4,000 cloud resources and agent-based depth on 300 of them has a natural next question every quarter: which fifty resources graduate?

What you should *not* expect is a revenue mix flip. Infrastructure and APM built on agent telemetry remain the bulk of the business for the foreseeable future, because the customers paying the largest bills are the ones running the most complex custom software, and complex custom software is exactly the workload where agentless cannot see. The realistic outcome is additive: agentless expands the addressable surface and shortens the sales cycle without cannibalizing the depth products, provided the pricing is designed so the two modes do not compete for the same dollar.

What drives that outcome

Three forces do most of the work here, and they pull in different directions, which is precisely why the answer is "both" rather than "pivot."

Physical access to the workload. This is the dominant variable and it is binary. Either you can execute code adjacent to the thing you want to observe, or you cannot. On an EC2 instance, a bare-metal server, a Kubernetes node, or a container you control, you can — and once you can, an agent gives you process tables, file descriptor counts, per-mount disk latency, JVM garbage collection pauses, per-query database timing, Kafka consumer lag by partition, and custom metrics submitted over a local DogStatsD socket. On a managed service, a function-as-a-service platform, or a vendor's SaaS, you cannot, and you are limited to whatever the provider's API chooses to expose. No amount of engineering ambition changes that boundary. It is the reason a pivot in either direction is wrong: half the world is on each side of the line.

Data granularity versus API economics. Cloud provider monitoring APIs are polled, rate-limited, and priced per call. Standard CloudWatch metrics land at one-minute resolution by default, with higher resolution available at additional cost, and the API imposes throttling that bites hard once you are polling thousands of resources. An agent, by contrast, pushes at ten-second or sub-second intervals with no per-sample API charge, because the collection cost is borne by the host you already pay for. This means agentless data is structurally staler and structurally coarser, and the gap widens as the estate grows. For capacity planning and inventory, one-minute polled data is fine. For incident response, where the difference between a five-minute-old metric and a ten-second-old metric is the difference between watching a failure and reconstructing it afterwards, it is not.

Instrumentation standardization. OpenTelemetry is the force that makes dual-mode viable rather than exhausting to build. It graduated within the CNCF and has become the default vendor-neutral instrumentation layer, which means the SDK work application teams do is portable and the collector can be deployed either as a per-host agent or as a central gateway that receives OTLP from anywhere. Datadog already ingests OTLP natively. That is the hinge: the same protocol serves the deep-mode and breadth-mode paths, so the second mode is largely an ingestion and enrichment problem rather than a second full instrumentation stack. The strategic risk cuts the other way too — as OTel matures, the proprietary agent's differentiation narrows to processing, integrations, and operational polish rather than to data access itself.

The reason this diagram matters more than any market-share argument is that it is a *deployment* decision tree, not a *vendor* decision tree. Customers do not choose agentless as an ideology. They choose it per workload, usually without thinking about it, because one branch of the tree is closed to them. Any product strategy that forces a single global answer is fighting the topology of the customer's own environment.

Benchmarks and realistic ranges

Some concrete anchors, kept to what is publicly verifiable or genuinely representative rather than invented precision.

Integration depth. Datadog publishes well over 700 integrations. That figure is worth interrogating rather than reciting, because the integrations split roughly into three families. Cloud-service integrations (the AWS, Azure, and GCP service catalogs) are already agentless — they authenticate through a role and poll the provider API. Application and middleware integrations (PostgreSQL, MySQL, Redis, Nginx, Kafka, Elasticsearch, RabbitMQ) are overwhelmingly agent-dependent, because they work by connecting to a local socket or endpoint and running checks the cloud API does not expose. Tracing integrations sit in between, since the tracer libraries can report through an agent or, increasingly, over OTLP. A pivot to agentless would leave the first family untouched, gut the second, and complicate the third. That asymmetry is the whole argument in one paragraph.

Metric volume per host. A typical cloud instance exposes on the order of ten to thirty standard provider metrics — CPU utilization, network in/out, disk operations, status checks. An agent on that same instance collects hundreds of system metrics before you add a single integration, and once you add database, web server, and application checks, a busy host commonly reports well into the hundreds or low thousands of distinct time series. The ratio between what the provider API shows you and what an agent shows you is comfortably one-to-two orders of magnitude. Anyone claiming agentless parity is measuring "did I get a data point" rather than "can I explain the incident."

Collection interval. Agent collection typically runs on a fifteen-second cycle for system checks, with custom metrics submittable far more frequently through the local statsd socket. Provider APIs are commonly one-minute by default; sub-minute resolution exists but is a paid tier and does not extend to every metric. Practically, budget for one to five minutes of end-to-end latency on agentless pipelines once you account for the provider's own publication delay plus poll interval plus ingestion, versus a handful of seconds on agent pipelines. If your alerting SLO assumes you detect a saturation event within sixty seconds, agentless will not meet it on the metrics that matter.

Deployment friction, measured honestly. Agentless onboarding for a single cloud account is a role-creation exercise: minutes to a couple of hours including the security conversation. Agent rollout across an enterprise fleet is a configuration-management project measured in weeks, sometimes a quarter, and it recurs every time the agent needs a major version bump. This is real cost and it is the strongest argument the agentless camp has. The correct response is not to eliminate the agent but to make the agentless path good enough that nobody is blocked while the agent rollout proceeds.

Cost direction, not cost precision. The honest statement is that neither mode is universally cheaper and the crossover depends on your metric cardinality. Agentless removes per-host licensing but adds provider API charges, custom-metric charges, and — in the case of high-resolution or extended-retention provider metrics — surprisingly steep line items on the cloud bill. Agent-based concentrates the cost in per-host pricing that is predictable and easy to forecast but scales linearly with fleet size. Estates with many low-value resources (dev instances, ephemeral batch workers, a long tail of managed databases nobody thinks about) tend to be cheaper agentless. Estates with fewer, larger, heavily instrumented services tend to be cheaper agent-based. The dual-mode design lets a customer put each part of their estate on the cheaper side of that line, which is a better outcome for them and a better retention story for the vendor than forcing everything through one meter.

Adjacent comparison worth borrowing. The same broad/deep split shows up in security tooling, where agentless cloud posture scanning (snapshot-based vulnerability assessment against cloud volumes) grew explosively precisely because it needed no install, and yet endpoint agents did not disappear — they remained mandatory for runtime detection and response. The market did not pivot; it stratified. Observability is following the same shape, and the vendors who tried to force a single mode learned it the expensive way.

Risks, edge cases, and failure modes

The moat erosion risk is real but slower than it looks. The genuine long-term threat to the agent is not agentless polling; it is OpenTelemetry becoming so complete that instrumentation is fully portable and the backend becomes a commodity destination for OTLP. If that happens, switching costs collapse and pricing power goes with them. But this is a five-year risk, not a two-year one, and the defensive move is not to abandon the agent — it is to make the agent the best OTel collector available and to move differentiation up-stack into correlation, incident workflows, and the data platform. Pivoting to agentless *accelerates* this risk rather than mitigating it, because it removes the one component competitors cannot trivially replicate.

The cannibalization trap. If agentless is priced too aggressively relative to agent-based, customers will downgrade tier-one hosts to agentless coverage, accept the visibility loss, and discover it during their next major incident. That is a lose-lose: the vendor loses revenue and the customer loses the postmortem. The pricing design has to make the modes non-substitutable — agentless priced per resource for breadth, agent priced per host for depth, with the message that they solve different problems rather than the same problem at different price points.

The confusion tax. Two modes means every customer conversation now includes a "which one do I use here?" question, and if the answer is not mechanical, the sales engineering load goes up permanently. The mitigation is a rule simple enough to fit on a slide: *if you can install on it, install on it; if you cannot, connect to it.* Anything more nuanced than that will not survive contact with a distributed field organization.

The silent-gap failure mode. This is the one that actually hurts operators. Agentless coverage tends to look complete on a dashboard — every resource appears, every tile is green — while lacking the specific signal that would have caught the failure. A managed database shows healthy CPU and connection counts right up to the moment a missing index turns a nightly job into a table scan, because the metric that would have told you (per-query latency, index scan ratio) is not in the provider's API at all. Teams then trust a monitor that cannot see the failure class it is nominally covering. The defense is explicit capability labeling: the platform should state, per integration, which signal classes are unavailable in agentless mode, rather than presenting a uniformly green surface.

API throttling under incident conditions. Polling architectures degrade exactly when you need them most. During a large-scale event, everything is retrying, the provider API is under load, and your monitoring poller is competing with your own remediation automation for the same rate limit. Agent-based push does not have this failure mode because the data path is independent of the control plane you are trying to fix. Any agentless deployment covering production-critical services needs a documented answer for what happens when the API you depend on is degraded.

Data residency and egress. Agentless collection through provider APIs pulls data across account and sometimes region boundaries, which has both compliance and cost implications that rarely surface in the evaluation and always surface in the finance review six months later. Agents can aggregate and filter locally before transmitting, which is a genuine advantage for high-volume log and trace data in egress-sensitive environments.

The counter-case, stated fairly. There is a coherent argument for the pivot: it would consolidate engineering investment, remove the largest source of deployment friction, and align with where standards are heading. If serverless and fully-managed adoption accelerates faster than expected and the share of customer workloads that can host an agent keeps falling, the agent becomes a shrinking asset that is expensive to maintain across Windows, Linux, macOS, containers, Kubernetes, and function runtimes. That is a real scenario. It is just not the base case, and the hedge — invest heavily in agentless while keeping the agent excellent — costs far less than being wrong in the other direction.

A practical rollout plan

For a vendor, or for an operations team making the same decision inside their own stack, the sequence matters more than the destination.

Start with an inventory census, not a tool choice. Enumerate every workload class in the estate and tag each one as agent-capable or not. This is usually a one-week exercise and it almost always surprises people — the fully-managed share is higher than anyone estimates, and so is the tail of forgotten VMs nobody wants to touch. The census, not a vendor pitch, determines the mode split.

Land agentless first, everywhere. Create the cross-account role, connect the cloud accounts, and let the inventory populate. This establishes a complete map with no change tickets and no security review beyond IAM. Accept that this layer is for coverage and cost attribution, not for incident response, and say so explicitly in the runbook so nobody builds a paging policy on top of a five-minute-stale metric.

Then deploy agents by service tier, not by convenience. Rank services by revenue impact and blast radius. Tier one gets agents with full integration configuration. Tier two gets agents with system checks only. Tier three stays agentless indefinitely. This ordering means the expensive, slow work happens where it pays for itself, and it gives the finance conversation a defensible structure rather than a flat per-host number.

Standardize application instrumentation on OpenTelemetry regardless of mode. This is the decision that ages best. Whether the telemetry exits through an agent or an OTLP gateway, the SDK work inside the application is the same, which means the mode decision stays reversible per workload and the organization is not re-instrumenting in three years.

Build the graduation loop. Every quarter, review which agentless-only services had incidents where the available telemetry was insufficient to explain what happened. Those services graduate to agent coverage. This turns the mode boundary into a data-driven, self-correcting line instead of a one-time architectural decision that slowly goes stale — and, for a RevOps team running the vendor side of this motion, it produces a clean, evidence-backed expansion trigger that the customer largely argues for themselves.

The graduation loop is the part most teams skip, and it is the part that determines whether the dual-mode design compounds or decays. Without it, the initial mode assignment calcifies, agentless coverage quietly expands into services that outgrew it, and the first serious outage in one of those services becomes the argument for ripping the whole platform out.

Related questions

Does agentless monitoring work for Kubernetes?

Partially. The Kubernetes API server exposes cluster and object state agentlessly — deployments, pod phases, events, resource requests. It does not expose per-container CPU throttling, node disk pressure detail, or pod-to-pod network latency. Those require a node-level agent, typically a DaemonSet.

Is OpenTelemetry a replacement for the Datadog agent?

Not a replacement, an alternative transport. OTel standardizes instrumentation and can be collected either by an agent-mode collector or a central gateway. Datadog ingests OTLP natively. The agent still adds integration breadth, local aggregation, and operational tooling OTel does not provide out of the box.

Which workloads genuinely cannot run an agent?

Functions-as-a-service with very short lifetimes, serverless container platforms with no host access, fully-managed databases and message brokers, third-party SaaS applications, and constrained edge or IoT devices where CPU, memory, or bandwidth budgets rule out a persistent collector.

How should a team price agent versus agentless internally?

Charge back agent coverage per host to the owning team, since it scales with fleet decisions they control. Charge back agentless per cloud account or resource group. Keeping the two meters separate prevents teams from downgrading critical services to save budget.

What did other vendors learn from over-rotating on one mode?

The pattern across monitoring and cloud security is stratification, not replacement. Vendors who pushed customers hard toward a single collection mode lost the accounts whose workloads sat on the other side of the line, and generally reversed course within a couple of years.

FAQ

Does Datadog already offer agentless monitoring today?

Yes, in meaningful ways. The AWS, Azure, and Google Cloud integrations authenticate through a role or service principal and poll provider APIs without any installed software, and the platform ingests OTLP directly from applications instrumented with OpenTelemetry SDKs. What does not exist is a fully agentless equivalent of the deep infrastructure and middleware integrations, and that gap is structural rather than a roadmap item.

Would going fully agentless make Datadog cheaper for customers?

Not reliably. It would remove per-host pricing but shift cost onto cloud provider API charges, high-resolution metric fees, and custom-metric volume. For estates with many low-value resources the agentless bill is genuinely lower; for estates with heavy custom instrumentation it is often higher for less data. Cost is a function of cardinality and workload shape, not of collection mode.

What is the strongest argument for the pivot?

Deployment friction. Agent rollout across a regulated enterprise fleet is a multi-week project involving security review, configuration management, and change windows, and it recurs on every major version. Every day spent on that is a day of unrealized value from a signed contract. If that friction were the only consideration, agentless would win decisively.

Why is the agent described as a moat rather than a cost centre?

Because access to process-level and application-internal telemetry cannot be replicated through a cloud provider API by any competitor, no matter how well funded. Database query timing, JVM garbage collection behaviour, consumer lag by partition, custom business metrics — these exist only where code runs. A vendor that gives that up competes purely on backend and pricing, which is a much harder position to defend.

How should a RevOps or platform team decide the mode for a given service?

Apply one rule: if you can install on it, install on it; if you cannot, connect to it. Then add a review cadence — any service where an incident could not be explained from available telemetry gets upgraded to agent coverage at the next cycle. That keeps the boundary evidence-based rather than habitual.

Is there any scenario where the full pivot becomes correct?

If the share of workloads capable of hosting an agent falls far enough that maintaining collectors across Windows, Linux, macOS, containers, Kubernetes, and function runtimes stops paying for itself, the calculation changes. That is a plausible long-horizon scenario, not a near-term one, and investing in agentless breadth now is the hedge that makes it survivable either way.

Sources

• Datadog Agent source: https://github.com/DataDog/datadog-agent
• Datadog integrations catalog: https://docs.datadoghq.com/integrations/
• Datadog OpenTelemetry support: https://docs.datadoghq.com/opentelemetry/
• OpenTelemetry project: https://opentelemetry.io/
• CNCF project landscape: https://www.cncf.io/projects/
• Amazon CloudWatch documentation: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/
• AWS Lambda documentation: https://docs.aws.amazon.com/lambda/latest/dg/welcome.html
• Azure Monitor documentation: https://learn.microsoft.com/en-us/azure/azure-monitor/
• Google Cloud Monitoring documentation: https://cloud.google.com/monitoring/docs
• Kubernetes API overview: https://kubernetes.io/docs/concepts/overview/kubernetes-api/

Related on PULSE

• [Should Salesloft pivot from sequencing to AI orchestration?](/knowledge/q1830)
• [Should Outreach pivot from sequencing to agent-orchestration?](/knowledge/q1771)
• [Should ServiceNow pivot from platform-led to agent-led?](/knowledge/q1651)
• [How do you execute a strategic ICP pivot in 2027?](/knowledge/q12416)
• [When should you pivot from horizontal (all verticals) to vertical-specific positioning?](/knowledge/q551)