Tell a coding agent once not to touch the scaling block without platform approval and it will get it right, but only in that session. Open a fresh session next week and see that the agent "forgets" since the context did not carry on for further sessions.
That forget pattern would become expensive in Slack, where it surfaces outdated information or forget the guardrails mid-incident or in a standup thread. The rule you typed once, for e.g., "roll back maxInstances, leave the schema migration in place" is still in scrollback, so new engineers did not see it, and the bot starts each fresh @mention without it. Scrollback 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, 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 deliberately, 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 belongs in the knowledge base versus the repository or Linear, how the privacy boundaries actually behave, and the 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 learned 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.
That split is your threat model for organizational memory, 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. The same rule captured in a DM stays with you alone, which quietly 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. Someone writes "roll back maxInstances, leave the schema migration in place", the agent opens a clean PR, everyone merges, then two weeks later a different engineer asks for a similar revert and the agent rolls back the migration too because the constraint never left scrollback. If you hear the same rule explained three times in Slack in a month, you have a capture problem (rather than a memory problem), so promote the rule to the knowledge base or to a runbook the agent reads through GitHub.
The second is keeping conflicting homes for one fact. Terraform says maxInstances is 12, a Notion page from 2024 says 8, and the senior on call says 10, and the agent will unfortunately pick one confidently. Choose a canonical source, which is almost always the repository for infrastructure, and use the knowledge base for a pointer (rather than maintain copies of the truth).
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 and retire rules when the process changes, otherwise the agent faithfully applies something your team stopped doing in 2024.
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" work well. So do defaults that name an owner and a dashboard, conventions that spell out how postmortems get filed, and compressed incident lessons that point at the file where the required details live. The north-star of a knowledge base is whether someone could act on the line without scrolling for more.
The longer material is better left where it already lives, since the agent can reach it through integrations. Runbooks stay in the repository or Notion, ticket state in Linear or Jira, and code and PR history in GitHub, so 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, and the same caution applies to anything that is an HR or legal narrative.
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 prompts that waste it
The way you phrase a prompt decides whether the agent stores something useful or just more noise, so a few patterns are worth keeping in muscle memory. You teach a fact with the @CodeRabbit Remember command, or with the /learn slash command in a channel, and the agent will sometimes 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 loud since memory needs overrides:
It is worth checking 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 stay away from are the ones that ask the agent to swallow something whole, like @coderabbit remember this whole thread, which just bundles the jokes, the half-formed guesses, and the exceptions that were already out of date into one giant blob nobody can later easily audit. The knowledge base only needs a pointer to the onboarding index (rather than a copy of the whole onboarding novel). None of this has to be perfect on the first try either, since you can always open the web app to review the saved facts and prune any that have gone stale.
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 running record of what actually happened this week.
When the three layers disagree, you can lean on the repository for infrastructure facts, the tickets for narrative, and fix the knowledge base whenever it turns out to be the one that is lying.
This will look familiar from spec-driven development, where the slow specs and runbooks in git set the foundation, the knowledge base holds the faster-moving judgment, and tickets and merged PRs record what shipped. Because that middle layer drifts on its own, give it half an hour once a month, skimming the busiest @coderabbit threads, moving anything that has hardened into a runbook, deleting the knowledge base lines that have gone stale, and adjusting scopes as new repositories or connections come online, since stale memory is worse than having none.
There is one distinction to keep straight if you already run CodeRabbit on pull requests, where you may know Learnings (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. The rule of thumb is to give each fact a single home (rather than copy it into all three), and to link to it from the others whenever they need it.
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 stays legible as work done rather than being billed for rereads on every question, though it is worth remembering that a rambling "remember this whole thread" prompt still manages to waste minutes and pollute memory at the same time.
The Usage dashboard is good to check now and then, but the real signal is qualitative where teams refer to the memory of the bot as the source of truth in meetings. When an agent-opened PR goes wrong, trace it back and ask whether the rule was not taught, taught only in a DM, or taught and then contradicted by an old Notion page.
A cheap and honest 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 and a required platform-review label, and then have someone who was not around for that ask for the same guidance the next day, because if they get the right answer without anyone pasting scrollback then shared memory is genuinely working. Once repeat questions start climbing it is healthier to treat them the way you would treat undocumented specs, as tech debt you can clear in twenty minutes with a confirmable Remember prompt.
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 on day one, and pretending otherwise would be dishonest, because if you are only ever DMing the agent for one-off questions then what you really have is a fast assistant rather than organizational memory and you may as well use it as one, and a single-repo startup that already keeps everything important in AGENTS.md will get very little out of copying those same lines into Slack memory. The one thing genuinely worth fixing first is the connections, since if GitHub and Linear are not set up yet there is no point arguing about knowledge base hygiene when the agent cannot reach the judgment in the first place.
It pays 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 earn their keep. Once the backend and data platform split their repositories and connections, each scope wants its own set of facts, taught in the channels that scope actually runs in.
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 (we hope you don’t run into one)!
Top comments (0)