What’s new in LaunchDarkly (Sep 2026): warehouse assignment, sample size estimates, and AgentControl datasets

What this page covers

This page is for a release lead, experimentation lead, or product engineer who already runs LaunchDarkly and wants September’s changes without reading the whole changelog — especially anything that changes where assignment comes from, how sample size is set before a test, or how AgentControl evaluation datasets are edited.

We list only entries dated September 2026 on LaunchDarkly’s changelog, plus the 3 September AI SDK announcement that LaunchDarkly published the same day as the sample-size entry. We don’t speculate about roadmap items. August AgentControl SDK and LiteLLM notes are out of scope except where September builds on them.

The product-ops guardrails stay the same: AI and automation suggest; a named experiment owner or release owner approves every warehouse assignment source, sample-size target, dataset save, and AgentControl config change. No customer PII or raw session data goes into a general chat tool.

Major features (with how someone uses them)

Examples at a glance: each feature has a concrete example from a real job plus a short Try this you can run this week.

1. Five changes a release or experimentation lead should act on (primary)

What it is: From the September notes, these five need a decision from someone, not just awareness: (1) warehouse-native experiment assignment from your own table, including retroactive analysis (23 September — changelog entry); (2) in-app sample-size and duration estimates for fixed-horizon frequentist experiments (3 September); (3) editable, versioned offline-evaluation datasets in AgentControl (16 September — changelog entry); (4) the LaunchDarkly AI SDK for Python and JavaScript as the recommended AgentControl path (3 September — blog post); and (5) who owns defining an assignment source once and reusing it across experiments in the same project and environment. Each is linked to the same dated source: LaunchDarkly changelog.

Concrete example (experimentation lead on the first Monday of October) An experimentation lead copies the five items into the team’s change log, assigns an owner to each, and writes one question per owner: for warehouse assignment, “which table is the source of truth, and who can edit it?”; for sample size, “do we attach an estimate before every frequentist launch?”

Try this

Primary workflow:

From LaunchDarkly’s Sep 2026 changelog, list 5 changes a release or experimentation lead should act on — cite sources.

2. Warehouse-native assignment (23 Sep)

What it is: On 23 September LaunchDarkly shipped warehouse-native experiments where audience assignment comes from a table in your own warehouse rather than a LaunchDarkly flag evaluation. If your team randomizes in its own service, or assignment happens in a third-party tool such as an email platform, those tests can be analyzed in LaunchDarkly with the same statistics, exposures, and sliced results as any other experiment. It also works backwards: assignment data already in the warehouse can be analyzed retroactively. You define an assignment source once and reuse it across experiments in the same project and environment.

Concrete example (data scientist reviewing a past email test) A data scientist points LaunchDarkly at the warehouse table that held last quarter’s email-variant assignments, runs the analysis, and finds the lift claim only holds in one region. She shares the sliced result with the experiment owner before anyone reuses the old “win” in a deck.

Try this

Name the source of truth:

List every experiment last quarter that was randomized outside LaunchDarkly. For each, write the warehouse table (or “none”), who owns it, and whether you would analyze it with a LaunchDarkly assignment source. Have the experiment owner approve before connecting anything.

3. Sample size and duration in the product (3 Sep)

What it is: On 3 September LaunchDarkly added an in-app way to estimate how much traffic a frequentist experiment needs and how long it will take. You can start from the experiment list for a quick check before you commit to a design, or from the builder to attach the estimate to that iteration so the experiment carries its own sample-size target. You can view, edit, or remove that target from the results page while the experiment runs. Estimates assume steady traffic, so an experiment may hit its sample size earlier or later. Available for fixed-horizon frequentist experiments.

Concrete example (PM designing a checkout test) A PM attaches a sample-size estimate in the builder, then watches traffic dip during a holiday week. The estimate says the test will run longer; she edits the target on the results page and tells stakeholders the decision date moved, instead of calling the test early.

Try this

Attach before you launch:

Pick one planned fixed-horizon frequentist experiment. Run the in-app sample-size estimate, attach it to the iteration, and write the decision date you will not move earlier without the experiment owner’s OK.

4. Editable AgentControl evaluation datasets (16 Sep)

What it is: On 16 September AgentControl gained in-place editing for offline-evaluation datasets. A dataset holds the inputs for an offline evaluation; each row is one case AgentControl runs your config against and scores. Open a dataset from the AgentControl Library for a Rows tab: add a row by hand or append a file, edit input, expected output, variables and metadata, search, reorder, and delete. You can create an empty dataset and add rows without a finished CSV or JSONL first. Changes stage until Save; each save creates a new version with who changed it, when, and the row count. Evaluation runs pin to the version that existed when the run started.

Concrete example (ML engineer owning an agent prompt config) An engineer fixes three bad expected-output rows, saves a new dataset version, and re-runs the eval. The previous run’s scores stay pinned to the old version, so she can compare without rewriting history. The AgentControl owner approves promoting the config that used the new version.

Try this

Version before you promote:

Open one AgentControl offline-evaluation dataset. Edit a single row, save, and confirm a new version appears with your name and the new row count. Write who must approve before any config that used the old version is promoted.

