CodeRabbit published a blog post last week titled "Now the Agent Moves First." The framing caught my attention because that phrase describes exactly what we've been writing about on this site: the shift from agents that wait to agents that watch.
Their Agent for Slack is one of the more ambitious products in AI development tooling right now. It sits inside your Slack workspace, pulls context from GitHub, Jira, Linear, Datadog, Sentry, Notion, and AWS, and responds to @mentions with genuinely useful answers. When you ask it to investigate a performance issue, it pulls APM traces. When you ask about a failing deploy, it correlates the error with recent code changes. The breadth of integration is impressive, and unusual. Most tools in this category connect to one or two systems. CodeRabbit connects to a dozen.
CodeRabbit aggregates context across development tools.↗
What they built
The Slack-native approach is the right call. Engineers don't want another dashboard. They already live in Slack, and putting the agent there means feedback appears in the same thread where the team is discussing the deploy or the incident. We reached the same conclusion building My Senior Dev: the review agent's move into Slack (Act 2) generated more engagement than any UI polish on the web dashboard.
Devin is probably the strongest existing example of this pattern. Its Slack bot can review PRs, write fixes, and execute multi-step engineering tasks directly from a thread. It's been around long enough to prove that Slack-native is a durable product shape, not just a demo. Devin ships 7 native integrations (GitHub, GitLab, Bitbucket for git; Slack and Microsoft Teams for communication; Linear and Jira for task management) plus a marketplace of 76 MCP tools for extending its reach. Where CodeRabbit differentiates is observability context: native connections to Datadog, Sentry, PagerDuty, PostHog, and cloud infrastructure give it cross-system reasoning about incidents and deploys that a code-focused agent doesn't attempt. Where Devin differentiates is execution depth, going from conversation to committed code in the same thread.
The automations feature is where CodeRabbit starts to separate from both. You describe what you want in natural language, the agent drafts a spec with schedule, scope, and destination, and you review before activating. "Every weekday at 9am, summarize new PR blockers in this channel." The setup is conversational and transparent. You see exactly what the agent plans to do, when it will run, and where it will post. That transparency matters when you're giving an AI recurring access to your codebase.
Their newest addition, Triggers, goes further. Instead of running only on a schedule, the agent fires when a specific event happens in a Slack channel. A Datadog alert lands in #prod-alerts, the agent investigates immediately rather than waiting for the next scheduled run. The blog post frames this as the moment where "the agent moves first," and for Slack-native events, that description is accurate.
When I dug into how the agent actually stores that context, the architecture was worth noting. CodeRabbit's sandbox maintains a structured knowledge base per repository: pre-indexed PR summaries with metadata and objectives for each recent PR, code guidelines extracted from AGENTS.md files, and path-specific instructions per directory. The workspace tracks 78 connected repos through a source mapping file and clones on demand rather than keeping everything checked out. Each PR gets its own directory with a meta.json, a raw summary, a summary map, and a PR objectives file. When the agent references a PR in a Slack thread, it reads from precomputed summaries rather than re-analyzing the diff each time.
This is infrastructure that most people won't see, but it explains why the agent's answers feel grounded. It's not just making live API calls to GitHub and hoping the context window holds. It's reading from a structured knowledge layer that was built before you asked the question.
A conversation that reveals the boundary
I tested this myself. In a Slack thread, I asked CodeRabbit: "can I create an automation from here?" It said yes and listed the options: recurring schedules, channel-triggered automations, fresh-thread or same-thread delivery.
Then I asked for something specific: "When a PR has a merge conflict, message the author of that PR in Slack."
CodeRabbit was upfront about the limitation: "The exact version you described isn't directly supported as an event-driven GitHub trigger from here." It proposed a workaround instead. A recurring automation that checks a repo for merge conflicts every thirty minutes and pings the PR author when it finds one.
I appreciated the honesty. Plenty of products would say "sure!" and quietly do something different. CodeRabbit explained the constraint, proposed an alternative, and showed a preview of the output. The sample run surfaced 11 PRs with confirmed merge conflicts in the repo, which was genuinely helpful information I hadn't found anywhere else.
But thirty minutes is not "when it happens."
A merge conflict appears the moment someone pushes to main and an open PR's base branch diverges. If the agent caught that push event in real time, the PR author could rebase while the changes are still fresh. Thirty minutes later, they've context-switched to something else. The cost of the rebase itself doesn't change, but the cognitive cost of picking it back up does.
Scheduled checks vs real-time event detection.↗
Schedule-driven vs event-driven
CodeRabbit's Triggers feature partially closes this gap, but only for events that surface in Slack. If a Datadog alert posts to a channel, the agent responds in seconds. For GitHub events like merge conflicts, check failures, or reviews going stale, the agent falls back to polling on a schedule. It watches Slack channels natively but reaches GitHub through periodic queries.
This is a common pattern across the industry. Devin goes furthest with Slack-native execution, writing and committing code from threads, but it still responds when mentioned rather than when something changes in the repo. Cursor's BugBot triggers on PR creation but doesn't monitor for state changes after that. Claude Code's auto-fix catches CI failures but not review comments that arrive hours later. The shape is consistent: respond to the initial event, poll for everything after.
The three-primitives framework maps this clearly. CodeRabbit's automations give it a solid clock, with scheduled runs that execute reliably on cadence. The Triggers feature adds a listener for Slack-native events. The inbox works well, delivering results to channels and threads with clear attribution. The gap is in listener coverage: it hears what happens in Slack, but GitHub and Jira remain on the other side of a polling interval. For those systems, the agent depends on either Slack forwarding (a Datadog alert posting to a channel) or scheduled polling (the thirty-minute merge conflict check).
Where this sits on the spectrum
CodeRabbit is further along than most tools in this space. The multi-system context, conversational automation setup, and honest interaction model are all well-executed. The Triggers feature represents a real architectural investment, not just a marketing rename.
The blog title "Now the Agent Moves First" describes where they're heading more than where they are today. For Slack-native events, the agent does move first. For everything outside of Slack, it still checks on a schedule.
We hit the same boundary building My Senior Dev. The shift from scheduled checks to continuous event detection required rearchitecting around normalized change events rather than periodic queries. It was the hardest part of the transition from Act 2 to Act 3. Given how quickly CodeRabbit ships, they'll probably get there faster than we did.
Posted May 15, 2026· AgentWorkforce
Issues, PRs, and arguments welcome on GitHub. Or email [email protected].