Cursor Automations Guide

Cursor's June 2026 Automations update added /automate, Slack emoji triggers, five GitHub triggers and computer use for cloud-agent automations. It also made automations easier to save through MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. auth, open PRs by default and clean up outdated memory files.

Knowing what shipped is the easy part. Turning Cursor AutomationsA cloud agent set to run on a schedule or an event trigger; each one is a trigger plus an instruction plus the tools it may use. Press Enter for the full definition. into something a team relies on takes a few deliberate steps, mapped below.

1. 1Prove the workflow manually once in a local agent session.
2. 2Use /automate or a Marketplace template to draft the trigger, tools and instructions.
3. 3Choose the narrowest Slack, GitHub, webhook or schedule trigger that carries enough context.
4. 4Review the first runs for noise, PR quality, memory behavior and permission creep.

New capability comes with new ways to get it wrong. Keep these boundaries in place as you adopt it.

An automation is just a cloud agent that runs on a schedule or in response to an event. Under the hood it is exactly three parts.

The trigger catalog

Treat an automation as an always-running agent on a schedule (every Monday) or a first-party trigger (a GitHub PR opened, a Slack channel created, a new message in a watched channel). They default to memory, so each run can look at prior runs, and you attach connectors inline when you set them up - one growth engineer authenticated Granola and Slack live, then fired a test run.

Worked example: a self-maintaining knowledge base

Cursor's finance team runs an AI ticketing system (Console) that depends on a detailed knowledge base. They built that KB by having Cursor scrape roughly six months of Slack history through the Slack MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. - learning what was asked, how it was answered, and whether it resolved well. Then they wired an automation that runs every 28 days, reviews the prior 28 days of channel messages, and proposes new KB additions: it drops a Slack message saying what it found and asks you to approve.

• Bug-report triage - an agent files reports to Linear, dedupes, auto-upvotes when many people flag the same thing, and follows up asking users for screenshots or repro steps.
• Doc consolidation on merge - on every PR merge, a Haiku-4.5 cloud agent reads the changed code, updates docs under /docs, then Slacks the result to a private channel.
• On-call rescue - a PagerDuty trigger fires a cloud agent at incident time, so instead of being paged at 2am you wake up to a fix already in flight and just review the PR.
• The fun one - a daily "what do you want for dinner" agent that creates a DoorDash group order in a food channel.

Because with /automate the manual run is the input, not a rehearsal. You create the automation from a local agent session in plain language, so whatever the agent understood in that session is what gets promoted into the trigger, the instruction and the tool list. A session where you quietly corrected it twice produces an automation that has never once run without you.

The failure mode is not a broken automation. It is a working one whose instruction was thinner than you thought, firing on schedule and opening a plausible pull request every time.

That costs more than it looks like it costs, because the damage is to attention rather than to code. An automation never merges on its own, so every run lands in front of a human, and after the fourth low-signal PR that human starts skimming anything from this bot. The review is nominally happening and nobody is reading. Define no-op behaviour up front, so a low-signal comment or emoji produces nothing at all, and the output stays worth opening.

A schedule fires at a rate you chose. An event fires at a rate your organisation chose, and that difference decides most of the design. Start with a schedule for anything whose value is a summary, and reserve event triggers for cases where the timing is the point: a PagerDuty incident is worth waking an agent for, a fourth comment on an issue thread usually is not.

The five GitHub triggers added in June sharpen this. Issue comment, PR review comment, PR review submitted, review thread updated and workflow run completed are all events that happen constantly on an active repo. That is not an argument against them, and it is why every trigger takes allow-list filters for specific people, channels, a keyword or a regex. Fire on a named reviewer's comments and you have a useful automation; fire on all comments and you have a queue.

Team size moves this line more than anything else. On a small repo an issue-comment trigger might go off twice a day, and you can watch every run. Across a monorepo with a couple of hundred engineers the same configuration is a different product, and the allow-list stops being an optimisation.

Which is roughly why Summarize Changes Daily is the recommended starting point. It is scheduled, it reads rather than writes, and Cursor measured it at 89% retention, so the boring one is also the one people keep.

It accumulates without review. Automations default to memory so each run can look at what earlier runs found, and that is exactly the mechanism that lets a monthly review automation build on itself instead of starting cold. The same mechanism means a conclusion written during one bad run is indistinguishable, later, from one written during a good run.

So an automation that has been running for four months carries a small pile of decisions nobody signed off. Cursor's guidance is to review the memory files periodically and delete the stale ones when they could steer future runs badly, and the June update added memory-file cleanup partly for that reason.

I'd put the memory files on the same review cadence as the automation's own output, whatever that turns out to be for you. Reading the PRs tells you what it did last week. Reading the memory tells you what it now believes, and those two questions drift apart faster than you would expect from something that looked correct when you set it up.