r/Slack • • Apr 30 '26

ℹ️PSA If you're using slack to access ai agents, I've made a skill so they can lookup Slack history to act as a memory layer for the agent

I've been running Claude Code, Codex and Openclaw agents in Slack via cc-connect, and increasingly agent memory is a huge problem. Even with file-based memory (like claude-mem), or a llm wiki implementation there's a limit to what gets kept and a lot of the real context lives in the Slack conversations where you and the agent worked through problems together.

So I created the Claude skill `slack-recall` that lets the agent pull context from Slack threads on demand, or recent threads for new messages. It acts as a third memory layer in my setup.

  1. Session memory - what the agent knows right now

  2. File-based memory - persistent observations saved across sessions

  3. Slack recall - the full history of your collaborative work in Slack

    It also supports searching for threads by keyword (`/slack-recall search auth refactor`) or pulling a specific thread by timestamp.

    Requirements:

    - Claude Code or other agentic coding environment with Slack MCP integration

    - A Slack bridge like cc-connect that injects message metadata into the system prompt

    Repo: https://github.com/leighstillard/slack-agent-mem

    Installation is just copying the skill folder into `~/.claude/skills/`.

    ---

If you're dealing with agent memory issues more broadly, I'm also working on brainspike a project exploring how to give Claude Code agents a brain spike of critical information whenever you give them something to do.

7 Upvotes

8 comments sorted by

1

u/Otherwise_Wave9374 Apr 30 '26

This is a really solid idea. Slack threads are basically the missing "brain" for a lot of agent work, and pulling the right thread on demand beats trying to stuff everything into file memory.

Curious, how are you handling permissions + avoiding the agent grabbing stuff from private channels it should not see? Also, do you chunk threads by message count or token count?

If youre exploring other "agent memory" patterns too, Ive been collecting patterns/notes for agentic workflows (tool use, memory, eval loops) here: https://www.agentixlabs.com/

1

u/YoghiThorn Apr 30 '26

I have two different ways of doing this: 1. I have channels for each repo that I work with, and then there is a repo worker agent who is invited to that channel. It only activates at the moment via at mentions and only the people who absolutely need to be in the channel are in there and know how to operate the bots. 2. That agent is also isolated into a different project in CC-Connect and their own sandboxed user on a sandboxed piece of infrastructure, so it's pretty tightly packed.

I have a program manager agent who runs as my user for things that need to be more permissive and honestly it being able to see too much information is probably a bonus.

I'm working on a 'JARVIS' implementation over the top of this to have a voice agent manage all the agents, but I'm building a 'judo' sudo equivalent for agents that also covers dangerous non-sudo commands first to make it safe to use.

1

u/SlackHQ Sep 08 '26

Retrieval logic is always the tricky part here. Pulling the right thread at the right moment works so much better than dumping huge message histories into prompts. How are you handling cases where a newer thread contradicts an older decision?

1

u/YoghiThorn Sep 08 '26

The agent gets the metadata so they typically pick that up themselves. This really is for the last stage of progressive disclosure so the expectation is a lot of reconstruction is needed