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

Sweeping linked Zendesk tickets when a Linear issue ships

Each Monday morning, the senior on-rotation support rep reviews the previous week's shipped Linear issues for the 'support-blocking' label. They reply to every Zendesk ticket carrying the matching 'linear-{id}' tag with a personalised 'eng-shipped-update' macro and submit each as Solved.

Tags

zendesklinearsweepmacrosshipped

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

Each Monday morning, the senior on-rotation support rep reviews the engineering teams' Done view in Linear for issues that shipped the previous week. For each shipped issue carrying the 'support-blocking' label, they search Zendesk by the canonical 'linear-{id}' tag, then open every matching ticket and reply using the 'eng-shipped-update' macro. The macro is personalised with the customer's first name, the release version if known and a one-line summary of what changed. Each ticket is then submitted as Solved (not Closed) so the customer can re-open if the fix turns out to be incomplete, and the 'linear-{id}' tag is left in place for record.

Reasoning

The fix-and-forget pattern is the most common cause of late CSAT drops on this team. Customers who reported a bug and were told 'logged with engineering' notice when nobody comes back, even months later. The Monday sweep is the team's mechanism for closing that loop reliably without depending on individual memory. Solved (not Closed) matters because incomplete fixes are common enough that re-opening needs to be one click for the customer. Leaving the 'linear-{id}' tag intact is what lets future sweeps detect tickets that came back unsolved and need a second look.

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 Linear issue carrying the 'support-blocking' label has moved to Done and is part of the previous week's release.

Outcome

Every Zendesk ticket linked by the canonical tag receives a personalised public reply confirming the fix and is submitted as Solved. The customer knows what shipped and can re-open if the fix is incomplete.

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 switch to each engineering team's Done view, filtered to issues completed in the last seven days and carrying the 'support-blocking' label.

Cycle through ENG-PLAT, ENG-WEB, ENG-API and ENG-BILL. Skipping a team is the easiest way to leave a customer hanging.

Expected: You have a list of shipped issues that have at least one Zendesk ticket linked.

Linear

For each issue, copy the identifier (e.g. 'ENG-PLAT-4192') and note the release version if it is recorded on the issue.

Release version is usually in the issue's release field or in the latest comment from the engineer who shipped. Mentioning the version in the customer reply helps the customer verify on their side.

Expected: You have the identifier and the release version (if available) for each issue.

Zendesk

Search Zendesk by the canonical tag 'linear-{id}' (lowercase, hyphenated). Open every matching ticket in tabs.

Canonical tag formatting matters here. A ticket tagged 'Linear-Eng-Plat-4192' will not match the lowercase search and will be missed.

Expected: All linked Zendesk tickets are open and ready for replies.

Zendesk

On each ticket, load the 'eng-shipped-update' macro and personalise with the customer's first name, the release version and a one-line plain-language summary of the fix.

Translate the engineering changelog into customer language. 'Tightened the SAML cookie expiry handling' is fine. 'Fixed the 401 loop on stale cookies' is what your customer cares about and remembers.

Expected: Each reply explains the fix in plain language and points to the release that shipped it.

Zendesk

Submit each ticket as Solved (not Closed). Leave the 'linear-{id}' tag in place.

Solved gives the customer a one-click re-open path through the Zendesk satisfaction survey. Closed forces them to start a new ticket, which is friction nobody wants when a fix did not actually fix things.

Expected: Each ticket is Solved with the canonical tag preserved and the customer can re-open from the survey if needed.

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

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

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.

Solved 4 tickets after ENG-PLAT-4192 shipped in v2026.18.1

Closed loop on Atlas Energy #82355, ENG-API-3987 shipped

Swept ENG-WEB-4233 shipped tickets, 3 customers replied to

Solved Heron #82321 after ENG-BILL-4235 fix in v2026.16.3

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 18 times across 3 connections
Applications	Linear, Zendesk
First seen	2 Mar 2026, 10:14
Last seen	5 May 2026, 10: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