How to put repetitive AI work on autopilot, without building the plumbing

There is a category of work I do for AI that AI should really be doing for me. Triaging the error report that just landed. Skimming the pull request before I look at it properly. Writing the Friday digest of what moved this week. Nudging the workunit that has been sitting in in_progress for nine days. None of it is hard. All of it is recurring, and all of it quietly eats the start of my day.

For a while my answer was scripts. A cron job that hit an API, dumped JSON into a prompt, and posted the result somewhere. It worked until it didn't — the script rotted, the prompt drifted from the script, the secret expired, and I was the only person who knew which box it ran on. The actual AI part was five lines. Everything around it was plumbing I had to babysit. This post is about how Workunit's Automations let me delete that plumbing and keep the five lines.

The chores that are actually automatable

If you write down the recurring AI tasks you do by hand, almost all of them split the same way: either something happened and you want an agent to react to it, or it's a particular time and you want an agent to go look. That's the whole shape. An event, or a clock.

Both halves are automatable, and both are the kind of thing an LLM with the right context handles well. The reason they don't get automated is rarely the AI — it's the glue. You need somewhere to receive the event, verify it actually came from GitHub and not someone poking your URL, run the prompt, give the model the tools to act, track what it cost, and show you what happened when it goes wrong. That's the part I no longer want to write per task.

Two triggers: a webhook or a schedule

An automation in Workunit is a trigger plus a recipe. The trigger decides when it runs, and there are exactly two kinds, matching the two halves above.

Both routes land in the same run pipeline. Same prompt rendering, same tool access, same cost accounting. The trigger is just the front door. Once a payload is inside, it doesn't matter whether a webhook or a schedule let it in.

Recipes: where the prompt and the guardrails travel together

The part I care most about is the recipe. A recipe is the reusable bundle that the trigger fires. It owns four things, and bundling them together is what stops the prompt-drifting-from-the-script problem I kept hitting with my own cron jobs.

One recipe can back many automations. I might write a single "Linear bug triage" recipe and point two automations at it — one webhook from Linear for live issues, one schedule for the weekly backlog walk. Same prompt, same tools, two front doors. Workunit ships a library of built-in recipes to start from — daily and weekly reporting digests, Linear-to-Workunit mirroring, GitHub PR review agents, Sentry triage, stale-workunit nudges — and you can write your own with the New recipe button.

Lightweight when you want an answer, heavy when you want work done

The two execution tiers are the difference between asking a model a question and handing a coding agent a machine. Picking the right one is mostly about whether the task is one-shot or multi-step.

Most automations want lightweight. It's the one-shot call that turns an incoming event into a triaged workunit or a written summary, and it costs cents. Reach for heavy only when the agent genuinely needs to run things — clone a repo, execute tests, work a task across several steps. The tier lives on the recipe, so the decision is made once by whoever authored it, not re-litigated per run.

Pointing GitHub, Stripe, and Sentry straight at it

The webhook side is where the plumbing usually hurts most, because the moment you expose a URL to the public internet you have to think about who's allowed to call it. Workunit handles this by verifying each vendor's native signature scheme. You don't reformat payloads, you don't run a proxy — you paste Workunit's endpoint into the vendor's webhook settings and it verifies the signature the vendor already sends.

For your own services there's a Workunit-native HMAC scheme in the Stripe style — sign the exact bytes you POST with a 32-byte secret, send it in an X-WU-Signature header, and Workunit verifies it with timestamp anti-replay and per-delivery dedup. A signing snippet for the custom scheme looks like this in Node:

const crypto = require("crypto");

const body = JSON.stringify(payload);          // the EXACT bytes you POST
const ts   = Math.floor(Date.now() / 1000).toString();
const sig  = crypto
  .createHmac("sha256", process.env.WU_WEBHOOK_SECRET)
  .update(ts + "." + body)
  .digest("hex");

await fetch("https://workunit.app/hooks/<token>", {
  method: "POST",
  headers: {
    "Content-Type":   "application/json",
    "X-WU-Signature": "t=" + ts + ",v1=" + sig,
  },
  body,
});

The endpoint URL carries a 43-character token — 256 bits of entropy — that's distinct from the automation's internal ID, so you can re-mint the public URL without breaking audit references. The signing examples ship in curl, Node, Python, and Go in the Automations guide. And before you wire up the real sender, the Test-fire button on each automation row replays a sample payload through the live template, so you can debug your prompt against realistic data without waiting for a webhook to arrive.

Knowing what it cost and what it did

The thing my homegrown scripts never gave me was visibility. When a cron job silently stopped firing, I'd find out a week later. When one started costing more than it was worth, I'd find out on the bill. Automations close both gaps.

Every run gets a detail page with a live terminal. For a heavy-tier run you watch the coding agent work in real time, exactly like a manual Cloud Execution. For a lightweight run the same page shows the MCP tool-call transcript and the model's response. Status, duration, and cost stream in without a refresh.

Cost and token usage are tracked per run and rolled up per automation, read straight from the model response and stored as USD. The Automations page breaks 7-day spend down by model, so the question "which automation is the expensive one, and which model is it burning" has an answer on the screen instead of in a spreadsheet. One honest caveat: heavy-tier runs don't yet surface their model spend back into that rollup, so the panel flags when heavy runs are in the window and undercounting — budget those separately for now.

What this replaces

I want to be precise about what Automations is and isn't. It isn't a general workflow engine with branches and loops and a visual canvas. It's a narrow thing done deliberately: take an event you already have — a webhook you already emit, a schedule you already keep in your head — and run an AI workflow off it, with the prompt, the tools, the model, and the cost tracking handled. The orchestration plumbing I used to write per task is the part that's gone.

And because the agent runs inside Workunit, the work it produces lands where the rest of your work already lives. A Sentry error becomes a triaged workunit with the right tasks. A PR review writes its findings as context atoms the next agent will read. A weekly digest pulls from the same workunits you and your collaborators have been editing all week. The automation isn't a side channel firing off into a Slack message and forgetting — it writes back into the shared workspace, so the next human or agent picks up where it left off. That's the difference between putting AI chores on autopilot and just adding another integration to maintain.