DEV Community: Pranab Sarkar

I Gave Claude Code a "Phone a Friend" Lifeline — It Calls GPT, Gemini, and DeepSeek

Pranab Sarkar — Thu, 05 Mar 2026 21:05:56 +0000

Last week Claude Code was stuck on an architecture decision. Instead of going back and forth with one model, I thought — what if it could phone a friend? Or three?

So I built brainstorm-mcp, an MCP server that gives your coding agent a brainstorming team. Claude poses the question, GPT-5, Gemini, DeepSeek, and others each bring their perspective, then they build on each other's ideas across multiple rounds. A synthesizer distills everything into a consolidated recommendation.

It's not about picking a winner — it's about getting perspectives you'd never get from a single model.

How it works

You give it a topic: "Design the architecture for a next-gen AI-powered code review tool"
All models respond independently in Round 1 — diverse, unbiased first takes
In Round 2, they see each other's ideas and build on them, challenge assumptions, or offer alternatives
A synthesizer distills the best ideas into a final recommendation

Claude participates as a brainstormer with full context of your codebase, so the discussion is grounded in your actual code — not abstract advice.

Real example: AI code review architecture

I asked three models to design an AI-powered code review tool that goes beyond linting. Here's what each one brought to the table:

GPT-5.2 went deep on systems architecture — a full Temporal-orchestrated pipeline with a Repo Knowledge Graph, multi-pass LLM review (intent inference → local correctness → architectural reasoning → team alignment), and a feedback loop that learns from accepted/rejected suggestions. Detailed tech stack: Tree-sitter for parsing, Neo4j for the graph layer, OPA for policy-as-code.

DeepSeek focused on the data flow and learning loop — how the system should ingest PRs, build context packs from the dependency neighborhood, and gradually learn team conventions. Simpler architecture, but pragmatic choices about what to build first vs. defer.

Claude (with codebase context from my actual project) grounded the discussion — pointed out which components I already had, where existing CI pipelines could be reused, and which parts of the architecture were overkill for my scale.

The synthesis combined GPT's comprehensive systems design with DeepSeek's pragmatic sequencing and Claude's "here's what you actually need right now" reality check. 2 rounds, 75 seconds, ~11k tokens, $0.07.

Full debate output

What surprised me

Each model has a genuine personality. GPT goes wide and comprehensive — you'll get a 6-section architecture doc. DeepSeek favors elegant simplicity. Claude with codebase context catches things the others miss entirely. The value isn't in any single response — it's in the combination.

Round 2 is where the magic happens. Round 1 gives you breadth — independent first takes. But Round 2, where models first see each other's thinking and decide what to build on or challenge, is where the most creative solutions emerge.

Cheaper than you'd think. A full debate costs $0.02-0.07. Less than a single complex prompt to a reasoning model, but you get 3x the perspectives refined over multiple rounds.

Local models add real value. Running Llama via Ollama alongside cloud models adds diversity. They think differently — less polished but more willing to suggest unconventional approaches.

Setup

It's an MCP server, so if you use Claude Code, Claude Desktop, or any MCP client:

npx brainstorm-mcp

Add your API keys and you're done. Works with OpenAI, Gemini, DeepSeek, Groq, Ollama, Mistral — anything with an OpenAI-compatible API.

One more thing

While building brainstorm-mcp, I kept losing track of decisions and tasks across sessions. Claude would forget what we'd discussed yesterday. So I built saga-mcp — a Jira-like project tracker that runs as an MCP server. SQLite-backed, 31 tools, full hierarchy from Projects down to Subtasks. One tracker_dashboard call gives your AI agent full context to pick up where it left off.

Both are free, open source, MIT licensed.

brainstorm-mcp: GitHub | npm

saga-mcp: GitHub | npm

Why AI Agents Keep Forgetting Your Project (And How I Fixed It)

Pranab Sarkar — Mon, 23 Feb 2026 00:36:47 +0000

Every time I start a new session with an AI coding agent, the same thing happens: it has no idea what I was working on yesterday.

It doesn't know which tasks are done. It doesn't know we decided to use Redis for caching. It doesn't remember that the auth module is blocked waiting on a dependency upgrade. It just... starts fresh.

So I'd do what most people do — maintain a PROGRESS.md file. After every session, I'd ask the agent to update it. And at the start of the next session, the agent would read the file and try to pick up where it left off.

This worked fine for about a week.

The Markdown Problem

As the project grew, so did the file. 50 lines became 200. Status updates from three weeks ago sat next to current blockers. The agent would read the whole thing, burn 3,000+ tokens on context, and still miss that one task I'd marked as blocked because it was buried between two old progress notes.

The fundamental issue: I was using a text file as a database.

I needed queries ("what's blocked?"), not full-file reads. I needed structure (projects → epics → tasks), not flat bullet points. And I needed an audit trail that wouldn't bloat the context window.

Building a Project Tracker for AI Agents

So I built one. Saga is an MCP server that gives AI agents a local SQLite database for project tracking — think Jira, but designed for the way agents actually work.

