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 and Linear, 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.

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

Once a Zendesk ticket has a Linear issue, the support rep records the Linear identifier as a 'linear-{id}' tag and sends a public reply chosen from one of three priority-keyed templates. The template is chosen by Linear priority and the Linear URL is never shared in the public reply.

Tags

zendesklineartaggingtemplatesexpectation

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 a Zendesk ticket has a Linear issue (whether newly escalated or matched against an existing one), the support rep records the Linear identifier as a Zendesk tag in the form 'linear-eng-plat-4192', adds an internal note pointing to the Linear issue, then sends a public reply chosen from one of three canned templates keyed to the Linear priority. P1 and Urgent issues get the 'actively investigating, expect a daily update' template. P2 issues get the 'logged with engineering, no fixed timeline' template. P3 and lower get the 'added to backlog' template. The Linear URL is never shared in the public reply.

Reasoning

Customers want to know two things: that someone heard them and what to expect. The canned-template choice is the team's way of making sure the customer gets the right one. Sharing a Linear URL externally has been a source of past leaks of internal triage discussion, so the team's rule is that the Linear identifier lives only in tags and internal notes. The structured 'linear-{id}' tag on the Zendesk ticket is what makes the post-fix sweep possible: searching Zendesk by that tag returns every ticket that needs a follow-up reply when the Linear issue ships, regardless of which support rep originally linked it.

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 either a newly created Linear issue or a matched existing one and is ready to be paused while engineering works.

Outcome

The Zendesk ticket carries a 'linear-{id}' tag, an internal note pointing at the Linear issue and a public reply that sets a priority-appropriate expectation. The customer knows their issue is logged and what level of update to expect.

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 add a tag in the format 'linear-{team}-{number}', lowercased and hyphenated (e.g. 'linear-eng-plat-4192').

Lowercase and hyphenated is the only format the post-fix sweep search recognises. Mixed case or underscores break the search and leave the customer hanging when the issue ships.

Expected: The ticket has a 'linear-{id}' tag in the canonical format.

Linear

Open the linked Linear issue and confirm its current priority. Note whether it is Urgent, High, Medium or Low.

The priority on the Linear issue (not the Zendesk ticket) is what determines which expectation template the customer receives. Engineering may have re-prioritised after escalation, so always check.

Expected: You know the current Linear priority and can pick the matching template.

Zendesk

Add an internal note on the Zendesk ticket of the form 'Linear: ENG-PLAT-4192 (priority: Urgent, status: Triage)'.

Keeping the Linear status in the internal note (not just the identifier) saves the next support rep a click. They can decide whether to give a fresh status update without leaving Zendesk.

Expected: The internal note records the Linear identifier, priority and status.

Zendesk

Pick the saved-reply template that matches the Linear priority: 'eng-active-update-daily' for Urgent, 'eng-logged-no-eta' for High and Medium, 'eng-backlog' for Low.

Resist the temptation to promise tighter timelines than the template offers. Customers remember promised ETAs and surface them weeks later when they slip.

Expected: The right template is loaded into the public reply.

Zendesk

Personalise the template with the customer's first name and the one-line summary of their report. Do not include the Linear identifier or URL.

The Linear identifier is internal. Customers who learn the identifier sometimes start asking for it by name later, which makes future sweeps and macro replies harder to keep tidy.

Expected: The reply addresses the customer by name and summarises their report in one line, with no internal identifiers visible.

Zendesk

Submit the reply as 'On-hold' so the ticket leaves the active queue without losing its Linear tag.

Submitting as Solved here is the most common mistake. Solved tickets get a CSAT survey straight away which is unfair to the customer when the bug is not actually fixed yet. On-hold preserves the linkage and pauses the SLA clock.

Expected: The ticket is on-hold with the public reply sent and the Linear tag still attached.

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

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

Often next

Holding a Zendesk ticket pending the Linear fix Sweeping linked Zendesk tickets when a Linear issue ships

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.

Tagged Northwind #82441 'linear-eng-plat-4192', sent active-update template

Linked Eastview #82398 to ENG-API-4231, sent logged-no-eta template

Atlas Energy #82355 tagged linear-eng-api-3987, daily update set

Periwinkle #82287 tagged linear-eng-web-4233, backlog template

Heron #82321 tagged linear-eng-bill-4235, active-update sent

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 47 times across 5 connections
Applications	Zendesk, Linear
First seen	21 Feb 2026, 11:24
Last seen	4 May 2026, 14:50

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