Try it free

Run agents in Workflows

  • Latest Dynatrace
  • How-to guide
  • 3-min read
  • Published Oct 12, 2026

Dynatrace Intelligence integration for Workflows Workflows allows you to use agentic workflow actions to actively react to changes and analyze real-time data in your environment by using Dynatrace agentic tools.

The Run agent workflow action is audience-agnostic. This means that the Run agent is customizable and can be adjusted to your needs. By using this action, you can use ready-made agents and customize the investigation by specifying:

  • Trigger type: what triggers the investigation.
  • Destination: where the output should be sent (for example, Slack or an E-mail).

Prerequisites

To use Dynatrace Intelligence, you need to ensure that your DPS license includes AI Units capabilities.

To use the Dynatrace Intelligence agentic AI workflow action, ensure that you have the following permissions:

  • ai:operator:execute
  • mcp-gateway:servers:invoke
  • mcp-gateway:servers:read
  • document:documents:read

Depending on the tools you use, you might need additional permissions. For more information about tool-specific permissions, see Server and server tools.

Licensing

Starting with Dynatrace version 1.347+, using Dynatrace Intelligence AI outside the Assist UI, Dashboards Dashboards, and Notebooks Notebooks is subject to license consumption according to your existing licensing agreement and requires a DPS license that includes AI Units capabilities.

If you are subscribed to any non-DPS licensing model or missing the required capability, you are no longer able to use agentic AI workflow actions.

Limits

Standard usage limits for Agentic and generative AI are also applied to Dynatrace Intelligence:

ItemMaximum limit

Individual user requests

25 requests per 15 minutes

All user requests across the environment

60 requests per 15 minutes

Duration of request to operator processing

120 seconds

If you schedule the automatic workflow execution to run frequently, all other Dynatrace Intelligence agentic and generative AI functionality might be throttled due to reaching the request limit. If you do run into the usage limit, please reach out to your CSM.

Set up a Run agent action

To create a workflow with the Run agent action

  1. In Dynatrace, go to Workflows Workflows.
  2. Select Workflow to create a new workflow.
  3. Choose a workflow trigger that will prompt the execution of the workflow.
  4. Select Add task.
  5. Type Dynatrace Intelligence into the search field or select Dynatrace Intelligence > Run agent.
  6. Configure the action:
    • In AI Agent, select an agent you want to use when executing your prompt. Currently, you can choose SRE Agent from Ready-made agents.

      Once you select an agent, you're able to review its functionality in Agent description.

    • In the Prompt field, enter your question or request. You can also add specific formatting instructions to better suit your use case.

      You can enter a maximum of 10,000 characters in this field.

    • Optional In the Additional context field, provide any additional context (for example, a code snippet or supplementary information about a problem or event) you want Dynatrace Intelligence agentic AI to reference when executing your prompt. You can reference an output from a previous workflow action in this field.

      You can enter a maximum of 200,000 characters in this field.

  7. Optional Add any additional workflow action before or after the Dynatrace Intelligence agentic AI action to support your use case.
  8. Select Save.
  9. Select Run to execute the workflow.

Use cases

Perform a root-cause analysis on any problem