If you're not familiar with MCP (Model Context Protocol) — it's a standard from Anthropic that lets AI tools talk to external services through typed tool calls. Claude Code, Claude Desktop, Cursor, and Windsurf all support it. Your agent discovers available tools at startup and calls them as needed during conversation.

Saga exposes 23 tools through MCP:

CRUD for a full hierarchy: Projects → Epics → Tasks → Subtasks
A notes system: For decisions, context, meeting notes, blockers — all typed and searchable
A dashboard: One call returns your entire project status — completion percentages, blocked tasks, recent activity
An activity log: Every change is automatically recorded with old/new values
A session diff: "Show me what changed since yesterday" — in one call

Everything lives in a single .tracker.db SQLite file. No servers, no API keys, no accounts.

How It Actually Works

Here's what a typical session looks like now.

Starting a new project:

Me: "Set up tracking for the e-commerce API"

Agent calls: tracker_init → epic_create (Auth) → epic_create (Catalog)
           → task_create (JWT auth) → subtask_create ([setup lib, create endpoint, add middleware])

Five tool calls. Project is structured with epics, tasks, and subtasks. All persisted to SQLite.

Resuming the next day:

Me: "What's the status?"

Agent calls: tracker_dashboard

One call. Returns:

{
  "stats": { "total_tasks": 12, "tasks_done": 4, "tasks_blocked": 1, "completion_pct": 33.3 },
  "blocked_tasks": [{ "title": "Add rate limiting", "epic": "Authentication" }],
  "recent_activity": ["Task 'JWT auth' status: in_progress → done", ...]
}

The agent immediately knows: 33% done, one task is blocked, auth epic is ahead of catalog. It can prioritize without me having to explain anything.

Recording a decision:

Me: "We're going with Redis for caching. Mark the research tasks as done."

Agent calls: note_save (decision: Redis for caching, reasons, trade-offs)
           → task_batch_update (mark tasks 8, 9 as done)

The decision is stored as a typed note, linked to the relevant epic. Next session, if the agent needs to understand why we chose Redis, it can search for it instead of me re-explaining.

The Token Math

This is the part that surprised me.

Saga's 23 tool definitions cost about 1,500 tokens in the system prompt. That's fixed — it doesn't grow with your project.

A tracker_dashboard call returns ~800 tokens of structured data. A filtered query like "show me blocked tasks" returns ~200 tokens.

Compare that to a PROGRESS.md file for a medium project: 3,000–5,000 tokens, loaded in full every session, growing over time.

The crossover happens at about 15–20 tasks. Beyond that, the structured approach scales better because the agent only retrieves what it asks for, not everything.

And unlike a markdown file, the data is queryable. "What did we decide about caching?" is a note_search call, not a full-file scan.

What's Under the Hood

For the technically curious:

SQLite with WAL mode — concurrent reads during writes, busy timeout of 5 seconds for lock contention
Foreign keys enforced — no orphaned tasks when you delete an epic (cascading deletes)
Append-only activity log — every create, update, and delete is recorded with field-level granularity
Parameterized queries with column allowlists — no SQL injection surface
MCP safety annotations on every tool — clients know which tools are read-only, destructive, or idempotent

The whole thing is ~1,400 lines of TypeScript. Two dependencies: the MCP SDK and better-sqlite3.

Session Diff: The Feature I Didn't Plan

After launching, someone on Reddit asked: "Can it show what changed between sessions?"

Good idea. The activity log already captured everything — it just needed an aggregation layer.

So I added tracker_session_diff. You give it a timestamp, and it returns:

{
  "total_changes": 14,
  "summary": { "created": 3, "status_changed": 4, "updated": 5, "deleted": 2 },
  "highlights": [
    "Task 'Fix auth bug' status: in_progress → done",
    "Created epic 'API v2'",
    "Note 'Sprint retro' deleted"
  ]
}

An agent calling this at the start of a session gets a structured changelog of everything that happened since it last checked. No parsing markdown diffs. No re-reading files.

Getting Started

Add this to your project's .mcp.json:

{
  "mcpServers": {
    "saga": {
      "command": "npx",
      "args": ["-y", "saga-mcp"],
      "env": {
        "DB_PATH": "/absolute/path/to/your/project/.tracker.db"
      }
    }
  }
}

That's it. Works with Claude Code, Claude Desktop, or any MCP-compatible client. The database file is created automatically on first use.

What I Learned

Building Saga taught me something about how agents actually consume information: they're better with structure than with prose.

A markdown file is optimized for humans scanning a document. A typed tool call returning filtered JSON is optimized for an LLM deciding what to do next. The agent doesn't need to "read" your project status — it needs to query it.

MCP makes this practical. The protocol handles tool discovery, typed schemas, and transport. All I had to do was put a database behind it.

If you're building multi-session agent workflows and finding yourself maintaining growing context files, consider whether that context should be a database instead.

Saga is open-source (MIT) and available on npm:

GitHub: https://github.com/spranab/saga-mcp
Install: npx -y saga-mcp