Linear launched Loops on July 20th. You describe a job in plain language, pick a schedule or trigger, and Linear Agent runs it on repeat — drawing on your issues, connected codebases, MCP servers, and previous runs. Product teams can now define recurring automation the way they define tickets. The product is genuinely useful.
The hard part it exposes isn't about the automation. It's that most teams don't know which of their work is actually recurring.
The Specification Is the Upstream Problem
Setting up a Loop is technically straightforward. The difficult part is answering the question the setup requires: what work is routine enough to systematize, predictable enough for an agent to handle with judgment, and frequent enough that automating it recovers meaningful time?
This sounds like it should be obvious. Most developers have a clear sense that some of their work is repetitive — sprint prep, checking on blocked tickets, running the same verification steps after each deploy, triaging the weekly queue. What they usually lack is actual data on the pattern. How long does sprint prep take across a full cycle? Is it two hours or six, and does it vary in ways that correlate with anything trackable? Which categories of issue arrive at predictable intervals and which feel regular but arrive in bursts?
The tasks that feel recurring are not always the same ones that actually are, by any measurable definition.
What Teams Automate vs. What Would Actually Help
There's a failure mode in automation that appears when people specify what to automate from memory rather than data: they automate the most memorable task, not the most frequent one.
The memorable task has salience. It's frustrating, it blocks something, you remember doing it last week and the week before. The task you do most frequently might be so embedded in your workflow that it doesn't register as a discrete thing to automate. You do it without categorizing it as "the thing I keep doing."
Sprint retrospective preparation is memorable because it's annoying and it blocks the retro meeting. Checking the same five dashboards before every PR merge is not memorable because each instance takes ninety seconds and is cognitively effortless. If you set up Loops based on salience, you get one for retrospective prep running every two weeks, and you miss the dashboard-check pattern running twenty times a week.
The automation value is in the dashboard-check pattern. Most teams would set up the retrospective loop.
Why the Frequent Work Stays Invisible
The underlying visibility problem is structural. The tasks that accumulate the most cumulative time are often distributed across dozens of small instances that never individually register as significant.
IDE-based time tracking doesn't help here because it only captures editing. You can find out how long you spent in your editor, broken down by language or file. You cannot find out how long you spent context-switching between your editor and a monitoring tool, or how often you interrupted a focused session to check a Slack channel for a specific kind of update, or what fraction of your day went to small recurring actions that don't happen inside any particular application.
System-level tracking captures this, but most developers don't do it. When every active window is logged with timestamps, the patterns that surface are often surprising. The application you assumed took two minutes a day appears as forty. The check you assumed was rare is logged seventeen times. The loop you set up for the infrequent-but-memorable task turns out to be less valuable than the one you didn't think to set up for the frequently-invisible one.
Linear Loops can't solve this. The product runs whatever loop you specify. The knowledge problem is upstream.
The Same Gap in AI Tool Adoption
This isn't a new pattern for AI tooling. Opsera's 2026 benchmark report across 250,000 developers found that 21% of AI coding licenses go underutilized across the enterprises they track. Teams pay for them; individual developers don't use them.
That's not primarily a motivation problem. It's a specification problem. Developers who adopt AI coding tools most effectively are the ones who have a clear sense of what to use them for — which tasks benefit from AI assistance, when to reach for the tool, what good output looks like. Developers who underutilize typically report that they're "not sure when it would help." They haven't mapped their work at the task level in a way that produces clear candidates for augmentation.
The 21% underutilized seat problem and the "what should I put in a Loop?" problem share the same root. Both require you to know your own workflow at a level of detail that most developers don't have, because the tracking infrastructure was never built to surface it.
The Pre-Work Most Teams Will Skip
Using recurring agent workflows effectively requires something like an inventory of recurring work. Not a vibes-based sense of what's routine — actual data on which tasks happen at what frequency, for how long, in what context.
That inventory is useful before you open the Loop configuration for the first time. It tells you whether you're setting up a high-frequency loop on a three-minute task or a low-frequency loop on a ninety-minute one. It tells you which automations would actually surface in the day-to-day versus which ones run once a month and feel impressive in a demo. It changes which loops you write.
The developers who'll extract the most from Loops are the ones who did some version of this mapping first — intentionally or not. They've been tracking their working time at the session level, or they've run time audits that surfaced their invisible overhead, or they've kept enough notes on recurring frustrations to know what frequency "recurring" actually means for each task.
Most teams will skip this. They'll set up loops for the obvious things — the tasks anyone would recognize as repeating — and miss the compounding gains hiding in the tasks no one thought to name.
What the Data Shows When You Look
At xeve, this is what the activity log surfaces: the apps you open repeatedly in sequence, the patterns that repeat across weeks, the short recurring actions that add up across a month. The recurring work that's worth automating shows up in the data before it shows up in memory.
A developer who can see that they check the same monitoring dashboard 22 times a week has a specific starting point for a Loop specification — one that targets actual frequency. A developer who estimates "maybe a few times a day" is guessing, and the guess is almost always an undercount by a factor of two or three.
Linear's product is correct that teams need recurring agent workflows. The automation capability is real and the timing is right — tool latency has dropped enough that the loops are fast, and LLM judgment is good enough that the loops handle exceptions. The missing piece isn't in the product. It's the self-knowledge required to configure it well.
That knowledge comes from tracking, and tracking is the work that happens before the agent does anything. The teams that spend time on it will set up better loops. The teams that skip it will set up loops that run reliably on the wrong tasks.
Loops are a good bet. The pre-work is on you.