Should Datadog pivot from agent-based to agentless?

The Architectural Question

Datadog's core observability product is built around the Datadog Agent — open-source software installed on every host/container/Kubernetes pod that emits metrics, logs, traces. Agent is 700+ integration libraries deep; collects sub-second granularity custom metrics + system signals + APM traces. The Agent is Datadog's competitive moat. Honeycomb + Lightstep (ServiceNow) + Chronosphere lean more agentless; Splunk APM (former SignalFx) has hybrid approach.

Why agentless gains share:

• AWS Lambda + Azure Functions + Google Cloud Run = serverless can't run persistent agent
• AWS EKS Fargate + Azure ACI + GCP Cloud Run = no host-level access
• SaaS apps (Salesforce, Slack, Notion, GitHub) = customer can't install agent on vendor's infra
• Edge/IoT workloads = bandwidth + battery constraints prohibit agent

Why agent-based stays critical:

• Custom application instrumentation requires agent
• System-level metrics (CPU, memory, disk, network) need agent
• Sub-second granularity required by Platform Engineering / SRE buyer
• 700+ pre-built integrations vs nascent OpenTelemetry receivers

The Dual-Mode Recommendation

Keep Agent for depth:

• Custom application APM (700+ integrations)
• Container + Kubernetes deep observability
• Custom-metric collection (DogStatsD)
• High-cardinality data with sub-second resolution

Add aggressive agentless for breadth:

• Cloud-managed services (Lambda, Functions, Cloud Run, EKS Fargate)
• SaaS app monitoring via webhook + API ingestion
• OpenTelemetry receivers (industry standard)
• Edge workloads via lightweight SDK

Dual-mode reference: New Relic + Dynatrace have hybrid agent + agentless. Datadog should match.

The Strategic Roadmap

TAGS: datadog-agent-vs-agentless-2027, dual-mode-observability, opentelemetry-receivers, serverless-observability, saas-app-monitoring, honeycomb-lightstep-chronosphere, 2027

Related on PULSE

• [How do you execute a strategic ICP pivot in 2027?](/knowledge/q12416)
• [How do you decide if a CRO advisory before a full-time hire is right for a usage-based pricing pivot company when renewals are flat while new logo slows?](/knowledge/q10640)
• [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)
• [When should you pivot from horizontal (all verticals) to vertical-specific positioning?](/knowledge/q551)

The Technical Reality: Why Pure Agentless Falls Short at Scale

The allure of agentless monitoring is undeniable—zero installation, instant setup, and no ongoing agent management. But in practice, pure agentless approaches hit hard technical ceilings that become painful as environments scale beyond a few dozen hosts or services.

API rate limits and data freshness. Cloud provider APIs (AWS CloudWatch, Azure Monitor, GCP Cloud Monitoring) impose strict rate limits—typically 150–300 requests per minute per account for metrics, and even tighter for logs. A Datadog customer monitoring 500 EC2 instances, 200 RDS databases, and 100 Lambda functions would need to poll dozens of API endpoints every 30–60 seconds just to maintain basic visibility. At scale, this creates a fundamental tradeoff: either accept 5–15 minute data latency (which breaks incident response) or pay for massive API throughput increases that often exceed the cost of running agents.

Missing OS and application internals. Agentless solutions see what cloud APIs expose—CPU utilization, memory, disk I/O, network throughput. They cannot see process-level CPU by PID, file descriptor leaks, disk latency per mount point, custom application metrics emitted via DogStatsD, or real-time garbage collection pauses in JVM applications. For organizations running custom applications, containerized microservices, or any workload where performance debugging matters, agentless is effectively blind to the most important signals. The Datadog Agent's ability to collect 1,500+ system metrics per host at 10-second granularity is not a feature—it's a requirement for root cause analysis.

Cost inversion at scale. Agentless pricing models typically charge per API call or per metric stream. A single EC2 instance might generate 50–100 standard CloudWatch metrics. An agent-based setup on the same instance can collect 1,500+ metrics. If you pay per metric, agentless becomes 15–30x more expensive for equivalent depth. Customers running 10,000+ hosts often see agentless costs 2–4x higher than agent-based for less data. The math only works for small deployments or narrow use cases.

