An agent for your runbook,
that can only do what the runbook says.

The runbook that reasons, within the lines you drew

A work item arrives: a customer reports slow exports. The triage is always the same. Check the export queue, check the last deploy to the export service, check whether the customer's tenant is on the big shard, and either fix the known thing or escalate with those three facts. That is a runbook with a judgement in it. A workflow cannot make the judgement. An agent can, and it can be forbidden from doing anything else.

An agent built from an admin's permissions, with instructions that say "fix it", and nobody reading what it did

How it bills. Agents built with Bits Agent Builder draw on AI Credits, the meter shared across the Bits AI family, sold on demand or in monthly bundles that reset on the first of each calendar month and do not roll over. Each agent run, manual or automatic, consumes credits, and administrators can cap credit usage for the organisation and per user. Datadog announced Bits Agent Builder as generally available at DASH 2026, and its documentation lists the Work Management integration with custom agents as in Preview. We publish no rates. The lever is how often an agent is triggered and how much it is allowed to do, which is the same lever as safety.

The configuration traps. The agent is built by an administrator and run under their permissions, so an agent designed to update work items can also delete monitors. The instructions say "resolve the issue" rather than naming the four checks and the two permitted fixes, and the agent, being helpful, finds a fifth thing to try. The connection it uses is the one from the first workflow, with the broadest role in the account. The trigger is an automation rule on every work item in the project rather than one type. The agent's actions are on the timeline, and the timeline is read by nobody. Each of these is a scope that was left open because closing it took an afternoon.

Start from a runbook that exists. Give the agent a service account, not a person. Name the approver before the first trigger.

We start with a Datadog HealthScan, read-only and fully automated, which reports the agents that exist, the connections and permissions each runs under, the automation rules that trigger them and the credits consumed. The build then runs within Managed Observability onboarding, one agent at a time, and the approvals are staffed by Critical Support.

1. Pick a runbook with a judgement in it. Not one that is a fixed sequence, which is a workflow, and not one that nobody has written down, which is a research project. A triage that an engineer does by hand, the same way, with one decision in the middle.
2. Write the instructions as steps and limits. What to check, in what order, which two actions are permitted, and the exact condition for stopping and asking. The instructions are reviewed like code, because they are the agent's behaviour.
3. Scope the data and the actions. Only the data sources the runbook reads. Only the Action Catalog actions the runbook takes, through connections with the narrowest role that works. Nothing inherited from the builder.
4. Run it under a scoped identity. An automation rule assigns the agent from a service identity whose permissions match its scope, not from whoever set up the rule.
5. Put an approver on every action beyond the safe set. Updating a work item or posting context runs unasked. Anything that changes the runtime, a ticket in another system, or customer-facing output waits for a named person. Under Critical Support that person is ours.
6. Trial it against the last month of work items. The agent is run on the items it would have triaged, its actions compared with what the engineer did, and the difference written up. Then it is triggered for real, with a credit budget and an owner.

Access is admin on the Datadog organisation for agents, connections and automation rules. The connections an agent uses are created on your accounts, by you, with us specifying the role; no credential of yours is held by us.

An agent's instructions were right for the runbook as it was in March

The runbook changes after an incident. A new action appears in the catalogue. The team that owned the approval is reorganised. Managed Observability reviews every agent every month against what it did, and Critical Support is the approver for anything it proposes in the runtime we operate.

We operate the stack. You own the product.

We build agents from our own runbooks and run them inside our own operations, under the same rule: the agent follows the steps, decides within the limits, and asks a person for everything else. An implementation partner builds the agent and leaves. A managed partner is the person it asks, and reads what it did every month. We are the second kind. The agents, their instructions and their timelines stay in your Datadog, and you can take them in-house whenever you choose.

Datadog is our proof, not our headline. Datadog certified one managed provider globally. We are it. The Powered by Datadog accreditation means Datadog's own engineers reviewed how we instrument, alert, respond and report. We are also a Datadog Advanced Partner, ISO 27001 certified and Cyber Essentials Plus certified, with offices in Cardiff, London and Dublin.

Datadog Bits Agent Builder, answered plainly