Skip to main content
A metric drops on Tuesday. The team notices Friday. By then you’ve spent three days sending more users into the same problem. Opening Mixpanel or GitHub wasn’t the expensive part. Nobody was checking the metric against open issues and recent releases. That’s a good job for an AI employee.
Writes follow your tool permissions. Keep issue creation, status changes, and team posts on Ask while you test. Runner stages each write as an Action Card. Allow acts without asking. Off blocks the tool unless the Runner has its own override.

​
Recurring jobs for customer impact

Each Runner works independently. Runners can read the same source apps, but they don’t pass work or results to one another automatically.
Runner can connect the evidence. It can’t prove that one deploy caused a metric change just because the timestamps are close.

​
Start with: customer-impact check

A user-created Runner becomes active as soon as it’s created. Open it, assign the Project that contains the metric definitions and source locations, confirm the saved thresholds, and review its schedule and permissions, then click Run now. Use a schedule that matches how quickly your team can respond. A daily check nobody reads is worse than a twice-weekly check somebody owns.

​
Keep the rules in the saved prompt

Use a product Project for shared background:
  • The names and source locations of the metrics that matter.
  • Severity vocabulary and team ownership.
  • Release and issue naming conventions.
Put thresholds, comparison windows, timezone, exclusions, and prohibited actions in the saved prompt. Metrics, issues, and releases hold live state. Previous run output doesn’t carry forward automatically. Review the first few results with write tools on Ask. Tighten a noisy threshold in the saved prompt. Remove a vanity metric. Correct inaccurate background in the Project. Don’t leave either fix inside one run.

​
Other jobs to schedule

​
Delivery risk

Run each weekday morning. Find projects due in the next 14 days with blocked work, missing owners, overdue dependencies, or no recent update. Name the evidence and draft the question for the owner.

​
Bug intake

Run each weekday morning. Group new reports by the product area and symptoms shown in the source. Search existing Linear issues before drafting a new one. A person still chooses severity and priority.

​
Release summary

Run Friday after your normal release window. If no release appears in the source from the past seven days, stop. Otherwise, pull merged work and completed issues into a customer-facing and internal draft. Don’t claim impact before the data exists.

​
Weekly product review

Run Friday afternoon. Compare shipped work with the approved metrics and open customer reports. Call out missing or inconclusive data instead of forcing a win.

​
Protect the work that already shipped

The goal isn’t more tickets. It’s catching a customer problem earlier, keeping an important project from slipping, and giving the team evidence before it makes a decision. That saves engineering time and protects revenue without pretending the system knows more than the sources do.

​
What’s next?

Connect your apps

Link Linear, GitHub, Mixpanel, and the sources your team trusts.

Which AI employee should you add next?

Find the next job tied to customer or business impact.

Create a Runner

Put one scheduled check behind clear rules.