Most days in production still run on reaction. Something breaks, and the digging starts. Why did the funnel drop off there? Which release caused it? What was the user actually doing when it happened? And can you test the fix without exporting half your warehouse to do it?
Those questions are normal. But they share a root cause: You tend to find out something's wrong long after it happened, and the tools to act on it live somewhere else. The harder question is what changes when you can see what's happening at the point of release—and act on it right there.
That's what we unpacked on the latest episode of the Control Panel. The team walked through what's new in LaunchDarkly and, more to the point, what's live today.
Observability shouldn't just tell you something broke—it should fix it
Here's how it usually goes. You ship a feature. A Slack message lands: "Hey, did you see what I just saw?" Out comes the whole tool belt to triage the who, what, when, and why of the thing you just shipped. More features, more problems.
If you’re using LaunchDarkly, the alert reads differently: The flag has already been flipped back, production is fine, and here's the context on why. That's adaptive triggers. If you're already sending observability signals through our SDKs, you connect a flag to that data, set a threshold on something like error rate, and define what should happen if it's crossed. When it is, the change happens automatically—configured right in the UI, as part of the rollout you were already doing.
And when you do want to investigate, Session Replay ties the audience of a feature to the flag, so you can watch the exact session where a user hit the problem—with the logs, traces, and flag evaluations right alongside the playback. It's observability made active, at runtime, instead of a dashboard you check after the damage is done.
"We'll give you an alert that says, hey, we've already flipped the flag back to the original version of the feature. Everything in production is fine."
— Jay Khatri, Head of Product, Observability
The takeaway: Control has to live at the point of release, not in a dashboard you open once it's already too late.
Let AI agents do the work nobody wants to do
If you use feature flags, you have flag debt—hundreds of old flags you're a little afraid to delete. Vega Flag Cleanup takes it off your plate: Click clean up, and the agent makes the code change and opens a PR (tagged so you know it came from Vega) for you to review and merge. It warns you before touching anything in a critical environment, and it can run on a schedule across hundreds of flags.
The same idea extends to your agents through MCP. Here's what that unlocked on screen:
- Clean up stale flags with an agent that writes the change and opens the PR for you.
- Run cleanup on a schedule, so hundreds of flags a month get triaged into one-click merges.
- Let the agent of your choice (Claude, Cursor, or Codex) query your observability and experimentation data directly.
- Kick off triage and root-cause analysis from tools like PagerDuty and Slack, before you even open your laptop.
The logic is simple: AI is writing more of the code, so you want more control and guardrails once it's live—and you want your agents working from the same context you have.
"Imagine hundreds of flags going out every month. We'll automatically triage and clean them up, so your engineering teams can just click merge."
— Jay Khatri, Head of Product, Observability
Test on the data you already trust, without stopping mid-experiment
Experimentation lives or dies on trust. Measure the same thing in two places, and the numbers eventually drift—the "two-watch problem"—and once your experiment metrics and your analytics metrics disagree, you stop believing either one.
That's the case for warehouse-native Experimentation. Your warehouse remains the single source of truth: LaunchDarkly syncs assignment and exposure data into it, and metrics are computed against the datasets your team already trusts—no duplicate pipelines to maintain. Support now spans Snowflake, BigQuery, Databricks, and Redshift, and you can mix and match across more than one.
Then there's the new ability to add metrics at any time. Real life doesn't follow a clean test plan: Halfway through, a media campaign you didn't know about starts running, or you realize you forgot a metric that matters. Instead of killing the experiment and losing the days, you add the metric—or a new attribute to slice by—while it's still running, and results recalculate without a restart.
"Chief amongst anything else with experimentation is trust. You're going to make decisions based on this data—you've got to trust that data."
— Aaron Montana, Head of Experimentation and Product Analytics
See how these tools can work in your stack
If you're already using LaunchDarkly, the next step is small: Try LaunchDarkly on one stale flag, add an adaptive trigger to your next rollout, or connect a warehouse and add a metric to a running experiment.
Want a guided look—or not using LaunchDarkly yet? Request a personalized demo, and we'll show you how to see what's happening in production, act on it in real time, and test on the data you already trust.
