In 2024, we wrote that OpenTelemetry was the future of observability, and that a platform built natively on it, rather than one that merely accepted OTel data at the door and converted it into a proprietary model, would serve customers better. We built Dash0 on that bet. In November 2025, we introduced Agent0, our agentic AI platform for observability, because reading dashboards and correlating traces by hand doesn't scale, and an expert-agent guild that could do it for you was the obvious next step.
Both calls were right. Neither is enough anymore.
What changed in six months
Software delivery moved faster in the first half of 2026 than most of us expected. According to the Faros AI Engineering Report, across 22,000 developers and 4,000 teams, AI now writes most of the code that ships: task throughput is up 34%, epics completed are up 66%, and code-related tasks are up 210% per team. That part is the good news, and it's the part every vendor keeps repeating.
Here's the part that doesn't make the slide: incidents per pull request are up 243%, more than tripled. Bugs per developer are up 54%. PRs merged without any review are up 31%. Median review time is up 442%, five times longer. Lead time from commit to production is up 480%. Faros calls this the Acceleration Whiplash: AI has flooded a system built for human-paced development with output it was never designed to absorb. Their own summary is blunt: "All organizations suffer from the Acceleration Whiplash, irrespective of their engineering maturity."
At the same time, we watched a category form in real time. AI SRE agents stopped being a research demo and became something teams run in production. And we watched how our own customers actually reach their data: less through a browser tab, more through an MCP server or a CLI, because the thing asking the question is increasingly an agent, not a person squinting at a dashboard. Observability built a UI for humans. It never seriously built an API for agents. That gap is now the whole game.
Put those two shifts together and the problem comes into focus. Code is generated at machine speed. Production is still run at human speed. Dashboards and alerts, however good, assume a person is on the other end of every notification, with time to read the dashboard, run the playbook, and open the pull request. That assumption is the one that's now broken.
From observability-native to beyond observability
Our OpenTelemetry-native bet doesn't change: own your data, in open formats, with no lock-in. What changes is what "your data" has to serve. For thirty years telemetry had one reader: a human, looking at a dashboard. Today it has two, and the agent reading your traces to draft a fix needs native access to the same data (with more context) as the engineer reviewing that fix in a pull request.
That's the shift behind this post. We're moving beyond observability. What is needed today is a closed loop from prompt to production or from code to customer. Developers, coding agents, SREs and agents running in production need to have access to all signals and full application runtime context to work at machine speed. This is a massive shift how observability has to be designed and operate.
Three things ship out of that shift. Here's what each one does.
SignalStore: own your data, natively
Our ingestion and storage layer is becoming SignalStore, the OpenTelemetry-native data platform for humans and agents. It's the same commitment from 2024, extended to cover every signal that matters in production, logs, metrics, traces, profiles, events, and RUM, stored once, in open formats, in a single cost-transparent datastore with no proprietary lock-in.
The part that's new is the two-reader design. Humans get a unified query layer, PromQL and SQL, plus a console to explore, alert, and dashboard. Agents get standardized access of their own: MCP, CLI, API and tools and context to operate effectively. Every vendor supports OpenTelemetry today.
The other half of SignalStore is SignalControl, which exists because the same forces driving up incidents are driving up data volume. AI writes more code, which ships more instrumentation, which produces more telemetry, faster than any team can afford to store and query all of it. SignalControl shapes what enters SignalStore before you pay to store it: a spam filter that drops low-value data at ingestion is live today, and derive-and-convert plus sampling to cut cardinality and trace volume further. In an illustrative pipeline run, that stack took the volume for logs, metrics and spans down 74%, without losing the signal that actually matters.
Darkplane: closing the loop on what AI builds
Observability answers what's happening in production. It has never answered what AI spent building the change that caused it, or whether that change was ever safe to ship unattended. That gap is what Darkplane closes: the control room for the AI that writes your code.
Darkplane starts with AI Coding Insights, shipping today: what AI coding actually costs across your org, and how much of that output your team keeps. It observes the coding agents themselves, sessions, token usage, cost, and tool calls, and ties every session to the repo and branch it worked in, so when a pull request shows up, the spend behind it comes attached instead of living in a separate billing export you have to reconcile by hand. It help with adoption throughout your product teams and shows the ROI of your token spend.
AutoMerge, coming next, is the other half. Agents now open more pull requests than any team can review by hand, and most auto-approval today runs on static rules: always clear dependency bumps, never touch anything else. Darkplane weighs live context instead, the health of your error budget, the author's track record, whether the files a change touches were reverted last week, and clears the small, safe changes you'd only ever rubber-stamp anyway. Everything else still goes to a person. Your checks say whether a change looks right. Darkplane decides what AI is trusted to ship on its own, and it starts conservative, widening only as a given type of change earns it in production.
Agent0 Automations: production on autopilot
Agent0 already goes further than a chatbot for your telemetry: ask it a question and it investigates, traces the root cause, and can open the fix as a pull request. But that's still a conversation somebody has to start. With code shipping at machine speed, we can't keep running production at human speed, one conversation, one Slack ping, one engineer awake at 2am at a time.
Agent0 Automations removes the conversation. You define a trigger (a failed check, a schedule, a deployment, a webhook, anything that emits a signal), a prompt in plain language, and the guardrails Agent0 has to stay inside, once. From there, Agent0 acts on its own, at agentic speed. A check fails at 2:17am, and by the time the on-call engineer opens Slack, Agent0 has already traced the checkout error spike to a config change deployed hours earlier, written the fix, and left the full investigation waiting in the notifications channel. A deployment ships, and Agent0 runs a health check on the affected services and reports back before anyone has to ask. A shell opens in a running container, and Agent0 validates it against policy and opens a Terraform PR to update the allowlist.
Automations ships with a catalog of agents that cover the common cases out of the box: incident investigation, deployment health checks, security policy checks, reporting, and more. It also lets you add your own, because the automations your production actually needs are never fully covered by somebody else's catalog. Every run is on the record, credit-based pricing keeps the cost of each one visible in the dashboard, and the guardrails are yours to set: what Agent0 can touch, what needs a sign-off, what it never does without you.
Closing the loop
None of these three exist in isolation. Darkplane governs what AI builds. Agent0 governs what AI runs. SignalStore is the data both of them read and write. What breaks in production should teach the agents that build the next change, and that only happens if the loop actually closes instead of stopping at a dashboard.
That loop is the actual answer to the Acceleration Whiplash. You don't fix tripled incidents by asking humans to review AI-written code faster than they already are, or by adding another dashboard to a system that was already too slow to keep up. You fix it by governing what ships, watching what runs, and letting agents act on both ends, with the same data underneath the whole thing.
Observability isn't going anywhere
To be clear about what this is not: it is not a pivot away from observability. Dash0 started there, and it stays the core of what we do. We keep investing directly in it, SLOs based on the OpenSLO standard, continuous profiling, and more, are all coming, alongside everything you already rely on for digital experience, applications, and infrastructure monitoring. Beyond observability doesn't mean instead of it. It means observability was always supposed to be the foundation for something bigger, and we're finally building the rest of it: the control plane for what AI builds, and the autopilot for what runs in production, both standing on the same OpenTelemetry-native data.
Coding is solved. The bottleneck just moved, from writing code to shipping it safely and running it reliably once it's out. We built Dash0 on OpenTelemetry because we believed owning your data was the foundation everything else would need. Everything we're shipping now is what we're building on top of it.
SHIP MORE. BREAK LESS.
Start for free at dash0.com/sign-up, or book a demo and we'll show you where the loop closes for your team.
