Repository navigation
Datadog Shipped - 10/23/26 #4
blondecostanza
announced in
Announcements
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Kicking off this roundup. 8 ships worth knowing about:
What shipped, why it exists, docs, and more.
1. Cross-App Access (XAA): who's actually authorizing your AI agents?
Today, every time an AI agent wants to reach Datadog on a user's behalf, that user clicks through a consent screen, one person, one tool, one time, with no central record of what got approved. As agents proliferate, that model doesn't scale.
What shipped: Cross-App Access, an open protocol and the technology behind Okta's Agent SSO (GA in August 2026, with Datadog as a launch partner), is now generally available for managing AI agent access to Datadog from the Okta Admin Console.
Why it exists: XAA moves the authorization decision from the end user to the admin. An admin sets policy once in Okta, controlling which agents can reach Datadog and which users can use them, from the same console they already use for every other connected app. Users sign in through Okta and the connection simply works, no consent screen. To revoke access, an admin does it once in Okta instead of logging into Datadog and every other vendor separately.
How it works: Okta issues a short-lived token for the signed-in user, and the agent exchanges it with Datadog for access scoped to that person, not a standing API key. Set up the Datadog side first (Organization Settings > Mobile and Third-Party Access), then enable Cross-App Access on the Datadog application in Okta.
Current limits: Okta-only for now (Entra ID, Ping, and others aren't supported yet). Claude is the first supported agent, with more to follow. Requires your Okta tenant to have AI Agent Identity and A2A Connections, plus existing Okta SAML SSO to Datadog.
Shipped by: Anthony Dagneaux
Docs: Cross-App Access documentation · Okta's release note
2. AI agents can now configure and maintain log pipelines, indexes, and archives with Datadog MCP
What shipped: Through the Datadog MCP Server, AI agents can now configure and maintain log pipelines, indexes, and archives directly, not just query them.
Why it exists: Setting up and maintaining log pipeline configuration has historically been a manual task, done by a person navigating the UI or hand-writing API calls. Giving agents the ability to configure this directly means routine log management work, like adjusting a pipeline, tuning an index, or setting up an archive, can be delegated to an agent instead.
Shipped by: Nicolas Jung
Docs: Release note
3. Skills Library: teach your agents how your team works, once
What shipped: Skills Library for Datadog Bits AI agents lets you turn your team's procedures, system context, and investigation history into reusable "skills" that Bits Chat and Bits Agent Builder agents can draw on.
Why it exists: Without a shared library, every agent interaction starts from scratch, re-explaining the same context about how your systems work, what your procedures are, and what's happened before. Skills Library lets that knowledge persist and get reused across agents and workflows instead of being re-taught every time.
Shipped by: Kevin Gallardo and Amber Tunnell
Docs: Skills Library documentation
How it works:
Datadog.Skills.Library.for.Bits.AI.mp4
4. Prompt Management: stop hardcoding your LLM app's prompts
What shipped: Prompt Management for Agent Observability is now generally available. Customers can author, version, deploy, and roll back prompts directly in Datadog, and fetch them at runtime with no application redeploy.
Why it exists: Prompts have typically been hardcoded or scattered across code, notebooks, and configuration, with prompt deployment tightly coupled to the application's own deploy cycle. That makes it hard to experiment with variants, respond quickly to a regression, or know for certain what's actually running in each environment. Prompt Management decouples prompt changes from app deploys entirely: prompts become durable, versioned resources you can test, ship, and revert on their own timeline, and because multiple versions can serve side by side, you can compare them against live traffic.
How it works: Create a managed prompt from scratch or promote an existing tracked prompt, then deploy a version to an environment label from the UI in one click, or pin a specific prompt and version directly. Fetch managed prompts at runtime via the Python SDK or API (requires dd-trace-py v4.13+). Any managed prompt using standard instrumentation gets automatic trace correlation.
Shipped by: Kai Xin Tai
Docs: Prompt Management documentation
5. The OTLP Native Processing Pipeline: run upstream OpenTelemetry, keep full Datadog functionality
What shipped: The OTLP Native Processing Pipeline is now generally available. Teams can run a pure upstream OpenTelemetry Collector, with no Datadog-specific exporter or connector, and still get full Datadog logs, metrics, and APM.
Why it exists: Previously, getting full value out of Datadog from OTel data meant adding a Datadog-specific exporter or connector to your Collector config, a layer of vendor-specific configuration on top of an otherwise vendor-neutral pipeline. This removes that requirement entirely, so teams aren't locked into Datadog-specific plumbing just to get full functionality.
Shipped by: Matt Dunnam
Docs: OpenTelemetry documentation
6. RUM Exclusion Filters: define noise exclusions once, not per filter
What shipped: RUM Exclusion Filters are now generally available for RUM without Limits customers. They sit between Permanent and Custom Retention Filters: when an event matches an exclusion filter, it's never evaluated against the custom retention filters, so it can't trigger session retention.
Why it exists: Previously, excluding noisy events (bot traffic, errors triaged as not worth keeping, etc.) meant adding a negative clause inside every custom retention filter's query, one at a time, for every application. Each new filter, or any change to the exclusion list, meant editing every filter again. Exclusion Filters are defined once and apply everywhere automatically. Excluded events aren't dropped either, if another event retains the session, the excluded ones are indexed along with it.
How it works: From Digital Experience > Real User Monitoring > Manage Applications, open an application's Product Settings > Retention Filters, and add an Exclusion Filter targeting a specific event type or "All events," by tags like @geo.country or @device.type. A built-in, non-editable exclusion filter for errors triaged as "Excluded" in Error Tracking can be toggled on to avoid maintaining the same exclusions in two places. Exclusion filters are also configurable through the Public API.
Shipped by: Quentin Sellem
Docs: Public documentation · API reference
7. Capturing network payloads for Browser Tests
What shipped: Browser Tests can capture HTTP request and response payloads for Fetch and XHR requests, viewable directly from a test's results. In the product today this is labeled "Capture network payloads" (it was originally announced as "HTTP Payloads").
Why it exists: When a Browser Test fails, figuring out whether the problem is in the frontend, a backend service, or an unexpected API response usually meant switching between multiple tools, or reproducing the issue manually just to see what was actually sent and received. With payload content available directly in the test result, that investigation happens in one place.
How it works: Enable "Capture network payloads" under a Browser Test's Advanced Options, in Request Options. After the test runs, open a result, click the Resources tab, and select any Fetch or XHR resource to see its request/response headers and payload body.
Current limitations: Chrome and Edge only (no Firefox yet), Fetch/XHR only, text-based payloads only (plain text, JSON, XML, HTML), and payload bodies up to 64 KB.
Shipped by: Yasmine El Hafdi
Docs: Browser Tests setup · Test Results / Resources tab
8. Datadog joins the newly launched BUILD Foundation
What shipped: Datadog is an initial member of the newly launched BUILD Foundation, a Linux Foundation initiative, alongside ASML, Canva, EngFlow, Figma, and Spotify.
Why it exists: AI is accelerating how fast code gets written, but build and test infrastructure has to keep pace with that, and Datadog relies on Bazel to keep build and test times stable as its own codebases grow. The BUILD Foundation will invest in the Bazel ecosystem through maintainer support, better documentation, tooling integrations, and software supply chain security.
Shipped by: Jeremy Garcia
Docs: Announcement
Questions or feedback on any of these? Drop a comment below.
All reactions