You can configure the SRE Agent to investigate new triggered problems across logs, traces, and metrics and automatically add problem annotations with the investigation results.

  1. In Dynatrace, go to Workflows Workflows.
  2. Select Workflow to create a new workflow.
  3. Set the workflow trigger to Problem trigger. Configure the trigger as needed:
    • Set Event state to active.
    • Choose one or more Event categories needed for your use case (for example, Availability and Error).
    • Optional Set Severity and add Entity tags to further filter incoming problems.
    • In Additional custom filter, enter dt.davis.is_duplicate == false to avoid overalerting.
  4. Select Add task > Run agent.
  5. Configure the action:
    • In AI Agent, select SRE Agent from Ready-made agents.

      Once you select an agent, you're able to review its functionality in Agent description.

    • In the Prompt field, enter your question or request. For example:
      Run a root cause analysis for problem with the id {{event()["display_id"]}}.
      Work outwards from the affected entities: their error and warning logs, the distributed traces of any service among them for the failing or slow span, the triggering metric's own time series where a threshold fired rather than the alert description alone, and how often this same alert name has already fired against the same entity in the last 24-48h.
      Judge what kind of problem this is and whether it needs attention. Synthetic, deliberately generated and test-origin alerts are noise and should be called out as such - a high, steady recurrence with no correlating logs is itself evidence of that. Where the evidence does not support a call either way, say so plainly and name what you checked, rather than offering a plausible guess.
      • You can add specific formatting instructions to better suit your use case. For example:
        Answer in this structure:
        **Verdict** - one short, self-contained statement the reader can act on: what kind of problem this is, what is happening, to which entity, and since when. One sentence.
        ## Root Cause Reasoning
        Name the root cause, then reason it through: the chain from that cause to the symptom the alert fired on, and why it happened when it did. Two to four sentences. Follow the system's causality, not your own train of thought.
        ## Recommendations
        The remediating measures you recommend.
        ## Evidence and findings
        The facts a reader needs to accept or challenge the verdict - for each, the entity it concerns, the value or timestamp behind it, and a link to its source. Whatever shaped the verdict belongs here: recurrence counts with the related problem ids, or a shared entity, cluster, namespace, naming, tag or alerting profile.
        ## Additional instructions
        - Your response is parsed programmatically. It MUST start with the exact three characters `**V` (the opening of `**Verdict**`) as the very first characters of your output - no text, whitespace, reasoning, or planning statement may come before it. A response that starts with anything else fails this task outright.
        - Do not include any planning, confirmation, or narration sentence anywhere in the response - not before the verdict, not between sections. Examples of what this bans, verbatim: "I now have all the evidence needed", "Let me compile the findings", "The recurrence pattern is definitive", "Writing the report". If a sentence like this forms in your reasoning, discard it before responding - it must never reach the output.
        - Never comment on your own evidence. Drop phrases such as "I have all the data I need" or "the recurrence data is clear".
        - Never name your tools. No mention of the queries, files, commands or search results behind a finding.
        - Ground every finding in data you retrieved. Where you cannot point to that data, do not make the statement.
        - State every fact once, in the section the structure assigns to it.
        - Use at most 20 tool calls; the backend refuses more and a run that reaches the limit returns nothing at all, so stop investigating and write the report while calls remain - a short report with an open verdict beats running out.
        - Link source data with relative paths so it resolves on the current environment: an entity as [CheckDestination](/ui/entity/SERVICE-907DC3F55716BCC9), a problem as [P-2609087](/ui/apps/dynatrace.davis.problems/problem/P-2609087), logs as [Logs](/ui/apps/dynatrace.logs), Kubernetes as [Kubernetes](/ui/apps/dynatrace.kubernetes).
        - Where you reference an alert configuration, link where it is changed rather than the alert itself: [centralized alert management](/ui/apps/dynatrace.settings/settings/alerts).
        - Never invent an ID, and never write an absolute URL containing a host name. Only link an ID you actually retrieved.
        - Keep tables to three columns at most, and use lists, code blocks and iconography to make findings scannable.
        - Keep the report under 800 words.
        - Close with a finished report. Never offer to continue and never ask a question back; the report is read after the run has ended.

      You can enter a maximum of 10,000 characters in this field.

    • Optional In the Additional context field, provide any additional context (for example, a code snippet or a supplementary information about a problem or event) you want Dynatrace Intelligence agentic AI to reference when executing your prompt. You can reference an output from a previous workflow action in this field.

      You can enter a maximum of 200,000 characters in this field.

  6. Select Add task > Annotate and link.
  7. Fill in the required fields:
    • In the Problem id, enter {{event()["event.id"]}} to attach the annotation to the investigated problem.
    • In the Annotation name, enter SRE Agent — Root cause analysis.
    • In the Description, enter {{ result('call_sre_agent')['text'] }} to send SRE Agent action result as the annotation text.
    • In the Annotation source, enter SRE Agent.
    • Optional In the Annotation id, enter {{event()["event.id"]}} to use the problem ID as an annotation ID. If you leave the field empty, a random id is generated.

      If the same annotation id is used multiple times, the existing annotation is updated with the latest information instead of creating a new one.

  8. Optional Add any additional workflow action before or after the Dynatrace Intelligence agentic AI action to support your use case.
  9. Select Save.
  10. Select Run to execute the workflow.