5. LaunchDarkly AI SDK (3 Sep)

What it is: Also on 3 September, LaunchDarkly published the LaunchDarkly AI SDK for Python and JavaScript as the recommended path for every new AgentControl integration. One install command replaces a multi-package setup; the SDK can record supported metrics automatically and send traces to LaunchDarkly Observability. The existing AI SDKs remain supported and move to maintenance mode with no migration deadline. New capabilities will land in the LaunchDarkly AI SDK going forward.

Concrete example (engineering manager starting a new agent feature) A manager asks the team starting a new agent path to use the LaunchDarkly AI SDK, not the legacy packages. They keep an existing production agent on the old SDK until a scheduled migration, with the AgentControl owner approving any config change either way.

Try this

Pick the path for new work:

List agent features you plan to start in the next 60 days. Mark which will use the LaunchDarkly AI SDK from day one, and which stay on a legacy SDK until a named migration owner schedules them.

6. Who approves each September change

What it is: Warehouse assignment sources touch your warehouse and experiment statistics — the experiment owner and a data owner approve connecting a table. Sample-size targets change when a test is “ready” — the experiment owner owns edits on the results page. Dataset saves change what AgentControl scores — the AgentControl config owner approves promotions that used a new version. AI SDK adoption is an engineering standard — the platform or AgentControl owner sets the default for new work. None of these are auto-approved by AI.

Concrete example (product ops coordinator) A coordinator adds four rows to the team’s change calendar: warehouse source (data owner), sample-size policy (experimentation lead), dataset versioning (AgentControl owner), and AI SDK default (platform lead). Each has a review date in October.

Try this

One owner per change:

For the four September themes above, write one named owner and one October review date. Have the experimentation lead approve the list before anyone connects a warehouse table or changes a live sample-size target.

Pricing context (October 2026)

September’s changelog entries did not mention price changes. LaunchDarkly publishes usage-based prices on its pricing page; as of 8 October 2026: Developer $0/mo (5 service connections, 1K client-side MAU, 5K AI runs/mo included); Foundation pay-as-you-go at $10 per service connection / mo (first 5 included) and $8.33 per 1K client-side MAU / mo billed yearly, with 5K AI runs included and $5 per extra 1K AI runs; Enterprise and the Guardian add-on are quote-only.

For our dated notes on LaunchDarkly’s AI features (Vega, AgentControl, guarded rollouts), see the LaunchDarkly AI review.

Uncertainty: We read LaunchDarkly’s changelog, the linked September entries, the AI SDK blog post, and the pricing page on 8 October 2026. Plan availability for warehouse-native assignment and AgentControl features can differ by contract. Always verify on the live changelog and your project settings. This is product education, not advice for your release process.

When it’s useful (honest take)

Useful when you run experiments or AgentControl in LaunchDarkly and want September’s dated changes with an owner and an action for each.

Useful when you randomize outside LaunchDarkly today and need to decide whether warehouse assignment belongs in your stack.

Less useful when you want a full product review — read LaunchDarkly AI — or you don’t use experimentation or AgentControl.

Related options (educational)

FAQ

What did LaunchDarkly change in September 2026?

Per the public changelog: warehouse-native experiment assignment (23 Sep), editable AgentControl offline-evaluation datasets (16 Sep), and in-app sample-size estimates for fixed-horizon frequentist experiments (3 Sep). The same day as the sample-size entry, LaunchDarkly also announced the LaunchDarkly AI SDK for Python and JavaScript.

Can I analyze past experiments that were randomized elsewhere?

The 23 September entry says assignment data already in your warehouse can be analyzed retroactively once you define an assignment source. Confirm the table, ownership, and privacy rules with your data owner first.

Which experiment types get the sample-size calculator?

LaunchDarkly’s 3 September entry says the in-app estimates are available for fixed-horizon frequentist experiments.

Do dataset edits change past evaluation results?

No — the 16 September entry says evaluation runs pin to the dataset version that existed when the run started, and each save creates a new version you can restore.

Did LaunchDarkly change prices in September 2026?

The changelog entries we read don’t mention price changes. As of 8 October 2026 the pricing page still listed Developer at $0, Foundation at $10 per service connection and $8.33 per 1K client-side MAU billed yearly, and Enterprise/Guardian as custom.

Optional next step (if seats overlap)

If product pays for LaunchDarkly, a separate experiment tool, and chat assistants that all summarize the same releases, fix that overlap before adding another seat. Map the overlap with the $19 AI toolkit audit or the $9 AI toolkit spreadsheet. Email Audit $19 or Toolkit spreadsheet $9.

Checkout is live via Stripe. After you pay, we email delivery (spreadsheet) or intake next steps (audit).

Related: LaunchDarkly AI · Statsig · Optimizely Opal · What’s new in Statsig (Sep 2026) · What’s new in Gainsight (Sep 2026) · Stack map for product ops · Gainsight AI · Fullstory AI · ChurnZero AI · Pendo AI · PostHog AI · Three checks before another AI seat · ops hub