Put One Weekly Ops Task on a Loop

The weekly ops review is where a small company learns whether it is drifting. If one recurring task keeps eating the same meeting time, put it on a loop and keep the judgment where it belongs. Linear introduced Loops inside Linear Agent, its agent feature, for repeatable team workflows. For a founder or ops lead, the weekly rule is short:

• Choose a task with a clear trigger and output.
• Make the agent's instructions and run history visible to the team.
• Reserve one human decision for scope, priority, and exceptions.

Pick a task with a visible trigger and a checkable output

The task should be recurring, not a one-time task that disappears after the meeting. The trigger must be something the system can see, like a new issue, a changed date, or the weekly review date. The output should be a short note, a checklist, a draft, or a flag. If the task needs taste, politics, or a budget call, it is not ready for the first loop.

A Linear Loop can be set to run on a schedule or after a triggering event across a workspace. The weekly ops review is a scheduled event, and the task should produce the same shape of work every week. Start with a task that is boring enough to repeat and specific enough to check. A release-plan check, a status summary, or an automated triage prompt are good candidates.

A Linear Loop can compare active projects and initiatives with a central release plan, revise the plan when timing or scope changes, and add a note explaining the change. If the task is too vague, the loop will produce confidence without clarity. Done looks like the team can name the trigger, the output, and the exception that stops the loop.

Make the loop legible before the first run

Make the agent's instructions and the run log visible to the team. A loop that only the founder understands becomes a black box the first time it misses. The team needs to see what the agent was told, what it did, and what it skipped. That keeps recurring agent workflows useful instead of turning them into a source of confusion.

Linear Loops operate at the team and workspace level, and people with access can inspect their instructions, setup, and run history. Before the first scheduled run, ask who can read the instructions, who can see the last run, and who can point to the output. If the answer is only one person, the loop is not ready for the weekly cadence.

The step is done when a teammate can open the loop, read the prompt, check the last run, and say what changed. The log should show the input, the action, and any note the agent left. If a run looks wrong, the team should be able to trace the reason without asking the founder to remember. A missing note is a signal to stop the loop.

Keep one human decision for scope, priority, and exceptions

The loop can prepare the material, but a person should still decide what matters. The human decision should be named, not implied. That keeps the automation useful and keeps the founder accountable for the choices that shape the company.

A Linear Loop can examine a triaged issue's description, comments, and relevant code to suggest a next action and, when the path is clear, begin a coding session. The line belongs there. The human still decides whether it is the right issue, whether the fix fits the current plan, and whether the exception needs a different owner.

Put the human decision in the weekly ops review, not in the agent's prompt. The loop brings the list, the notes, and the proposed changes. The founder or ops lead decides what gets done, what gets deferred, and what gets escalated. The team can turn the loop off, edit the instructions, and review the log without breaking the week's plan or the next review.