Operations | Monitoring | ITSM | DevOps | Cloud

As teams rush to adopt AI, they often find themselves with conflicting workflows unique to each individual developer. To manage costs and promote good development practices, organizations need to establish Golden Paths around AI usage. AI Golden Paths are standardized flows that help developers work with agents more reliably and effectively. But how do you sift through all the possible workflows to decide what these Golden Paths should be?

Launches are high-stakes moments for product managers (PMs), but understanding how a new product or feature is performing can be difficult. Teams may lack the instrumentation they need to track performance, or they may miss defects that affect specific user segments during QA.

Teams use AI coding agents and Bits Chat to troubleshoot systems and handle complex tasks, often uncovering repetitive work worth automating. But turning those routines into workflows can still require switching tools and recreating context manually. Through the Datadog MCP Server, Workflow Automation now lets you build workflows from Bits Chat or AI coding agents like Claude Code, Cursor, and Codex.

Datadog’s 2026 State of AI Engineering report showed organizations’ LLM inputs swelling rapidly as context engineering expands. In March 2026, 69% of all input tokens in Datadog customer traces were for system prompts: internal instructions, policy definitions, and tool guidance providing context and guardrails around the user input. This suggests that most context engineering spend among Datadog customers is going toward optimizing repeating system prompts in heavily scaffolded agent systems.

Let’s say your team shipped a support agent last quarter. The launch demo went well, stakeholders were pleased, and everyone moved on. A few months later, things start to look off. Summaries of long conversations are truncated, and monitors show latency spikes on tool calls to the billing API. Your team’s first instinct is to ship fixes such as tweaking prompts or upgrading the model.

CUPED (Controlled-experiment Using Pre-Experiment Data) is a powerful tool that can reduce metric variance and help teams obtain precise experiment results with less data. However, the difference between an experiment’s CUPED-adjusted lift and raw lift can be difficult to explain, especially when an experiment uses many pre-exposure metrics and subject properties. The CUPED adjustments visualization in Datadog Experiments breaks the difference into a sequence of specific adjustments.

Developers and SREs who use Bitbucket Cloud often need to move between their source code, observability data, test results, and security findings to investigate a problem. Connecting an error or slow method to the correct repository, file, and commit takes time. Teams may also discover vulnerabilities, infrastructure misconfigurations, coverage regressions, or flaky tests only after code has progressed further through the software development life cycle, when remediation is more disruptive.

A frequently encountered issue when exploring database optimizations is proving that a proposed query rewrite is actually faster than the existing query. Often, proving this isn’t just as simple as running both queries and comparing their execution times. When your hot queries are measured in milliseconds, factors such as cache states, concurrent queries competing for CPU and I/O, and noisy neighbors can mask the true performance difference between query versions.

Some production bugs don’t show up clearly in logs or traces, and they often cannot be reproduced in a local or staging environment. When developers need more runtime detail, they typically fall back on a familiar but slow workflow: add log lines, open a pull request, wait for review and CI/CD, deploy the change, and wait for the issue to happen again. If the new logs don’t capture the right variable values or execution path, the loop starts over.