Automatically enrich incident tickets

You can configure the SRE Agent to automatically add details to the new ServiceNow or JIRA ticket after investigating a new problem, saving the time your team spends on the initial investigation.

  1. In Dynatrace, go to Workflows Workflows.

  2. Select Workflow to create a new workflow.

  3. Set the workflow trigger to Problem trigger. Configure the trigger as needed:

    • Set Event state to active.
    • Choose one or more Event categories needed for your use case. For example, Availability and Error.
    • Optional Set Severity and add Entity tags to further filter incoming problems.
    • In Additional custom filter, enter dt.davis.is_duplicate == false to avoid overalerting.
  4. Select Add task > Run agent.

  5. Configure the action:

    • In AI Agent, select SRE Agent from Ready-made agents.

      Once you select an agent, you're able to review its functionality in Agent description.

    • In the Prompt field, enter your question or request. For example:
      Run a root cause analysis for problem with the id {{event()["display_id"]}}.
      Work outwards from the affected entities: their error and warning logs, the distributed traces of any service among them for the failing or slow span, the triggering metric's own time series where a threshold fired rather than the alert description alone, and how often this same alert name has already fired against the same entity in the last 24-48h.
      Judge what kind of problem this is and whether it needs attention. Synthetic, deliberately generated and test-origin alerts are noise and should be called out as such - a high, steady recurrence with no correlating logs is itself evidence of that. Where the evidence does not support a call either way, say so plainly and name what you checked, rather than offering a plausible guess.
      • You can add specific formatting instructions to better suit your use case. For example:
        Answer in this structure:
        **Verdict** - one short, self-contained statement the reader can act on: what kind of problem this is, what is happening, to which entity, and since when. One sentence.
        ## Root Cause Reasoning
        Name the root cause, then reason it through: the chain from that cause to the symptom the alert fired on, and why it happened when it did. Two to four sentences. Follow the system's causality, not your own train of thought.
        ## Recommendations
        The remediating measures you recommend.
        ## Evidence and findings
        The facts a reader needs to accept or challenge the verdict - for each, the entity it concerns, the value or timestamp behind it, and a link to its source. Whatever shaped the verdict belongs here: recurrence counts with the related problem ids, or a shared entity, cluster, namespace, naming, tag or alerting profile.
        ## Additional instructions
        - Your response is parsed programmatically. It MUST start with the exact three characters `**V` (the opening of `**Verdict**`) as the very first characters of your output - no text, whitespace, reasoning, or planning statement may come before it. A response that starts with anything else fails this task outright.
        - Do not include any planning, confirmation, or narration sentence anywhere in the response - not before the verdict, not between sections. Examples of what this bans, verbatim: "I now have all the evidence needed", "Let me compile the findings", "The recurrence pattern is definitive", "Writing the report". If a sentence like this forms in your reasoning, discard it before responding - it must never reach the output.
        - Never comment on your own evidence. Drop phrases such as "I have all the data I need" or "the recurrence data is clear".
        - Never name your tools. No mention of the queries, files, commands or search results behind a finding.
        - Ground every finding in data you retrieved. Where you cannot point to that data, do not make the statement.
        - State every fact once, in the section the structure assigns to it.
        - Use at most 20 tool calls; the backend refuses more and a run that reaches the limit returns nothing at all, so stop investigating and write the report while calls remain - a short report with an open verdict beats running out.
        - Link source data with relative paths so it resolves on the current environment: an entity as [CheckDestination](/ui/entity/SERVICE-907DC3F55716BCC9), a problem as [P-2609087](/ui/apps/dynatrace.davis.problems/problem/P-2609087), logs as [Logs](/ui/apps/dynatrace.logs), Kubernetes as [Kubernetes](/ui/apps/dynatrace.kubernetes).
        - Where you reference an alert configuration, link where it is changed rather than the alert itself: [centralized alert management](/ui/apps/dynatrace.settings/settings/alerts).
        - Never invent an ID, and never write an absolute URL containing a host name. Only link an ID you actually retrieved.
        - Keep tables to three columns at most, and use lists, code blocks and iconography to make findings scannable.
        - Keep the report under 800 words.
        - Close with a finished report. Never offer to continue and never ask a question back; the report is read after the run has ended.
        Format the response for direct insertion into a ticket description field - no markdown tables, plain headers only.

      You can enter a maximum of 10,000 characters in this field.

    • Optional In the Additional context field, provide any additional context (for example, a code snippet or a supplementary information about a problem or event) you want Dynatrace Intelligence agentic AI to reference when executing your prompt. You can reference an output from a previous workflow action in this field.

      You can enter a maximum of 200,000 characters in this field.

  6. Select Add task > Run JavaScript.

    You need to provide a connector and credentials to run this action.

  7. In the Input tab, enter the following:

    import { executionsClient } from "@dynatrace-sdk/client-automation";
    export default async function ({ execution_id }) {
    const task = await executionsClient.getTaskExecution({ executionId: execution_id, id: "call_sre_agent" });
    const text = task.result?.text ?? "";
    await fetch("https://<your-instance>.service-now.com/api/now/table/incident/<sys_id>", {
    method: "PATCH",
    headers: { "Authorization": `Basic ${credentialVaultToken}`, "Content-Type": "application/json" },
    body: JSON.stringify({ work_notes: text }),
    });
    }

    You can change https://<your-instance>.service-now.com/api/now/table/incident/<sys_id> to any other ticketing system you're using.

  8. Optional Add any additional workflow action before or after the Dynatrace Intelligence agentic AI action to support your use case.

  9. Select Save.

  10. Select Run to execute the workflow.

