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 GitHub, 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 if a case looks like this pattern but does not quite fit?

The pattern is linked to 1 alternative. The agent can follow the connections shown on this page to a related pattern that matches the case more closely.

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.

Rolling back by reverting the merge commit

With the suspect PR identified, the engineer uses GitHub's Revert button to generate a clean revert PR prefixed [hotfix]. The revert PR is reviewed, merged and deployed, then a comment on the original PR explains the revert and the next steps.

Tags

githubrollbackreverthotfixmerge-commit

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

With a suspect PR identified, the engineer uses GitHub's Revert button on the original PR to generate a clean revert PR, prefixes the title with [hotfix], requests review from the original PR author and one other on-call engineer, then merges only after CI completes and the deployment finishes. They leave a comment on the original PR explaining the revert rather than closing it.

Reasoning

GitHub's Revert button creates a revert PR with the proper merge commit graph linkage, which keeps the audit trail clean and allows a future revert of the revert if the team decides to roll forward later. Doing the same change with a local git revert and a manual PR works but loses the linkage in GitHub's UI. The [hotfix] prefix is a team convention that tells the deploy pipeline to use the abridged test suite, which shaves around 18 minutes off CI. Leaving the original PR open with a comment rather than closing it preserves the discussion thread for the post-mortem and signals that a forward fix is welcome.

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 engineer has identified a single suspect PR as the cause of the incident and has decided that reverting the merge is safer than shipping a forward fix.

Outcome

A revert PR has been merged to the affected service's main branch, the deploy has completed and the original PR remains open with a comment linking the revert and explaining the next steps.

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.

GitHub

On the suspect PR's main page, scroll to the merged status banner near the bottom and click 'Revert'.

The Revert button only appears on PRs that were merged using the Merge or Squash strategy and only on the default branch. If the PR was merged to a release branch or rebased, the button is absent and you will need to fall back to a manual git revert.

Expected: GitHub creates a new branch named revert-<n>-<original-branch> and opens the new PR creation page pre-populated with the inverse diff.

GitHub

Edit the PR title to prefix it with [hotfix] and reference the PagerDuty incident ID in the body.

[hotfix] is the convention that triggers the deploy pipeline's abridged test suite. The PD incident ID in the body is the citation that links this revert PR to the post-mortem. Example title: '[hotfix] Revert #4892, retry policy regression on api-gateway'.

Expected: The revert PR title starts with [hotfix] and the body links the PagerDuty incident.

GitHub

Request review from the original PR author and from one other engineer on the on-call rotation.

The original author understands the change best and can confirm the revert is the correct shape. The second on-call reviewer adds a check on a sleep deprived 2am decision. Avoid requesting from the wider team for a hotfix, parallel reviewers slow the merge.

Expected: Two reviewers are requested on the revert PR with their avatars in the sidebar.

GitHub

Wait for CI to complete on the revert PR.

Even with the [hotfix] abridged suite, the deploy gating tests must pass. Skipping CI on a revert is a regular cause of compounding incidents because the revert itself can fail to build or to run migrations in reverse. If CI fails on the revert, stop and switch to the forward fix pattern.

Expected: All required checks on the revert PR are green.

GitHub

Merge the revert PR using the 'Merge' button, not Squash.

Merge preserves the revert commit's link to the original merge commit, which the GitHub UI uses to render the revert relationship on both PRs. Squash flattens that link and the audit trail becomes harder to follow in the post-mortem.

Expected: The revert PR is merged to the default branch and the deploy pipeline has started.

GitHub

Wait for the deploy to complete and the new release tag to appear on the Releases page.

Do not close the PagerDuty incident yet. Merging the revert is not the same as the revert reaching production. The deploy can fail, the rollout can stall and the page can re-fire. Wait for the green checkmark on the new release before declaring success.

Expected: The Releases page shows a new release tag for the revert with a green deploy status.

GitHub

Open the original PR and post a comment explaining the revert and the path forward.

Example: 'Reverted by #4901 due to PD-PT4ZXKR. Will reopen for forward fix once we understand why the new retry policy caused a 5xx spike on api-gateway.' Leave the original PR open. Closing it removes it from the team's followup list and the forward fix loses its origin.

Expected: The original PR has a new comment with the revert PR link and the original PR remains in Open status.

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

Identifying the suspect PR with GitHub Compare

Alternative to

Shipping a forward fix instead of rolling back

Often next

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.

Reverted api-gateway #4892 via #4901, [hotfix] tag, deploy green

Revert PR for checkout-service #5021 merged, original kept open

Reverted billing-worker #3814 with merge commit graph intact

Posted forward-fix note on api-gateway #4892 after revert

Requested review on revert from #2211 author and Marco for second pair

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 19 times across 4 connections
Applications	GitHub
First seen	2 Feb 2026, 13:24
Last seen	5 May 2026, 18:09

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