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

Escalating a confirmed bug to engineering through Linear

When no duplicate Linear issue exists, the support rep creates a new one with an engineering-style title and the team's fixed structure of customer impact, repro steps, expected vs actual, environment and a verbatim quote. The issue goes to the engineering team's Triage pseudo-user (never a named engineer) with the 'support-blocking' label and the Zendesk ticket number embedded.

Tags

linearescalationsupport-blockingtriage-userengineering

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 no duplicate Linear issue exists, the support rep creates a new Linear issue from the Zendesk ticket. The title is in engineering-symptom language (not the customer's wording) so engineers can find it later. The description follows the team's fixed structure: customer impact, reproduction steps, expected vs actual, browser and device, tenant ID and a verbatim quote of the customer's own words. The issue is assigned to the engineering team's 'Triage' pseudo-user (never to a named engineer), priority is set against the team's escalation matrix, the 'support-blocking' label is added and the originating Zendesk ticket number is pasted into the description.

Reasoning

The single biggest reason engineering ignores a support-raised issue is a customer-language title like 'login broken'. Engineers search Linear in technical terms, so the title is the only thing standing between an escalation and a duplicate of work the team has already started. Assigning to a named engineer rather than the Triage pseudo-user is also a quiet way to slow the issue down, because that engineer might be on leave, in a focus block or simply not the right owner. The verbatim quote of the customer's words is a hedge against support rep paraphrase: it lets engineering see what was said, not what was summarised.

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 carries a confirmed bug with reproduction evidence and a Linear search has returned no duplicate.

Outcome

A new Linear issue exists with an engineering-style title, a structured description, the 'support-blocking' label, the Zendesk ticket number embedded and assignment to the team's Triage pseudo-user.

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.

Linear

Open Linear and create a new issue in the engineering team that owns the area (ENG-PLAT, ENG-WEB, ENG-API or ENG-BILL).

If you are unsure which team owns the area, default to ENG-PLAT. Their triage rotation is set up to redirect to the right team within a working day.

Expected: A new issue draft is open in the right engineering team.

Linear

Write the title in engineering-symptom language. Lead with the system component, then the symptom (e.g. 'SAML callback returns 401 in cookie-expiry loop').

Avoid customer phrases like 'broken', 'not working' or 'I can't'. Engineers search Linear by component and symptom, and customer-language titles are the most common reason an existing issue is missed.

Expected: The title is short, technical and discoverable through Linear search.

Linear

Fill in the description using the team's escalation template: Customer impact, Reproduction steps, Expected, Actual, Browser/device, Tenant ID, Zendesk ticket, Customer verbatim.

Paste the customer's exact opening message under 'Customer verbatim' even if it is messy. The verbatim is what protects engineering from support rep paraphrase that quietly drops a detail.

Expected: The description follows the template and includes a quoted block from the customer.

Linear

Set the priority using the team's escalation matrix: Urgent for paid customer fully blocked with no workaround, High for blocking with workaround, Medium for annoyance, Low for cosmetic.

Linear priorities differ from Zendesk priorities by name but map directly: Zendesk P1 to Linear Urgent, Zendesk P2 to Linear High, and so on. Mismatching them confuses engineering when they look back at the originating ticket.

Expected: Linear priority maps consistently to the originating Zendesk priority.

Linear

Add the 'support-blocking' label and assign the issue to the team's 'Triage' pseudo-user.

Never assign directly to a named engineer at escalation time. The 'Triage' pseudo-user is what each engineering team uses to pick up support escalations during their rotation, and it survives any one engineer being away.

Expected: The issue is labelled 'support-blocking' and assigned to the engineering team's Triage user.

Zendesk

Switch to the Zendesk ticket and add an internal note recording the new Linear issue identifier (e.g. 'Linear: ENG-PLAT-4231').

Use the identifier, not the URL. Identifiers survive any Linear URL change and are searchable across Zendesk for the sweep step later.

Expected: The Zendesk ticket carries the new Linear identifier in an internal note.

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

Reproducing a customer-reported bug on a staging tenant Searching Linear for a duplicate engineering issue

Often next

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

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.

Created ENG-API-4231 'CSV export 500 large dataset' from Eastview #82398

Filed ENG-WEB-4233 dashboard permission-denied for Periwinkle

Escalated ENG-BILL-4235 invoice PDF rendering for Heron, P1

Created ENG-PLAT-4238 search index lag from Brightline Health

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 28 times across 5 connections
Applications	Linear, Zendesk
First seen	19 Feb 2026, 15:32
Last seen	2 May 2026, 17:08

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