On July 17, 2026, Cursor pushed a changelog entry that is easy to miss: "Cursor in Slack now shares a plan before it starts, runs in multi-repo environments, and can work across channels and threads. Cursor now responds with a plan before it begins, so you can jump in and redirect early." That one update moves the IDE out of the IDE.
The significance is not that a coding agent can now receive a Slack message. Several tools could already do that. The significance is the sequencing: plan first, execute second, with status updates as it works. That is a different contract than "here is a pull request, please review."
What spec-driven coding agents in Slack actually change
The traditional agentic coding loop is: open IDE → prompt agent → watch it run → review diff. That loop still requires the engineer to initiate from inside the tool. A newer category of tools operates asynchronously: you message the agent from Slack, describe the task, and walk away-the agent plans, writes code, runs tests, and delivers the result as a pull request.
Cursor's July update sharpens this pattern with one key addition: Cursor now responds with a plan before it begins, so you can jump in and redirect early; as it works, it updates its status so you can follow each step. This matters because the most expensive agentic mistake is not a bad diff-it is a bad diff across forty files that nobody caught until review. Interrupting after a plan costs nothing. Interrupting after implementation costs review time and context.
The multi-repo piece is also non-trivial. From Slack, Cursor can now start in a named multi-repo environment instead of a single default repository. If your frontend, backend, and shared code live in separate repos, Cursor reads your request and targets the environment that gives it access to all of them. Most engineering teams do not live in a monorepo. Cross-repo tasks-adding a feature that touches an API contract and two downstream consumers-are exactly the ones that get avoided because they are slow to coordinate. A Slack-native agent that can reason across them changes the calculus.
The attention problem nobody is talking about
As agentic coding spreads, the working life of a software engineer has become dazzlingly complex. A single engineer might oversee dozens of coding agents at once, launching and guiding different processes as necessary. Human engineers' attention has quickly become the limiting resource.
This is the non-obvious consequence of getting coding agents right. The bottleneck was always assumed to be model quality or tool quality. The actual bottleneck, once those improve, is the engineer's ability to track what is running and redirect what has gone sideways. Cursor Automations address this by bringing the agent surface to where engineers already look-their Slack workspace-rather than requiring constant IDE attention.
The new Automations feature allows developers to configure agents that operate continuously in the background, triggered by events such as Slack messages, newly created issues, merged pull requests, or PagerDuty incidents. Cursor says it uses this internally: a security review automation runs whenever code is pushed to the main branch, analyzing code changes for potential vulnerabilities and flagging high-risk issues to engineers via Slack notifications.
Cursor estimates that it runs hundreds of automations per hour, reaching far beyond simple code review.
Where this sits in the broader shift
Cursor's Automations are the most visible edge of a wider change: coding agents are moving from personal productivity tools to team workflow infrastructure. From completion to delegation-you no longer ask AI to finish a line, you delegate issues, tests, migrations, refactors, and cleanup tasks. From isolated tools to workflow entry points-IDEs, CLIs, GitHub issues, Slack, and cloud environments are becoming connected surfaces. From prompt tricks to systems engineering-context management, permissions, MCP tools, sandboxes, audit logs, and cost controls matter as much as model quality.
AWS made a structurally similar bet with Kiro earlier this year. Unlike Cursor or GitHub Copilot, which bolt AI onto the traditional code-as-you-type workflow, Kiro introduces a fundamentally different programming model: you describe what you want to build, the agent generates a structured specification-requirements document, design document, task list-and only then does it execute code.
One limitation developers have identified: because requirements.md and design.md are generated upfront, they do not automatically update when implementation reveals new constraints. Teams have reported specification drift as code evolves beyond what the original spec captured.
Cursor's "plan before executing" pattern in Slack is a lighter version of the same idea-without the waterfall risk. The plan is a short statement of intent, not a locked document. You redirect it in-thread, in seconds, before the agent has touched a file.
Beagle in action#engineering, 10:41amThe Slack-as-control-plane model also has a governance angle. Teams now need to decide which agents can modify which repositories, access which secrets, and spend which budget. When the agent lives only inside an individual's IDE, those decisions are invisible to the team. When it operates from a shared Slack channel, the decisions become auditable-who triggered what, when, and what the agent proposed before it ran.
The honest caveat: while AI coding agents have dramatically increased the amount of code developers can produce, related processes such as code review, monitoring, and maintenance have not advanced at the same pace. Cursor's Automations aim to close that gap by deploying agents that automatically handle those tasks. Whether they do is still an open empirical question. Bugbot, Cursor's existing code-review agent, is triggered every time an engineer makes an addition to the codebase and reviews new code for bugs; using Automations, Cursor has been able to expand that system to more involved security audits and more thorough reviews. That is a concrete track record, not a product promise.
Cursor Automations in Slack: common questions
What can Cursor Automations in Slack actually do?
Automations allow developers to configure agents that operate continuously in the background, triggered by events such as Slack messages, newly created issues, merged pull requests, or PagerDuty incidents. Each trigger launches an agent in a cloud sandbox. Practical uses include security review on push, risk classification for pull requests, and incident investigation when a PagerDuty alert fires.
Do I need to be in the IDE for this to work?
No. The July 17 update lets Cursor receive a task in Slack, post a plan in the thread, and work across repositories-all without the engineer opening the IDE. As it works, it updates its status so you can follow each step. Cursor also refined how its responses look in Slack.
How is this different from GitHub Copilot's coding agent?
GitHub Copilot's coding agent works through GitHub Issues: you assign an issue to Copilot, it works in a GitHub Actions environment, explores the repository, changes code, runs tests, and opens a pull request. GitHub draws a useful distinction: agent mode in the IDE is synchronous pairing, while coding agent is asynchronous delegation. Cursor's Automations add Slack as a trigger surface and include always-on background scheduling, not just issue-based delegation.
What is the plan-first pattern and why does it matter?
The plan-first pattern means the agent states what it intends to do-which files, which tests, what scope-before writing any code. You can redirect or cancel before the agent has committed to a path. This matters most for cross-repo tasks, where a wrong assumption early produces a large diff that is expensive to unwind at review.
Does this change how engineering teams should structure their Slack channels?
Probably yes, over time. If a coding agent operates from a shared channel, that channel becomes an audit trail for what the agent touched and why. Teams that want to keep agentic work visible-rather than buried in an individual's IDE history-may want a dedicated #eng-agents channel, or trigger Automations from project-specific channels so context is co-located with the conversation that generated the task.