DEV Community: Darshan K

I Gave My AI a Memory Graph — Then I Let It Block My Pull Requests

Darshan K — Sat, 04 Jul 2026 20:06:31 +0000

(Submission for the WeMakeDevs × Cognee "Hangover Part AI" Hackathon - Best Blogs Track)

Your AI coding assistant has amnesia. I gave mine a graph memory — and then I let it fail my Pull Requests.

Last week, Cursor suggested MongoDB for the fifth time. We migrated off Mongo three months ago. I snapped, opened a terminal, and built ProjectBrain.

ProjectBrain is a persistent memory layer for your codebase, built on Cognee and the Model Context Protocol (MCP). It doesn't just remember decisions locally for my IDE. I did something weird—I wired it to a real-time visualization dashboard and gave it veto power over my entire team's PRs via GitHub Actions.

Here is how I used Cognee's lifecycle to cure Context Rot.

The 4 Memory Verbs of Cognee

Cognee operates on a distinct lifecycle. We mapped each step to an MCP tool, allowing the IDE to command the graph directly.

1. `remember()`: Building the Context

When we make an architectural decision, we tell Cursor to save it. ProjectBrain ingests this into Cognee, extracting entities and building graph nodes in real-time. On our dashboard, you physically see a new node pop into existence.

2. `recall()`: Fetching the Context

When we ask a new question, Cursor queries ProjectBrain. Cognee uses a hybrid search (semantic similarity + graph traversal) to find relevant past decisions. Now, when I ask about transactions, it sees the explicit link between Mongo, the Double-Charge Bug, and Postgres.

3. `improve()` (Memify): Strengthening the Bonds

Not all memories are equal. Calling improve() in Cognee strengthens the edge weights in the knowledge graph. In our dashboard, you can see the graph edges literally shift from gray to bright cyan as feedback is reinforced.

4. `forget()`: Active Hebbian Decay

When a deprecated pattern is deleted, we tell ProjectBrain to forget it. We built an active Hebbian decay loop in our API: the nodes dissolve and fade out with a particle effect, and Cursor immediately stops hallucinating obsolete patterns.

The Climax: CI/CD God-Mode

Memory shouldn't just exist inside a single developer's IDE. If a decision is made, the entire organization needs to enforce it.

So, we built a headless CI/CD Enforcer using GitHub Actions. We wrote a secondary agent (reviewer_agent.py) that triggers on every Pull Request, parses the Git diff, and queries the same Cognee graph memory.

If a junior developer (or their AI) tries to sneak MongoDB back into the codebase, the CI agent detects the architectural violation and physically fails the pipeline.

The Results

By combining MCP with Cognee's graph capabilities, we achieved massive context gains:

Metric	Result
Cold recall latency	~180ms
Memory ingestion	~1.2s per decision
Hallucination reduction	14/15 test prompts accurate (vs 4/15 baseline)
Graph nodes at demo end	47 interconnected entities

We didn't just build a memory plugin. We built an organizational brain that enforces its own memory across the entire engineering team.

RAG gives your AI a library card. Cognee gives it a memory. ProjectBrain gives it a conscience.

Try it yourself:
Check out the open-source repo here: rushdarshan/brain
Deployed Dashboard: brain-production-3699.up.railway.app
Built for the WeMakeDevs × Cognee "Hangover Part AI" hackathon.

I Built a CLI That Caught 33,531 Tokens of Startup Bloat in My Agent Project

Darshan K — Sat, 11 Apr 2026 17:57:27 +0000

One afternoon I looked at my Claude Code agent and realized: I have no idea how many tokens load on startup. Skills scattered across .agents/skills/, global instructions in CLAUDE.md, reference files nobody asked for — it all adds up invisibly.

So I built trimr — a CLI that tells you exactly how much token bloat you have at startup, and automatically migrates your skills to a progressive-disclosure architecture.

The Problem

Your Claude Code agent loads every skill file on startup. All of them. Whether you need them or not.

Even a "lean" project can burn 30K+ tokens before you type a single message. But you can't see it, so you optimize in the dark.

What I Found in My Own Project

$ trimr audit ./my-agent

📊 trimr audit — ./my-agent
──────────────────────────────────────────────────
Skill files (21 found)
  Ungated (globally loaded):   21 skills    ~33,531 tokens at startup
  Vaultable:                   21 skills    eligible for migration

Startup token cost
  Current:                     ~33,531 tokens
  After migration:             ~2,100 tokens
  Reduction:                   93.7%

Violations (31)
  [WARN]  .agents\skills\adapt\SKILL.md       | Ungated skill eligible for migration
  [WARN]  .agents\skills\animate\SKILL.md     | Ungated skill eligible for migration
  [WARN]  .agents\skills\critique\SKILL.md    | Ungated skill eligible for migration
  [WARN]  .agents\skills\frontend-design\SKILL.md | Ungated skill eligible for migration
  ... 17 more

Run `trimr migrate ./my-agent` to auto-fix.
──────────────────────────────────────────────────

33,531 tokens. Gone before my agent processed a single word.

How It Works

The fix is progressive disclosure: instead of loading every skill at startup, you load a 100-token metadata stub (name + description). The full skill body only loads when the agent actually needs it.

Before migration:
  Agent starts → loads all 21 skills (33,531 tokens)

After migration:
  Agent starts → loads 21 metadata stubs (2,100 tokens)
  Agent needs "critique" skill → loads it on demand (2,468 tokens)
  Everything else: never loaded

trimr audit finds the bloat:

Ungated skills loaded globally
Oversized global instruction files (CLAUDE.md, AGENTS.md, .cursorrules)
Hidden system prompts in JSON/YAML/TOML configs
Malformed YAML frontmatter that breaks skill routing silently

trimr migrate auto-fixes it:

Moves ungated skills to .vault/skills/
Generates pointer files so the agent knows where to find things
Truncates bloated global files while preserving frontmatter
--dry-run shows exactly what will change before touching anything

Installation

pip install trimr

Try It

# See what you've got
trimr audit ./your-agent

# Preview the fix
trimr migrate ./your-agent --dry-run

# Apply it
trimr migrate ./your-agent

# Verify
trimr audit ./your-agent

Who It's For

Optimized for Claude Code and Cursor IDE projects using markdown-based SKILL.md files.

Not for Langchain/OpenAI/Anthropic Workbench — different architecture, different problem.

The Numbers

Before: 33,531 tokens at startup
After: ~2,100 tokens (21 skills × 100 token L1 metadata)
Reduction: 93.7%

These are real numbers from a real audit on my own project. Your mileage will vary depending on skill size and count — run the audit to find out what you're actually burning.

GitHub: https://github.com/rushdarshan/trimr

PyPI: https://pypi.org/project/trimr/

Built because token budgets matter and most people have no idea what they're spending at startup.