Cursor Automations Guide

The table lists each change in the update with what it does. The GitHub row names all five new events, which you need when you choose the narrowest trigger for a workflow.

Cursor's release notes and announcements say what changed. They don't say how a team should act on it. The steps below are our suggested order, and the next section lists what to watch out for along the way.

1. 1Run the workflow by hand once in a local agent session, so you know what a good result looks like.
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.

Each item below is either a fact about the release, such as its beta status or plan access, or our advice for using it safely. Plan around each one, and recheck the facts when Cursor ships an update.

• Define no-op behavior, so a low-signal comment or emoji reaction doesn't open a noisy PR.
• Review 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, Slack access and GitHub write access as separate permissions.
• Review automation memory files on a schedule, and delete stale memories before they steer future runs the wrong way.
• Automations need Premium or higher, a Teams or Enterprise plan, or the legacy Pro, Pro+ or Ultra plan. Free, Plus and the legacy Start plan don't include them.

An automation is a cloud agent that runs on a schedule or in response to an event. It has three parts.

Common triggers

Each example below runs on a schedule, such as every Monday, or on a first-party trigger: a GitHub PR opened, a Slack channel created or a new message in a watched channel. Automations default to memory, so each run can read what earlier runs found. You attach connectors inline while you set one up. One growth engineer authenticated Granola and Slack live, then fired a test run.

Worked example: a self-maintaining knowledge base

In one Cursor talk, Cursor's finance team described Console, an AI ticketing system that depends on a detailed knowledge base. They built it by having Cursor read 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.: what was asked, how it was answered and whether the answer resolved the question. Then they set up an automation that runs every 28 days. It reviews the previous 28 days of channel messages, posts a Slack message about what it found and asks you to approve the new entries.

Because with /automate, the manual run becomes the automation. You create the automation from a local agent session, in plain language. Whatever the agent understood in that session goes into the trigger, the instruction and the tool list. If you quietly corrected the agent twice along the way, the automation has never once run without you.

The risk is a working automation with a thinner instruction than you thought. It fires on schedule and opens a plausible pull request every time.

That costs attention more than code. An automation never merges on its own, so every run lands in front of a person. After the fourth low-signal pull request, that person starts skimming anything from this bot, and the review happens on paper only. Cursor's docs suggest a quality bar in the prompt for when the agent should open a pull request, comment or do nothing, which is the no-op rule from the list above. If you enable approvals on the comment tool, the automation can also approve pull requests, so leave that off while people still read every run.

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

The five GitHub triggers added in June make the choice sharper. 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. An unfiltered comment trigger turns every comment into a run. Narrow a trigger where it offers a filter, such as the workflow name on Workflow run completed or a keyword or regex on Slack messages, and let the prompt decide when a run should do nothing.

Team size moves this line more than anything else. On a small repo, an issue-comment trigger might fire twice a day, and you can watch every run. Across a monorepo with a couple of hundred engineers, the same setup behaves like a different product, and narrowing the trigger stops being optional.

It builds up without review. Memory is what lets a monthly review automation build on earlier runs instead of starting cold. It also means a conclusion written during one bad run later looks the same as one written during a good run.

So an automation that has run for four months carries a small pile of decisions nobody signed off. Cursor's docs warn that memories persist across runs, and that untrusted input can leave misleading or malicious memories that affect later runs. Since the June update, you can delete memory files in the tool settings, or tell the automation to delete outdated ones when it runs.

Put the memory files on the same review schedule as the automation's output. Reading the pull requests tells you what the automation did last week. Reading the memory tells you what it now believes, and that can drift even while the pull requests still look fine.