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 Linear and 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 2 alternatives. 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.

Searching Linear for a duplicate engineering issue

Before opening a new Linear issue, the support rep translates the customer's wording into engineering-style symptom keywords and searches the most likely team's issues from the last sixty days. A strong match is recorded on the Zendesk ticket and skips the escalation, otherwise the support rep proceeds to create a new issue.

Tags

linearsearchdeduplicationengineeringlabels

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

Before opening a new Linear issue, the support rep translates the customer's wording into engineering-style symptom keywords (e.g. 'I can't log in' becomes 'SAML 401 loop on cookie expiry') and searches Linear with those. They wrap exact error codes in quotes, filter by the engineering team most likely to own the area, restrict to issues created in the last sixty days and check the labels on any close match for 'support-blocking'. If a strong match exists in Backlog, Todo or In Progress, they record the issue identifier on the Zendesk ticket and skip the escalation. If no match exists, they proceed to escalate.

Reasoning

Engineering does not search Linear in customer language and customer reports do not search well in engineering language. Translating between the two is what makes deduplication possible. The sixty-day window keeps results manageable: older issues are usually shipped or stale and surface false positives. Quoting error codes prevents Linear's fuzzy search from rewriting '401' into '4-0-1' across multiple tickets. The 'support-blocking' label check matters because issues already carrying that label have been escalated by support before, and re-escalating them is what makes engineering tune out.

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 confirmed as a reproducible bug or has steps clear enough that engineering could investigate.

Outcome

Either the existing Linear issue identifier is recorded on the Zendesk ticket and the escalation step is skipped, or the support rep has confirmed there is no duplicate and is ready to create a new Linear issue.

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

Read the confirmed bug summary and pick out the symptom in engineering language: error code, system component, action verb.

'Login broken' becomes 'SAML 401 cookie loop'. 'CSV export not working' becomes 'CSV export 500 large dataset'. 'Webhook missing' becomes 'webhook delivery 503 retry'. The translation is the work.

Expected: You have two to four symptom keywords ready to paste into Linear.

Linear

Open Linear's global search and paste the symptom keywords. Wrap any error code in double quotes so the search treats it as an exact match.

Without quotes, Linear's fuzzy matcher rewrites '401' across multiple issues and pollutes the result list. Quoted '"401"' will only match issues with that exact token.

Expected: The Linear search results are scoped to the most relevant issues for the symptom.

Linear

Filter the search by the engineering team most likely to own the area: ENG-PLAT for auth and infra, ENG-WEB for the dashboard UI, ENG-API for public API and webhooks, ENG-BILL for invoices and Stripe.

Most teams here own a clear surface area. If unsure, ENG-PLAT is the safest default to start with because they triage cross-team issues weekly.

Expected: Search results are scoped to the team most likely to own the bug.

Linear

Restrict to issues created in the last sixty days. Sort by relevance, then scan for a clear match in Backlog, Todo or In Progress.

Older issues that are still open are usually deprioritised work that is not coming back. Sticking to the last sixty days surfaces issues that engineering still considers active.

Expected: You have a manageable list of recent open issues to scan for a match.

Linear

Open any clear match and check its labels. If it carries 'support-blocking', leave a comment with the new Zendesk ticket number rather than re-escalating. If not, add 'support-blocking' yourself when you link.

An issue already labelled 'support-blocking' has been raised by support before. Repeating the escalation makes engineering tune out the label. Adding the label fresh is what tells engineering this is the second customer to hit the issue.

Expected: The match's labels reflect that support has linked a customer ticket to it.

Zendesk

If a match was found, copy the Linear issue identifier (e.g. ENG-PLAT-4192) and record it on the Zendesk ticket as 'Linear: ENG-PLAT-4192' in an internal note. If no match was found, proceed to escalate.

Use the issue identifier, not the URL. Identifiers are searchable across Zendesk and survive Linear URL changes.

Expected: The Zendesk ticket carries either the existing Linear identifier or a clear note that no duplicate was found and an escalation is the next step.

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 Reproducing a customer-reported bug on a staging tenant

Often next

Linking a Zendesk ticket to its Linear issue and setting the customer expectation

Alternative to

Escalating a confirmed bug to engineering through Linear Reproducing a customer-reported bug on a staging tenant

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.

Found ENG-PLAT-4192 'SAML 401 cookie loop' for Northwind, linked

No match in ENG-API for Eastview CSV 500, escalating new

Found ENG-API-3987 'webhook 503 retry' for Atlas Energy, In Progress

Added support-blocking label to ENG-PLAT-4192 for Sundermark

Searched ENG-WEB for 'permission denied dashboard', no match in 60d

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 56 times across 5 connections
Applications	Linear, Zendesk
First seen	12 Feb 2026, 10:55
Last seen	5 May 2026, 16:14

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