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 Zendesk, 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.

Reproducing a customer-reported bug on a staging tenant

When a Zendesk ticket is triaged as a Bug Report, the support rep walks the customer's repro steps on a staging tenant whose plan tier matches the customer's. They capture screenshot or Loom evidence in an internal note if the bug reproduces, or ask the customer for the missing details using a saved macro after roughly ten minutes.

Tags

zendeskreproductionstagingloomevidence

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

When a Zendesk ticket has been triaged as a Bug Report, the support rep reads the customer's reproduction steps, picks a staging tenant whose plan tier matches the customer's plan and walks through the steps in the same order. If the bug reproduces, they capture either a screenshot or a Loom recording (Loom for anything timing-related or interactive, screenshot otherwise) and paste the evidence into a Zendesk internal note. If the bug does not reproduce after roughly ten minutes, they stop and ask the customer for the missing details (browser, exact URL, tenant ID, time of last successful attempt) using a saved macro rather than guessing.

Reasoning

Reproducing a bug before escalating is the single biggest filter the team has against creating noisy Linear issues. Roughly two reports in five turn out to be either user error, a feature on the customer's plan that they have not enabled or a third-party outage outside of the product's control. Matching the customer's plan tier matters because Pro and Enterprise tenants have different feature flags and the bug often only exists on one of them. The ten-minute cap exists because reproduction rabbit holes consume hours and the right move when the steps are vague is to ask for more information, not guess.

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

A Zendesk ticket has been triaged as Bug Report and the support rep is about to decide whether to escalate.

Outcome

The ticket has an internal note that either confirms the bug with evidence (screenshot or Loom) on a matching staging tenant, or has a polite request to the customer for the specific missing details needed to repro.

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.

Zendesk

Open the ticket and read the customer's reproduction steps in full. Note the browser, device, plan tier and tenant ID if specified.

If the customer mentions a specific time ('this happened at 14:32 BST yesterday'), copy that detail into a working note. The time often becomes critical when correlating to engineering logs later.

Expected: You have the customer's repro steps and the environmental details needed to choose a staging tenant.

Zendesk

Pick the staging tenant whose plan tier matches the customer (Pro vs Enterprise) and log in as the matching role (admin, member, viewer).

Feature flags differ between Pro and Enterprise. A bug that exists on Pro will silently not exist on Enterprise (or vice versa) and reproducing on the wrong tier is the same as not reproducing at all.

Expected: You are logged into a staging tenant that matches the customer's plan and role.

Zendesk

Walk through the customer's repro steps in the same order. If any step is ambiguous after one minute of trying, stop and skip to step 6.

Vague steps are the strongest signal that the customer has missed information. Pushing through with a guess often reproduces a different bug, which then poisons the eventual Linear escalation.

Expected: Either the bug reproduces faithfully or it becomes clear the steps are too thin to follow.

Zendesk

If the bug reproduces and is visual or static, take a screenshot. If it involves timing, animation, an error toast that disappears or a network failure, capture a Loom instead.

Loom is worth the extra minute for anything where 'the order in which it happened' is the bug. Static screenshots lose the sequence and force the engineer to ask for a video later.

Expected: You have evidence in the right format for the type of bug.

Zendesk

Paste the evidence into a Zendesk internal note along with a one-paragraph confirmation that the bug reproduces, on which staging tenant and at which timestamp.

Format: 'Reproduces on staging-pro-09 as admin at 2026-05-04 18:41 BST. Loom: <URL>'. The timestamp helps engineering correlate to logs.

Expected: The ticket has an internal note confirming reproduction with the evidence attached.

Zendesk

If the bug did not reproduce in roughly ten minutes, stop and use the 'Need more detail' macro to ask the customer for browser, exact URL, tenant ID and time of last successful attempt.

Customers respond faster to a polite, specific list than to a vague 'can you send more info'. The macro is named 'repro-need-detail' in the saved replies panel.

Expected: The customer has a clear, polite list of the four pieces of information the team needs to try again.

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

Triaging a new Zendesk ticket and assigning a priority

Often next

Searching Linear for a duplicate engineering issue Escalating a confirmed bug to engineering through Linear

Alternative to

Searching Linear for a duplicate engineering issue

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.

Reproduced Northwind SAML 401 loop on staging-ent-04 with Loom

Could not repro Eastview CSV export 500, asked for browser

Confirmed Atlas Energy webhook delivery 503 on staging-pro-09

Sent repro-need-detail macro to Sundermark after 12-minute attempt

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 41 times across 4 connections
Applications	Zendesk
First seen	15 Feb 2026, 13:18
Last seen	4 May 2026, 18:42

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