Notify on-call teams

You can configure the SRE Agent to notify the on-call team members about new problems by sending the message to the chosen app, such as Slack or Teams.

  1. In Dynatrace, go to Workflows Workflows.

  2. Select Workflow to create a new workflow.

  3. Set the workflow trigger to Problem trigger. Configure the trigger as needed:

    • Set Event state to active.
    • Choose one or more Event categories needed for your use case. For example, Availability and Error.
    • Optional Set Severity and add Entity tags to further filter incoming problems.
    • In Additional custom filter, enter dt.davis.is_duplicate == false to avoid overalerting.
  4. Select Add task > Run agent.

  5. Configure the action:

    • In AI Agent, select SRE Agent from Ready-made agents.

      Once you select an agent, you're able to review its functionality in Agent description.

    • In the Prompt field, enter your question or request. For example:
      Run a root cause analysis for problem with the id {{event()["display_id"]}}.
      Work outwards from the affected entities: their error and warning logs, the distributed traces of any service among them for the failing or slow span, the triggering metric's own time series where a threshold fired rather than the alert description alone, and how often this same alert name has already fired against the same entity in the last 24-48h.
      Judge what kind of problem this is and whether it needs attention. Synthetic, deliberately generated and test-origin alerts are noise and should be called out as such - a high, steady recurrence with no correlating logs is itself evidence of that. Where the evidence does not support a call either way, say so plainly and name what you checked, rather than offering a plausible guess.
      • You can add specific formatting instructions to better suit your use case. For example:
        Answer in this structure:
        **Verdict** - one short, self-contained statement the reader can act on: what kind of problem this is, what is happening, to which entity, and since when. One sentence.
        ## Root Cause Reasoning
        Name the root cause, then reason it through: the chain from that cause to the symptom the alert fired on, and why it happened when it did. Two to four sentences. Follow the system's causality, not your own train of thought.
        ## Recommendations
        The remediating measures you recommend.
        ## Evidence and findings
        The facts a reader needs to accept or challenge the verdict - for each, the entity it concerns, the value or timestamp behind it, and a link to its source. Whatever shaped the verdict belongs here: recurrence counts with the related problem ids, or a shared entity, cluster, namespace, naming, tag or alerting profile.
        ## Additional instructions
        - Your response is parsed programmatically. It MUST start with the exact three characters `**V` (the opening of `**Verdict**`) as the very first characters of your output - no text, whitespace, reasoning, or planning statement may come before it. A response that starts with anything else fails this task outright.
        - Do not include any planning, confirmation, or narration sentence anywhere in the response - not before the verdict, not between sections. Examples of what this bans, verbatim: "I now have all the evidence needed", "Let me compile the findings", "The recurrence pattern is definitive", "Writing the report". If a sentence like this forms in your reasoning, discard it before responding - it must never reach the output.
        - Never comment on your own evidence. Drop phrases such as "I have all the data I need" or "the recurrence data is clear".
        - Never name your tools. No mention of the queries, files, commands or search results behind a finding.
        - Ground every finding in data you retrieved. Where you cannot point to that data, do not make the statement.
        - State every fact once, in the section the structure assigns to it.
        - Use at most 20 tool calls; the backend refuses more and a run that reaches the limit returns nothing at all, so stop investigating and write the report while calls remain - a short report with an open verdict beats running out.
        - Link source data with relative paths so it resolves on the current environment: an entity as [CheckDestination](/ui/entity/SERVICE-907DC3F55716BCC9), a problem as [P-2609087](/ui/apps/dynatrace.davis.problems/problem/P-2609087), logs as [Logs](/ui/apps/dynatrace.logs), Kubernetes as [Kubernetes](/ui/apps/dynatrace.kubernetes).
        - Where you reference an alert configuration, link where it is changed rather than the alert itself: [centralized alert management](/ui/apps/dynatrace.settings/settings/alerts).
        - Never invent an ID, and never write an absolute URL containing a host name. Only link an ID you actually retrieved.
        - Keep tables to three columns at most, and use lists, code blocks and iconography to make findings scannable.
        - Keep the report under 800 words.
        - Close with a finished report. Never offer to continue and never ask a question back; the report is read after the run has ended.
        Keep the response under 200 words and lead with the Verdict - this is read in a chat channel, not a ticket.

      You can enter a maximum of 10,000 characters in this field.

    • Optional In the Additional context field, provide any additional context (for example, a code snippet or a supplementary information about a problem or event) you want Dynatrace Intelligence agentic AI to reference when executing your prompt. You can reference an output from a previous workflow action in this field.

      You can enter a maximum of 200,000 characters in this field.

  6. Select Add task > Run JavaScript.

    You need to provide a Slack webhook or Teams connector to run this action.

  7. In the Input tab, enter the following:

    import { executionsClient } from "@dynatrace-sdk/client-automation";
    export default async function ({ execution_id }) {
    const task = await executionsClient.getTaskExecution({ executionId: execution_id, id: "call_sre_agent" });
    const text = task.result?.text ?? "";
    await fetch(slackWebhookUrl, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ text }),
    });
    }

    Change slackWebhookUrl to your Slack webhook or Teams connector.

  8. Optional Add any additional workflow action before or after the Dynatrace Intelligence agentic AI action to support your use case.

  9. Select Save.

  10. Select Run to execute the workflow.