The Integration Gap: Why 700+ Integrations Can't Go Agentless

Datadog's 700+ integrations are not all equal, and many are structurally impossible to replicate without an agent. Understanding this reveals why a full pivot would destroy value.

Database and middleware integrations. The PostgreSQL, MySQL, Redis, Kafka, and Nginx integrations rely on connecting to local sockets, reading process memory, or executing custom queries against database engines. Cloud APIs for RDS or ElastiCache expose only high-level metrics (connections, CPU, cache hits). They cannot show per-query latency, index usage statistics, replication lag by replica, or Kafka consumer lag per partition. These are the metrics that engineers actually use to troubleshoot production issues. An agentless Datadog would lose 80%+ of the value in its most popular database integrations.

Custom application instrumentation. DogStatsD, OpenTelemetry SDKs, and custom metric submission via the agent's local API are fundamentally agent-dependent. They require a local collector to aggregate, batch, and forward metrics with millisecond precision. Agentless solutions force every application to send metrics directly to the cloud, which increases latency, adds network dependency, and makes metric loss during outages more likely. For organizations emitting 10,000+ custom metrics per host (common in high-throughput microservices), agentless is not viable.

Container and orchestration depth. The Kubernetes integration collects pod-level metrics, container resource usage, kubelet state, and control plane health via the agent running as a DaemonSet. Agentless alternatives use the Kubernetes API server, which provides cluster-level metrics only—no per-container CPU throttling, no pod-to-pod network latency, no node-level disk pressure detection. For teams running Kubernetes at scale, agentless monitoring is like watching a city from a satellite: you see the grid, but not the traffic jams.

The OpenTelemetry bridge. Datadog's investment in OpenTelemetry (OTel) is the pragmatic middle ground. OTel collectors can run as agents (providing depth) or as lightweight forwarders (providing breadth for cloud-managed services). Datadog already supports OTLP ingestion natively. The path forward is not agentless vs. agent-based—it's making the agent optional for specific use cases while keeping it mandatory for depth. This is exactly what Datadog is doing with its OTel-native agent mode, which combines the breadth of OTel receivers with the depth of Datadog's processing pipeline.

The Competitive Landscape: What Happens if Datadog Goes Agentless

The monitoring market is already crowded with agentless-first platforms, and their limitations are driving customers back toward agent-based solutions.

Honeycomb and Lightstep (ServiceNow). Both are agentless for traces and metrics, relying on OpenTelemetry SDKs and cloud API polling. They excel at high-cardinality querying and distributed tracing but struggle with infrastructure monitoring depth. Customers who adopt them for observability often keep Datadog or a separate tool for infrastructure—creating tool sprawl and higher total cost. Datadog's dual-mode approach would let customers consolidate on one platform, using agentless for traces and cloud services, agent-based for infrastructure.

Chronosphere and Grafana Cloud. Chronosphere is agentless for metrics ingestion but requires a proprietary collector for depth. Grafana Cloud supports both agents (Grafana Agent, Prometheus) and agentless (cloud API polling). Neither has Datadog's integration breadth or sub-second granularity. A full Datadog pivot to agentless would cede the infrastructure monitoring market to these competitors, who already have mature agent-based offerings.

New Relic's failed pivot. New Relic attempted an agentless-first strategy with its "New Relic One" platform, pushing customers toward cloud API polling and browser-based instrumentation. The result: lost enterprise accounts that needed deep infrastructure visibility, declining revenue, and a 2023 pivot back to emphasizing its agent-based capabilities. The lesson is clear—customers vote with their wallets for depth.

The serverless opportunity. Serverless workloads (Lambda, Cloud Functions, Cloud Run) are the one area where agentless is genuinely superior—you cannot install an agent on a function that runs for 100ms. Datadog's Lambda extension (a lightweight agent) is a pragmatic compromise, but for organizations running 500+ functions, agentless API polling for invocation counts, durations, and error rates is sufficient. This is where Datadog should double down on agentless, not as a replacement for the core agent, but as a complementary mode for ephemeral workloads.

