Using Slack to coordinate for software work with AI agents is becoming the norm today, with Tobi from Shopify speaking about River, Shashank from Razorpay talking about Slash and Han from Mintlify sharing about their own kb agent.
All of these agents are able to pull on-demand from a highly curated context, formed (and improved) from the key learnings from every conversation in the past. For example, if not creating relevant context on the go across each agent invocation, a coding agent told to not touch a code block without an approval will forget that rule in the next session.
That forget pattern would start surfacing outdated information or forget the guardrails mid-incident on Slack. The rule you typed once, for e.g., "roll back maxInstances and leave the schema migration in place" is still stored only in history, so new engineers or in a relevant chat, it does not surface up. Chat history does keep the instructions searchable, but it does not pull and show the right context correctly to whoever needs them next.
CodeRabbit Agent for Slack is built for a different kind of default. It works in the channel where your team already coordinates (on Slack), so it can investigate issues, open pull requests, and run scheduled digests there, and it keeps a knowledge base that stores durable facts it learns while working with you. Those facts respect how Slack already partitions trust across public channels, private channels, and DMs. Used deliberately, that memory becomes infrastructure your team can rely on.
This is a practical guide for engineers who want to use it to the fullest, the kind of thing you would tell a teammate who is about to @coderabbit in #eng-incidents for the first time. We will walk through what should be stored in the knowledge base versus the repository, what's the privacy model, and the regular habits that keep memory from rotting.
How CodeRabbit scopes knowledge (your threat model)
CodeRabbit Slack Agent knowledge base follows Slack's privacy model across three levels. There is team knowledge that is shared across the workspace, channel memory that holds patterns specific to one team, and thread memory that carries the current task. Facts that it learns in public channels and shared surfaces feed the global workspace knowledge base, while private channels, DMs, and group DMs keep an isolated private conversation knowledge base.
Respecting the spaces to not merge such different sources of communication into one funnel slows down the speed with which your org's memory can be refreshed. That is because where a fact is captured decides who gets to use it. A production guardrail captured in a public channel like #eng-incidents or #eng-backend becomes shared memory the whole team and the next @coderabbit invocation can draw on it. The same rule captured in a DMs stays with those people, which leaves the rest of the team running an agent that did not learn it.
Memory works alongside scopes, which decide which repositories, connections, and spend limits the agent can use in a given conversation. Every workspace starts with a Base Scope that applies everywhere, and targeted scopes override it for specific channels or DMs. If two scopes match the same conversation, the agent treats the match as ambiguous and blocks the request, to make sure it does not run with the wrong repositories, connections, or spend limits. Memory answers "what does the team know?", and scopes answer "what is the agent allowed to do?", and you want both. An agent that remembers your revert policy but can still open PRs against the wrong repository or organization is only half governed.
With the scoping and the guardrails clear, the next question is how teams lose context in the first place.
Three ways teams lose context
Before you turn memory on, it helps to name the failure modes you are fixing.
The first is treating the incident thread as the source of truth. For e.g., someone asks the agent to "roll back maxInstances, leave the schema migration in place", it opens a clean PR, and then two weeks later a different engineer asks for a similar revert and the agent rolls back the migration too because the guideline was not captured in the agent memory. If you hear the same rule being explained many times in Slack, promote the rule to the knowledge base, or to a runbook the agent reads through GitHub.
The second is having conflicting multiple sources for one fact. For e.g., Terraform says maxInstances is 12, a Notion page from 2024 says 8, and the senior on call says 10, and now given the ambiguity, the agent will unfortunately pick one confidently. Choose a canonical source, and use the knowledge base for a pointer to it.
The third is treating chat history as memory. Pasting fifty messages into a new thread adds tokens and noise without creating curated judgment. Your knowledge base is the spec layer for Slack-native work, so edit it on purpose (seriously!) and retire rules when the process changes.
Once you can name those failure modes, the practical question is what actually belongs in the knowledge base.
What to put in the KB (and what to leave out)
A useful rule of thumb is that the knowledge base holds distilled team judgment and not your entire conversation threads or chat export.
Good knowledge base entries are short and actionable. Governance lines such as "never bundle a Cloud Run scaling change with a schema migration in the same PR without platform-team review" works well. So do defaults and conventions that spell out how postmortems get filed, and compressed incident lessons that point at the file where the required details can be referenced from.
The north-star of a knowledge base is whether someone could act on the line without scrolling for more.
The longer material is better off left where it already is, since the agent can reach it through integrations. Runbooks for example can stay in Notion, ticket state in Jira, and code and PR history in GitHub, so that instead of duplicating any of that into memory, you let the agent link out and read the source when it needs the detail.
A few things should never make it into memory at all, starting with secrets, API keys, and customer PII, which have no business in a public knowledge base path.
Knowing what belongs there only helps if you can get it in cleanly, which comes down to how you prompt.
Prompts that build memory and that waste it
The way you phrase a prompt decides whether the agent stores something useful out of it. You teach a fact with the @CodeRabbit Remember command, or with the /learn command in a channel, and the agent will sometime offer to save a durable fact it discovered after a run. Whichever way you store a rule, be explicit, keep it bounded, and ask for playback so you can check what it actually captured.
Start with a single bounded rule:
When the process changes, retire the old rule out since memory needs overrides:
It is also good to check that the rule actually took hold before you lean on it during an incident, so ask the agent to walk through what it would do and watch for the constraint to show up in its plan:
@CodeRabbit can you list the steps you will take to:
- revert cloud run scaling for inventory-service
- deploy the changes to prod
The prompts to just stay away from are the ones that ask the agent to swallow something whole, like @coderabbit remember this whole thread, which would bundle the jokes, the half-formed guesses, and the exceptions that turn it into one giant blob nobody can later easily audit.
Good prompts fill the knowledge base, so the next question is where it sits among everything else your team already writes down.
Operating model: specs, KB, and tickets
It helps to picture the whole setup as three layers:
At the bottom sits the slow-changing material that humans own, the mission, the tech stack choices, and the runbooks checked into git, all of which the agent reads through GitHub or Notion whenever it needs the real procedure.
The knowledge base sits in the middle and carries the faster-moving judgment, the things like what you never do in a revert, who owns which dashboard, and which label gates a Terraform change.
Tickets and merged PRs sit on top as the activity record of what actually happened in a given week.
Now, while people are busy adding new tools (new sources of information) and ship net new features, that middle layer is bound to drift on its own. So, you'd want to take out few hours a week to go through the busiest @coderabbit threads, move anything that has hardened into a runbook, delete the knowledge base lines that have gone stale, and adjust scopes as new repositories or connections come online.
It is important to differentiate between Learnings and Knowledge Base. You may know of Learnings if you already run CodeRabbit on pull requests (the repo-scoped hints that sharpen review comments over time).
- Learnings are code-review memory, so they are the right home for the style, test, and ownership preferences that apply while a PR is being reviewed.
- The Agent for Slack knowledge base is workflow memory instead, so it should own the operational guardrails and channel norms that come up during incidents, standups, and automation, while anything long enough to count as a procedure stays in specs/ or a runbook.
With those layers in place, the thing to watch next is whether the memory stays healthy over time.
Health checks without obsessing over tokens
The billing model makes this easier to reason about than most AI tooling, because CodeRabbit charges Agent for Slack by the agent minute at fifty cents for each active minute, which simply measures the runtime a run actually spends working instead of stacking up input tokens and model-tier multipliers. Since scopes let you set separate spend limits for the runs people start and the runs that automation or triggers kick off, what you are paying for is the work done (and not for re-reads on every question).
A cheap and quick way to test the whole thing is to create a low-stakes channel like #eng-agent-lab, teach it a couple of small facts such as a hotfix/ branch prefix, a required platform-review label, and then have someone who was not around for that ask for the same guidance. If they get the right answer without anyone pasting scrollback then your shared memory set is genuinely working.
Healthy memory is the goal, but not every team needs to chase it on day one.
When to skip and when to invest
None of this is mandatory to have, because if you are only ever DM-ing the agent for one-off questions then what you really have is a fast assistant rather than organizational memory.
It starts to pay off once the pain is shared across the team. That usually means several channels leaning on the same production guardrails, or scheduled jobs like a daily standup digest that need the rules to hold steady. This is also where scopes come in handy. Once the backend and data platform split their repositories and connections, each scope wants its own set of facts, taught in the respective channels.
Designing memory on purpose
Context without amnesia is not about a bigger context window. It is about the memory you design. You teach the shared rules where Slack is public, so the whole team inherits them. You store distilled judgments, and ask the agent to play back what it learned to catch a misread. You retire whatever has gone wrong, and you lock down what the agent may do with scopes.
CodeRabbit Agent for Slack is built for the work your team already does in threads, huddles, and integrations, and clearly not for replacing the engineers doing it. A well-tended knowledge base is what keeps one person from becoming the bottleneck for passing context along. So teach three facts in a lab channel before your next real incident (I hope you don’t run into one)!
Top comments (0)