Contextberg
Turn your work into AI agent memory, served over MCP
Start new thread
Tiger

Contextberg - Turn your work into AI agent memory, served over MCP

by
Contextberg
β€’
Contextberg is a local memory app for AI agents. It watches your screens, browser history, and agent conversations in the background β€” so Claude Code, Cursor, and friends can just remember.

Add a comment

Replies

Best
Tiger
Maker
πŸ“Œ

Hey Product Hunt πŸ‘‹

Tired of re-explaining yourself to your own AI agent?

I'm Tiger. Every session reset. Every task switch meant catching my agent up from scratch. My brain was doing the memory work that the agent should be doing.

So I built Contextberg β€” the missing piece.

🧩 What It Does

A local memory app that runs in the background and feeds context to your agent via MCP.

  • Watches your screens, browser history, and agent conversation history

  • Builds both short-term and long-term memory in the background

  • Supplies context to your agent via MCP using built-in skill commands

  • No build step. Just install from the Microsoft Store and sign up β€” that's it. Free to start.

πŸͺŸ Built for Windows Developers

Every tool like this was Mac-only. Windows developers were always left out.

Contextberg is Windows-first β€” and built specifically for Windows, so it runs efficiently without hogging your CPU.

Close your laptop Friday night, mid-debug.
Open it Monday morning. "Where should I start?"
Your agent already knows.


πŸ”­ Long-Term Vision

The end goal: accumulate your personal context into your own data warehouse, and use it as fine-tuning material for a truly personalized LLM. An AI that knows you β€” not just your last session.
Roadmap:

γ€€- macOS & Linux support

γ€€- Hermes model integration

γ€€- Auto-generation of skill commands

γ€€- Skills management view

Got ideas? Drop them in the comments β€” your feedback shapes what we build next.

πŸš€ v1.0.0 Is Live Today

What context do you wish your agent just already knew?

Thami Benjelloun

I think memory/context is becoming one of the biggest bottlenecks for AI agents. The model can be smart, but if it forgets the project every session, the user still does the real work.

How do you think guys about privacy and user control with screen/browser history being part of the memory layer?

Tiger
Maker

@thamibenjellounΒ I fully expect strong criticism and concerns around handling sensitive information, and honestly I want to hear as many opinions as possible.

Because privacy and security matter so much here, one thing I prioritized from v1 was support for local LLMs, so users can keep memory processing entirely on-device if they want.

That said, this doesn’t fully solve the problem for cloud-model users, so features like automatically excluding password inputs or other sensitive moments from capture are already on the roadmap.

Naim Azoutar

congrats on your launch!

Tiger
Maker
@naimz Aww thank you!! πŸ₯Ή I’ve been working on this for a long time, so your support genuinely means a lot.
Akshaypal

The passive capture approach is what makes this architecturally different from most memory tools I've seen... instead of explicitly saving context like most MCP memory layers do, Contextberg just watches and builds it automatically. I've been thinking about this exact tradeoff while working on my own memory system: explicit memory gives you cleaner, more intentional retrieval but passive capture catches the stuff you'd never think to save yourself.

Curious how you're handling the signal-to-noise problem though.. screen and browser history is extremely noisy. Are you doing any relevance filtering before storing, or does everything go in and the retrieval layer handles pruning? Because in my experience with ChromaDB retrieval, garbage-in-garbage-out hits hard when the vector store gets polluted with irrelevant chunks.

Tiger
Maker

@akshaypal_bishnoiΒ Right now, I intentionally store everything.

If you filter before storage, you risk losing exactly the kind of unintended but important context you were talking about. So I treat the raw capture layer as immutable source data.

Then every hour β€” or every 15 minutes during active periods β€” Contextberg generates compressed short-term memories from that raw data. That gives me a cleaner first-order memory layer derived from the noisy source instead of relying directly on raw retrieval.

Currently, long-term memories are generated daily from those short-term memories.

But the bigger direction is:

- dynamically generating skills from merged short-term memories

- building a proper RAG layer on top of evolving memory structures

- eventually letting agents form reusable behavioral/context patterns automatically

So instead of pruning early, the idea is:

raw data β†’ compressed episodic memory β†’ structured long-term memory β†’ adaptive skills/RAG.

Nishu Kumari

Interesting idea, especially the focus on Windows developers since most AI memory tools seem Mac-first. One thing I’m curious about: how are privacy and data controls handled when Contextberg watches screens, browser history, and agent conversations? It would be useful to have very granular controls over what gets stored or excluded.

Tiger
Maker
@nishu_kumari02 Security is honestly the hardest part of building something like this. One reason I started with the Microsoft Store is exactly to build trust through platform review and distribution standards. (And also because Windows users are constantly getting left behind while everything becomes Mac-first 😭) Even today, users can already choose what should never be stored. For example, you can disable keyboard input capture or screenshots entirely. You can also turn recording off anytime you don’t want Contextberg watching. That said, I think automatic opt-out detection would improve the UX a lot, so that’s already on the roadmap πŸ™Œ
Binu George

