--- title: "Guild agents, now visible in Datadog" canonical: "https://www.guild.ai/blog/product/guild-agents-datadog" --- # Guild agents, now visible in Datadog - **Category:** Product - **Author:** Cory Waddingham - **Published:** Nov 11, 2026 - **Reading time:** 6 min ## You can't govern what you can't see An agent platform wouldn't be complete if your on-call team can't see what the agents are up to. With Guild's Datadog integration, now live, you can do exactly that. Agents are new hires who never clock out. They call models, hit APIs, spend real money and take real actions, around the clock. You'd never give a new hire production access without a manager and a badge log. Agents deserve the same treatment, and in a lot of engineering orgs the badge log already has a name: Datadog. When an agent slows down, loops, or starts burning through tokens at 2 a.m., the person holding the pager shouldn't have to go hunting. They should see it in the tool they already trust, right next to the services that agent touches. ## Why Datadog Walk into a typical enterprise ops team and you'll find Datadog on the big screen. It's where the dashboards live, where the monitors fire, and where years of tuned thresholds and hard-won runbooks sit. SREs have built their incident muscle memory around it, and that muscle memory is worth a lot. Getting those teams to watch agents in a separate console is a big ask. Every extra pane of glass is one more tab nobody checks when the house is on fire. New services earn trust the boring way: they show up in the monitoring everyone already uses, they behave predictably, and when they don't, they're easy to investigate. Agents should have to clear the same bar. That's the thinking behind our whole integration catalog. Developers and business users already have tools they know and love, and they've built their days around them. Agents should move into that neighborhood and learn the local customs. ## What you get: Datadog in both directions Think of it as a two-way street. You can drive either lane on its own, but they're better together. **Your agents show up in Datadog.** Turn on trace forwarding and Guild sends the OpenTelemetry traces and metrics from every agent session in your workspaces into Datadog APM. Sessions, LLM calls, latency and errors land right next to the services they touch, and Datadog computes request counts and latency from the spans for you. Spans follow the OpenTelemetry GenAI semantic conventions, and Guild tags each one with attributes your team can filter and group on: - guild.session and guild.task to pull every span from one session or one task - gen\_ai.agent.name to compare agents side by side - gen\_ai.provider.name to split LLM calls by model publisher, such as Anthropic or OpenAI When a trace looks off, grab its guild.session value and you can jump straight to the full session in Guild, where you can see what the agent was actually trying to do. **Your agents can read Datadog.** Getting your ops team visibility into what your agents are doing is one thing, but turning those agents into an extension of the team is the next level. Guild agents get a set of read-only Datadog tools, so an agent can triage an alert with the same data your on-call engineers see. It can pull up monitors, query metrics and timeseries, search and aggregate logs, and check the event stream for recent deploys. Picture the first five minutes of an incident, the part where someone is frantically opening tabs, already handled by the time a human opens their laptop. ## Already on Datadog? Here's what Guild adds If Datadog is your security camera, Guild is the lock on the door. Datadog tells you what your agents did. Guild decides what they're allowed to do in the first place. You want both, and if your teams are already building agents (or about to), the two snap together nicely. **Agents land in your existing monitoring on day one.** No new dashboards to learn and no separate console to babysit. Every Guild session flows into Datadog APM with attributes your SREs can slice by agent, task and model provider. Point a few monitors at the agent spans, and the alert routing you've spent years tuning handles agents the same way it handles everything else. **Keys stay out of agent code.** A Datadog application key carries the permissions of whoever created it. Those keys deserve the same care as any other production credential. Guild's credential proxy holds your Datadog keys server-side and injects them per request, so they never reach agent code, prompts or containers. The agent gets to use the key without ever getting to see it. **Agents can help on call without changing a thing in Datadog.** Every Datadog tool in Guild is read-only. Your triage agent can pull the monitor, the metrics behind it and the related logs. It can't create, change or mute anything, so nobody wakes up to find that an agent quietly silenced the alert it was supposed to investigate. **One control plane for all of it.** Visibility answers "what happened?" Governance answers "what was allowed, and who allowed it?" Guild gives you both, for Datadog and for every other tool your agents touch. ## Each agent gets only the operations it needs Every Guild integration is a menu of operations, and Datadog's menu has ten items today. Read-only is a solid default, but read access is still access. Logs in particular can hold far more than a monitor-checking agent has any business seeing, so Guild lets you go a level deeper. [Credential policies](https://docs.guild.ai/platform/credential-policies) let you write ALLOW and DENY rules by operation name, agent or workspace. You can also scope the Datadog credential itself to the whole account, one workspace, one member or one installed agent. Here's what that looks like for a team running three agents against the same Datadog account: - **Alert triage** explains why a monitor fired. It gets datadog\_get\_monitor, datadog\_search\_monitors and datadog\_query\_timeseries\_points, and can't touch logs or the event stream. - **Log investigator** digs into errors during an incident. It gets datadog\_search\_logs and datadog\_aggregate\_logs, and can't touch monitors or metrics. - **Release reporter** summarizes what shipped and what alerted this week. It gets datadog\_search\_events, and can't touch logs, metrics or monitors. Three agents, three keyrings. Each one sees exactly the slice of Datadog its job calls for. If a prompt goes sideways or a tool response tries to talk an agent into wandering off, it still can't open a door it was never handed the key to. And since every one of those calls is traced, you can check that in Datadog yourself instead of taking our word for it. ## Get started The first lane takes a Datadog API key and about two minutes: 1. In Guild, open **Access & setup \> Observability**. In an organization, this step takes an admin. 2. Choose **Datadog** as the provider and pick your Datadog site. 3. Paste your Datadog API key and click **Save**. 4. Run a session, then find its spans in Datadog APM by guild.session. Ready for the second lane? Connect Datadog under **Access & setup \> Credentials** with an API key, an application key and your site, then hand the tools to an agent. The [Datadog integration guide](https://docs.guild.ai/integrations/datadog) covers both paths, the supported sites and the usual gotchas. Datadog joins Splunk, New Relic and Google Logging on the observability side of the [Guild catalog](https://docs.guild.ai/integrations), which is now over 70 integrations strong. The goal hasn't changed: connecting agents to your knowledge, your processes and your tools should be trivial, and keeping them inside the lines should be just as easy. Now you can watch them stay there, right in Datadog. Want to see it live? [Book a demo](https://guild-ai.cal.com/gtm/meeting-with-guild.ai), and bring your gnarliest alert. ## Watch your agents in Datadog this week See how Guild forwards agent traces to Datadog and gives your agents scoped, read-only Datadog tools, all inside the Guild agent control plane. [See Guild in Action →](https://guild-ai.cal.com/gtm/meeting-with-guild.ai)