When does an AI agent use this pattern?

When the trigger described above matches the situation the agent is handling. The agent queries FusedFrames at runtime, this pattern is returned and the agent follows the recorded reasoning and steps to reach the recorded outcome.

How were the steps captured?

By the desktop app on the machine of someone who actually does this work. It records clicks, keystrokes, copy and paste, drag and drop, selected text and screen regions across PagerDuty, GitHub and Datadog, then groups them into the meaningful steps shown above.

Where does the reasoning come from?

From the operator. When the desktop app sees a decision the action alone cannot explain, it asks why in the moment. The operator's answer is recorded and becomes the reasoning attached to the pattern, so the AI agent gets the thinking and not just the steps.

What if my team handles this differently?

Capture how your team actually does it. The desktop app records what your operator does on your tools and the web app distills that into a pattern shaped by your team. Each team's library reflects their own approach rather than the example shown here.

What happens when a case looks like this pattern but does not quite fit?

The connections shown on this page link to related patterns that may match the case better. The agent can follow those edges to find a closer fit.

How does my AI agent actually call this pattern?

Through the read-only REST API or the npm CLI. Create an API key in the dashboard, choose whether it accesses all libraries or specific ones and have your agent query at runtime. The response is structured JSON ready for tool use.

Is the data shown on this page from a live customer?

No. Example libraries on this site are illustrative. Patterns in your own account are built from your team's captured actions and stay private to your workspace.

How do I build a pattern like this for my team?

Install the desktop app on the machine of the person who already does this work, ask them to handle a real case end to end, then distill the captured action into a pattern in the web app. The pattern you end up with mirrors how your team actually operates.

Resolving an incident and recording the timeline

Once metrics have been healthy for at least 15 minutes, the engineer resolves the PagerDuty incident with a complete resolution note. That note names the cause, attaches the GitHub PR numbers and Datadog dashboard URL and tags the affected service plus a root cause classification.

Tags

pagerdutyresolutionpost-mortemtaggingroot-cause

Lets your agent filter to the right pattern

Categories and tags scope the retrieval set, so your agent receives only the patterns relevant to the task instead of scanning the full library.

What and why

The observed behaviour and the reasoning behind it.

Behaviour

Once metrics have recovered, the engineer returns to the PagerDuty incident, posts a final status update naming the cause and the remediation, attaches the relevant GitHub PR numbers and the Datadog dashboard URL in the resolution note, tags the incident with the affected service and a root cause classification, then clicks Resolve. They wait at least 15 minutes after metric recovery before resolving, to allow time for the metric to flap back if the fix is not actually durable.

Reasoning

The PagerDuty resolution note is the canonical post-mortem citation. Anyone reading the incident later expects to find the suspect PR, the remediation PR and the dashboard that shows the spike and recovery in one place. Tagging with the service and the root cause classification is what powers the team's quarterly incident report, so consistency in tagging matters more than exhaustiveness. Waiting 15 minutes after recovery is the simple insurance policy against flapping incidents, which are the single most common reason a resolved page reopens within the same hour.

Gives your agent an operator's reasoning

Behaviour records the action; reasoning records the rationale. Your agent applies both to handle cases that diverge from the captured examples.

Cause and effect

What initiates this pattern and what it produces.

Trigger

The affected service's metrics have returned to baseline, the SLO burn rate has dropped below 1 and any downstream consumers have also recovered.

Outcome

The PagerDuty incident is resolved with a complete resolution note, the affected service tag and a root cause classification tag applied, and a stable 15 minute window of healthy metrics observed before the resolution.

Tells your agent when to act and what to verify

Your agent stays within the scope set by the trigger and outcome, so it doesn't extend beyond the work or finish before the outcome is met.

Standard operating procedure

Step-by-step instructions to reproduce this pattern.

Datadog

Confirm 15 minutes have elapsed since the metric returned to baseline.

Use the same monitor view used for verification. If the 15 minutes contain any threshold breaches, even brief ones, restart the timer. Flapping incidents are the most common reason the page re-fires within the hour, and 15 minutes is the empirical floor below which the team has been bitten before.

Expected: The metric graph shows a continuous 15 minute window below the alert threshold.

PagerDuty

Open the incident and click 'Add Status Update' one final time.

Write the cause and the remediation in two short sentences. Example: 'Cause: api-gateway #4892 changed the retry policy default and increased upstream pressure. Remediation: reverted via #4901, deploy completed at 14:48 UTC.'

Expected: A status update appears on the timeline with the cause and the remediation.

PagerDuty

Click the Tags field and apply the affected service tag and a root cause classification tag.

Use the team's standard tag set. Service tags follow the repository name (api-gateway, checkout-service, billing-worker). Root cause classifications are bad-deploy, infra, dependency, traffic, configuration. Stick to the standard set even if it is a slightly imperfect fit. The quarterly report depends on consistency.

Expected: The incident shows the service tag and the root cause classification tag in the sidebar.

PagerDuty

Click Resolve and complete the resolution note with PR links and the Datadog dashboard URL.

Paste the suspect PR number, the revert or hotfix PR number and the Datadog monitor URL into the resolution note. The note has a 1500 character limit on desktop and around 500 on mobile, which is why this step is done from a workstation. Anyone opening this incident in the post-mortem will look for these three links first.

Expected: The incident is in Resolved status with a resolution note containing the two PR links and the dashboard URL.

PagerDuty

Confirm the resolution event appears at the bottom of the incident timeline.

If the resolution event is missing, the click did not register. This sometimes happens when the page was reassigned earlier and the responder did not re-acquire it. Re-open and resolve from the original responder account.

Expected: The timeline ends with a Resolved event named after the responder.

Hands your agent your team's exact steps

Your agent executes the documented procedure in order, against the applications named at each step, producing consistent output across human and agent runs.

Book a demo

Related patterns

How this pattern connects to other patterns in the library.

Often previous

Verifying a rollback restored service in Datadog

Lets your agent confirm the match and its scope

Alternative patterns let your agent compare candidates and select the closest match. Previous and next patterns define position in the workflow, so the agent operates within the scope of this one.

Supporting actions

Actions that provide evidence for this pattern.

Resolved PD-PT4ZXKR with #4892, #4901 and api-gateway dashboard

Tagged PD-PT5MN8L with checkout-service and bad-deploy

Waited 17 min after metric recovery before resolving billing-worker page

Resolution note for PD-Q9HK22N: cause, remediation, 3 links

Re-resolved PD-PT5MN8L after first click did not register on reassigned page

Shows your agent the evidence behind the pattern

Each pattern is derived from captured action sequences. Your agent can reference the source actions to verify any field, so nothing it acts on is authored by hand or hallucinated.

Metadata

Timestamps and identifiers.

Evidence	Observed 33 times across 5 connections
Applications	PagerDuty, GitHub, Datadog
First seen	2 Feb 2026, 14:21
Last seen	5 May 2026, 18:54

Helps your agent rank patterns by confidence

Action count and last-seen timestamp weight each pattern by frequency and recency, so your agent selects the highest-scoring match rather than the first returned.

Questions

Frequently asked questions

Book a demo View all examples

Speak to the founder

Get a demo. Watch a live capture, then an AI agent query the result.

Ask anything. Pricing, security or integrating with your stack.

No purchase obligation

Book a call

Start capturing

Record in minutes. Install once and work as normal.

Plug AI agents in. One API call from any AI agent stack.

Refund on unused credits if you cancel