Local-first with MCP is an interesting architecture choice, but there's a tension worth exploring: MCP servers are process-local, so when Claude Code or Cursor spins up a new session, it reads from Contextberg's MCP endpoint. Does the memory retrieval happen on every session start, or is it query-driven? And how do you handle the case where two different agents (say, Claude Code and Cursor running simultaneously) are both reading from the same memory store, Do they see the same context snapshot, or does Contextberg maintain per-agent memory streams?

Tiger
Maker
@binu_george Retrieval is query-driven. I recommend exposing memory access through callable skills/commands rather than automatically injecting everything at session start. Considering context window pressure, being able to fetch memory only when needed feels like the optimal approach. Connections to the shared memory store are handled per request, so there’s no real concern around conflicts or stale snapshots. Agents always fetch the latest state at retrieval time.
Avri Simon

The memory layer is where most multi-agent workflows actually fall apart. At ~120 engineers I saw juniors lose half their session time re-explaining context the prior session already had. MCP is the right wire-format choice. One thing I'd want to understand before adopting - if Contextberg watches the screen and browser, what's the redaction model when the screen has customer PII or a private repo open? Does memory scope per project, or does the team set explicit exclusions?

Tiger
Maker
@avrisimon The time loss becomes enormous when you look at it across the entire team. Right now, those kinds of exclusions/redactions are not implemented yet, but they’re planned on the roadmap. I think the first major step is allowing users to switch to enterprise-grade LLM APIs so the whole pipeline can become fully secure.
Tony Spiro

Persistent context across agent sessions is one of those things that sounds simple but completely changes what's possible, it's the difference between a smart tool and an actual teammate. The MCP approach is the right bet; curious how you're thinking about privacy boundaries for teams vs. individual devs.

Tiger
Maker
@tonyspiro I think it becomes a completely different thing once sessions persist across different agents β€” and once you layer the user’s actual work history on top of that. I also want to expand this toward team use cases over time. My idea is to separate it into privacy grades. Level 1: aggregate session-level memory into reusable skills. Level 2: integrate app usage history to systematize how top performers work. Level 3: integrate screen history to evaluate and model work patterns across all users. I expect Level 3 will face the most resistance, so I’m planning to build it gradually starting from Level 1.
Tony Spiro

@screenest_aiΒ The three-level privacy grade model is exactly right, and the gradient approach is smart. Level 3 resistance is predictable but I'd bet the teams that opt in early will have a compounding advantage that's hard to explain to the ones who didn't. The interesting design question at Level 2 is whether you systematize from the top performers down or let the system discover patterns bottom-up. Top-down is faster to ship, bottom-up is more accurate over time. Which way are you leaning?

Tiger
Maker
@tonyspiro Thanks, this question really helped me think deeper about the design. I’m leaning toward starting top-down, then gradually transitioning into bottom-up discovery. I think every company’s workflows become highly specific, so defining β€œwhat good looks like” purely from raw data would be difficult at the beginning. In that situation, it probably makes sense to first define strong patterns top-down, then use bottom-up signals to compare against those patterns, refine them, and sometimes even discover entirely new successful behaviors. I’m also curious how you approach team knowledge management on your side. I’ve been struggling with the incentive design part β€” getting people to actively systematize and structure knowledge is surprisingly hard.
Oliver Olibrice

Would this work with hyperagent by air table?

Tiger
Maker

@oliver_olibriceΒ I researched it a bit more, and it looks like Hyperagent can act as an MCP client.

So if that’s the case, I can pass basically all memory/context through MCP.

The only things I wouldn’t receive back from the Hyperagent side would be browser history, keystrokes, and screenshots.

Rosetta (Zidian) Guo

The five-sensor architecture is thoughtfully constructed, and I can see why each signal was included. The keystroke layer in particular raises an interesting design tension that I'd love to understand better.

Screenshots, browser history, app usage, and agent conversations already reconstruct a remarkably complete picture of work context. What specific inference does keystroke data enable that the other four sensors cannot provide? I ask because in my experience building internal activity trackers, the keystroke layer consistently became the most contested component in security reviews, even with exclusion rules in place.

I may be missing a nuance in how the keystroke signal gets processed or weighted against the visual and behavioral signals. Would be curious to hear how the team thinks about the marginal utility of keystroke capture relative to its privacy surface.

Tiger
Maker
@rosetta_zidian_guo The fact that this becomes a security discussion is exactly why I’m building this for individuals first. Also, screenshots alone are actually not enough to accurately follow user intent or focus. If you increase screenshot frequency, you quickly run into token pressure. And even with more screenshots, you still lack the context of what the user was actually typing and where. Keystroke signals solve that gap. Combined with the active window/app context, they make it possible to understand what the user was working on and generate much richer, more accurate memory. Of course, users can fully opt out of keystroke capture. But for personal use, I currently believe enabling it creates significantly better memory quality and continuity for AI agents.
12
Next
Last