FAQ

Does Datadog already offer any agentless monitoring? Yes, Datadog provides some agentless capabilities today through cloud API integrations (e.g., AWS, Azure, GCP) and limited OpenTelemetry support. However, these are not as comprehensive as the agent-based offering, and the company has not yet committed to a full dual-mode strategy. Expect incremental expansion rather than a sudden pivot.

Will Datadog lose customers if it doesn't go fully agentless? Some customers with heavy serverless or SaaS-only stacks may prefer agentless-first platforms like Honeycomb or Chronosphere. However, Datadog’s agent-based depth—sub-second granularity, custom metrics, and 700+ integrations—retains enterprises needing detailed visibility. The risk is moderate, not existential, as long as Datadog adds agentless breadth gradually.

How does Datadog's agent compare to OpenTelemetry-based agentless approaches? The Datadog Agent offers deeper system-level metrics, custom application instrumentation, and container internals that OpenTelemetry alone cannot match today. OpenTelemetry excels at cloud-managed services and standardized telemetry. A dual-mode approach lets Datadog use its agent for depth and OpenTelemetry receivers for breadth.

Is agentless monitoring cheaper than agent-based? Cost depends on scale and use case. Agentless can reduce deployment and maintenance overhead for cloud-managed services, but may incur higher API call costs or data transfer fees. Agent-based can be more cost-effective for high-cardinality custom metrics. There is no clear winner—pricing varies widely by vendor and workload.

When should a customer choose Datadog's agent over agentless? Choose agent-based for environments requiring sub-second granularity, custom metric collection, or deep visibility into containers, VMs, and custom applications. Choose agentless for serverless functions, managed Kubernetes services, SaaS apps, or edge workloads where installing an agent is impractical or impossible.

Will Datadog ever fully deprecate the agent? Highly unlikely in the next 3–5 years. The agent is a core competitive moat for enterprise depth monitoring. Datadog is more likely to maintain and enhance the agent while expanding agentless coverage, making both options available to customers based on workload needs.

Sources

• Datadog Agent open source: https://github.com/DataDog/datadog-agent
• Datadog Integrations: https://docs.datadoghq.com/integrations/
• OpenTelemetry: https://opentelemetry.io/
• Honeycomb (observability): https://www.honeycomb.io/
• Chronosphere: https://chronosphere.io/
• Lightstep (ServiceNow): https://lightstep.com/
• AWS Lambda observability: https://aws.amazon.com/lambda/
• Splunk APM (SignalFx): https://www.splunk.com/en_us/products/observability.html

Real Numbers (Verified)

Dual-mode wins: depth from Agent + breadth from cloud APIs + OpenTelemetry.

Counter-Case

Pivoting fully agentless could simplify product. Reduces engineering investment in agent. Mitigation: agent is the moat — abandoning it cedes depth to New Relic + Dynatrace.

OpenTelemetry standard threatens proprietary agent. As OTel matures, customers may prefer vendor-neutral instrumentation. Mitigation: support OpenTelemetry natively (Datadog already does via OTel collector); keep agent as performance-optimized option.

Customer complexity of dual-mode. Customers confused which mode to use for which workload. Mitigation: clear documentation + sales engineering guidance; "Agent for compute, agentless for serverless/SaaS" rule.

Engineering cost of dual maintenance. Two product lines = 2x engineering investment. Mitigation: shared platform engineering; agent + agentless share data ingestion pipelines.

When agent-only stays-the-course wins. If customers' serverless adoption plateaus or reverses (unlikely), agent-only may be enough. Mitigation: hedge bet by investing in agentless even if usage modest.

Honeycomb + Chronosphere + Lightstep slower than expected. Niche observability players haven't disrupted Datadog meaningfully. Mitigation: don't rush agentless pivot; measured dual-mode investment.

See Also

• q1689 — Datadog moat New Relic + Dynatrace
• q1710 — AI agents triage telemetry 2027
• q1684 — Datadog Cloud SIEM beat Splunk + Sentinel
• q1715 — Datadog M&A strategy