Schedule fleet health digest

You can configure the SRE Agent to use your investigation logic configuration for all problems detected during the last n days and prepare a digest, then save it to a [Showcase] Weekly Fleet Health Digest notebook.

  1. In Dynatrace, go to Workflows Workflows.

  2. Select Workflow to create a new workflow.

  3. Set the workflow trigger to Cron schedule trigger. Configure the trigger as needed:

    • Set Cron expression to 0 8 * * 1 to run the investigation every 7 days.
    • Set Timezone to your preferred timezone.
  4. Select Add task > Run agent.

  5. Configure the action:

    • In AI Agent, select SRE Agent from Ready-made agents.

      Once you select an agent, you're able to review its functionality in Agent description.

    • In the Prompt field, enter your question or request. For example:
      Summarize the last 7 days of Davis problems across this environment using your available tools to list and investigate recent problems.
      Group findings by category (AVAILABILITY, ERROR, SLOWDOWN, RESOURCE_CONTENTION, CUSTOM_ALERT). For each category, name the most frequently recurring root-cause entities and judge whether the pattern looks like a real, worsening issue or recurring noise.
      • You can add specific formatting instructions to better suit your use case. For example:
        Answer in this structure:
        **Verdict** - one sentence: is the fleet healthier, worse, or unchanged versus a typical week.
        ## Highlights
        The 3-5 most notable findings from the week, each with the affected entity and a one-line reason it matters.
        ## By category
        A short paragraph per problem category present this week.
        ## Recommendations
        Concrete next steps, if any.
        This is a weekly digest, not a single-incident investigation - there is no triggering problem id, do not reference one.

      You can enter a maximum of 10,000 characters in this field.

    • Optional In the Additional context field, provide any additional context (for example, a code snippet or a supplementary information about a problem or event) you want Dynatrace Intelligence agentic AI to reference when executing your prompt. You can reference an output from a previous workflow action in this field.

      You can enter a maximum of 200,000 characters in this field.

  6. Select Add task > Run JavaScript.

  7. In the Input tab, enter the following:

    import { documentsClient } from "@dynatrace-sdk/client-document";
    import { executionsClient } from "@dynatrace-sdk/client-automation";
    const DIGEST_DOC_ID = "614763ae-abfe-4a16-82c1-1a2a4108fc9d";
    export default async function ({ execution_id }) {
    const task = await executionsClient.getTaskExecution({ executionId: execution_id, id: "call_sre_agent" });
    const text = task.result?.text ?? "_Agent returned no output this run._";
    const doc = await documentsClient.getDocument({ id: DIGEST_DOC_ID });
    const content = await doc.content.get("json");
    const timestamp = new Date().toISOString();
    content.sections[0].markdown = `# [Showcase] Weekly Fleet Health Digest\n\n_Last updated: ${timestamp}_\n\n${text}`;
    await documentsClient.updateDocument({
    id: DIGEST_DOC_ID,
    optimisticLockingVersion: doc.metadata.version,
    body: { name: doc.metadata.name, content: new Blob([JSON.stringify(content)], { type: "application/json" }) },
    });
    }
  8. Optional Add any additional workflow action before or after the Dynatrace Intelligence agentic AI action to support your use case.

  9. Select Save.

  10. Select Run to execute the workflow.

