Inspiration
As a developer, I've dealt with agent memory issues for months. My two biggest pain points were persistent memory and shareability. I tried storing all my agents' context in Obsidian markdown files, but that blew up my token costs and hurt my agent's performance, and it didn't solve sharing at all. As someone who competes in hackathons almost every week, I wanted a way to share context with my team so all our coding agents stay on the same page. So I built ContextMaster.
What it does
Say you have a team of five builders, each using Claude, Cursor, and Gemini. All your agents can see the codebase, but the code doesn't tell the whole story. There's no record of why you made a decision, where you pivoted, or how the product reached its current state.
ContextMaster connects all agents to a single workspace over MCP. Instead of copy-pasting context between agents and losing details, each agent selectively pushes and pulls from a shared "team brain", so every decision is tracked and every model stays up to date.
How we built it
I built a custom MCP server with tools to push and pull context from specific workspaces (you can have as many as you want). When you save a chat session, gpt-4o-mini chunks it into typed categories: decisions, current state, conventions, findings, open questions, references, and context. Each chunk is embedded with text-embedding-3-small and stored in Redis. Every save is timestamped, so you can tell which decisions are current and which are old but still relevant, and superseded decisions get flagged automatically.
For retrieval, I use RediSearch. Your query is embedded and two ranked lists come back: one ranks chunks by keyword match using BM25, the other by semantic similarity using K-nearest-neighbors with cosine distance over an HNSW vector index. I fuse the both lists, keyword + semantic, with Reciprocal Rank Fusion (RRF). The top chunks load into the agent's context, so it doesn't miss anything and doesn't have to load the entire project into its window. Vectors, full-text search, and storage all live in one Redis instance, no separate vector database.
Challenges we ran into
The hardest challenge was keeping the agent faithful to the tool instead of falling back on its own memory, where it tends to miss details and hallucinate. Getting reliable retrieval took real experimentation before I landed on the BM25 + KNN/HNSW hybrid. To test this out, I turned off my agent memory and examined if it could pull catch specific details and important information from the context.
The other challenge was minimizing overhead so developers don't feel like they're migrating to a new tool. You do 99% of the work right inside Claude or Cursor, make an account, connect your agents, and you're set.
Accomplishments that we're proud of
I'm proud of the retrieval performance — even with minimal LLM calls, agents save and retrieve details reliably. A big milestone was connecting multiple coding agents to a single shared workspace, so different agents stay in sync through one "team brain." I also architected the system for full team sharing: once it's deployed, users can share workspaces and connect their own agents across machines, I just couldn't demo that part solo on one computer.
What we learned
I learned how to manage large amounts of context and why it matters, not just for coding agents. Context loss is a serious industry problem, and this project showed me that conservative, shared context isn't just about saving tokens; it directly improves an agent's performance.
What's next for ContextMaster
I'm planning to deploy this, it's a tool I'd genuinely use with my hackathon teams. I'd also love to bring it to local startups and see how they respond to this approach.
Built With
- clerk
- cursor/claude
- docker
- express.js
- mcp
- node.js
- openai
- pnpm
- react
- redis
- redisearch
- redisinsight
- redisstreams
- typescript
- vite
Log in or sign up for Devpost to join the conversation.