Detect and triage recurring alerts and noise

You can configure the SRE Agent to detect problems with high recurrence or problems open for a prolonged time and investigate the noise, then provide suggestions on reducing the number or recurring alerts in the problem annotation.

  1. In Dynatrace, go to Workflows Workflows.
  2. Select Workflow to create a new workflow.
  3. Set the workflow trigger to Problem trigger. Configure the trigger as needed:
    • Set Event state to active.
    • Choose one or more Event categories needed for your use case. For example, Availability and Error.
    • Optional Set Severity and add Entity tags to further filter incoming problems.
    • Set Minimum duration to 15 minutes or longer.
    • In Initial root cause analysis, turn on Wait for root cause analysis.
    • In Additional custom filter, enter dt.davis.is_duplicate == false to avoid overalerting.
  4. Select Add task > Run agent.
  5. Configure the action:
    • In AI Agent, select SRE Agent from Ready-made agents.

      Once you select an agent, you're able to review its functionality in Agent description.

    • In the Prompt field, enter your question or request. For example:
      Run a root cause analysis for problem with the id {{event()["display_id"]}}.
      Work outwards from the affected entities: their error and warning logs, the distributed traces of any service among them for the failing or slow span, the triggering metric's own time series where a threshold fired rather than the alert description alone, and how often this same alert name has already fired against the same entity in the last 24-48h.
      Judge what kind of problem this is and whether it needs attention. Synthetic, deliberately generated and test-origin alerts are noise and should be called out as such - a high, steady recurrence with no correlating logs is itself evidence of that. Where the evidence does not support a call either way, say so plainly and name what you checked, rather than offering a plausible guess.
      • You can add specific formatting instructions to better suit your use case. For example:
        Answer in this structure:
        **Verdict** - one short, self-contained statement the reader can act on: what kind of problem this is, what is happening, to which entity, and since when. One sentence.
        ## Root Cause Reasoning
        Name the root cause, then reason it through: the chain from that cause to the symptom the alert fired on, and why it happened when it did. Two to four sentences. Follow the system's causality, not your own train of thought.
        ## Recommendations
        The remediating measures you recommend.
        ## Evidence and findings
        The facts a reader needs to accept or challenge the verdict - for each, the entity it concerns, the value or timestamp behind it, and a link to its source. Whatever shaped the verdict belongs here: recurrence counts with the related problem ids, or a shared entity, cluster, namespace, naming, tag or alerting profile.
        ## Additional instructions
        - Your response is parsed programmatically. It MUST start with the exact three characters `**V` (the opening of `**Verdict**`) as the very first characters of your output - no text, whitespace, reasoning, or planning statement may come before it. A response that starts with anything else fails this task outright.
        - Do not include any planning, confirmation, or narration sentence anywhere in the response - not before the verdict, not between sections. Examples of what this bans, verbatim: "I now have all the evidence needed", "Let me compile the findings", "The recurrence pattern is definitive", "Writing the report". If a sentence like this forms in your reasoning, discard it before responding - it must never reach the output.
        - Never comment on your own evidence. Drop phrases such as "I have all the data I need" or "the recurrence data is clear".
        - Never name your tools. No mention of the queries, files, commands or search results behind a finding.
        - Ground every finding in data you retrieved. Where you cannot point to that data, do not make the statement.
        - State every fact once, in the section the structure assigns to it.
        - Use at most 20 tool calls; the backend refuses more and a run that reaches the limit returns nothing at all, so stop investigating and write the report while calls remain - a short report with an open verdict beats running out.
        - Link source data with relative paths so it resolves on the current environment: an entity as [CheckDestination](/ui/entity/SERVICE-907DC3F55716BCC9), a problem as [P-2609087](/ui/apps/dynatrace.davis.problems/problem/P-2609087), logs as [Logs](/ui/apps/dynatrace.logs), Kubernetes as [Kubernetes](/ui/apps/dynatrace.kubernetes).
        - Where you reference an alert configuration, link where it is changed rather than the alert itself: [centralized alert management](/ui/apps/dynatrace.settings/settings/alerts).
        - Never invent an ID, and never write an absolute URL containing a host name. Only link an ID you actually retrieved.
        - Keep tables to three columns at most, and use lists, code blocks and iconography to make findings scannable.
        - Keep the report under 800 words.
        - Close with a finished report. Never offer to continue and never ask a question back; the report is read after the run has ended.

      You can enter a maximum of 10,000 characters in this field.

    • Optional In the Additional context field, provide any additional context (for example, a code snippet or a supplementary information about a problem or event) you want Dynatrace Intelligence agentic AI to reference when executing your prompt. You can reference an output from a previous workflow action in this field.

      You can enter a maximum of 200,000 characters in this field.

  6. Select Add task > Annotate and link.
  7. Fill in the required fields:
    • In the Problem id, enter {{event()["event.id"]}} to attach the annotation to the investigated problem.
    • In the Annotation name, enter SRE Agent — Root cause analysis.
    • In the Description, enter {{ result('call_sre_agent')['text'] }} to send SRE Agent action result as the annotation text.
    • In the Annotation source, enter SRE Agent.
    • Optional In the Annotation id, enter {{event()["event.id"]}} to use the problem ID as an annotation ID. If you leave the field empty, a random id is generated.

      If the same annotation id is used multiple times, the existing annotation is updated with the latest information instead of creating a new one.

  8. Optional Add any additional workflow action before or after the Dynatrace Intelligence agentic AI action to support your use case.
  9. Select Save.
  10. Select Run to execute the workflow.

Related topics

  • Workflows
  • Dynatrace Intelligence agentic and generative AI overview
  • Dynatrace Intelligence AI integrations
  • Dynatrace MCP server
  • Agentic workflows
Related tags
Dynatrace PlatformGenerative and agentic AI for Workflows