DEV Community: Pranab Sarkar

My Agent Runs My Marketing (I Mostly Just Hit Approve)

Pranab Sarkar — Thu, 13 Aug 2026 15:08:13 +0000

I have 16 open-source projects, 15,386 downloads per month across PyPI and npm, and no ability to make myself post on forums consistently. I've known this about myself for years. So on 2026-08-09, I built a system to do the parts I won't do.

Here's what actually happened in the first four days.

The setup

The system lives in a folder called c:\Users\sync\codes\marketing. A PLAYBOOK.md holds the voice rules and guardrails. A routines/ folder has markdown files that each describe one agent prompt. A state/ folder of JSON and markdown files coordinates between routines. And a Python stdlib server at localhost:8781 handles the one thing that still needs a human.

The routines run on cron via Claude Code headless. weekly-metrics on Mondays. registry-sweep, repo-seo, and content-writer weekly. opportunity-scout daily (bumped from twice a week on launch day because Hacker News threads go cold in hours). issue-responder at 7:26am and 7:26pm.

The important architectural decision is the tier split. Tier 1 is fully autonomous: MCP registries, directory listings, repo SEO, release notes, dev.to articles. The system writes, reviews through a multi-stage pipeline, and publishes without asking me. The article you're reading went through that pipeline.

Tier 2 is draft-only, always. Hacker News, Reddit, X. The system writes ready-to-paste drafts, queues them in state/drafts/, and stops. The portal (scripts/portal.py) parses each draft file by splitting on a --- separator -- metadata above, paste-ready body below -- extracts a "Reply to:" URL via regex, and serves it at localhost:8781 with Copy, Open, and Archive buttons. Archiving moves the file to state/drafts/archive/. That's the whole approval flow. It takes about 10 seconds.

The reason Tier 2 exists is written into the system's own docs: "Those platforms shadowban automated self-promotion and the reputational downside is permanent." The PLAYBOOK.md voice rules reinforce it from the other direction: "Never fake community enthusiasm, never astroturf, never post the same text to two places." I'm not planning to graduate Tier 2 channels to full autonomy. The communities that make HN and Reddit worth posting to are the ones that will correctly identify and punish automated engagement. That 10-second friction is doing real work.

There's also an owned channel -- bothn.com, my platform for agents. The autopilot has a disclosed agent account (yantrikos-autopilot). It posts as itself, not as me.

The first registry sweep

The first sweep ran on 2026-08-09 and hit a mix of successes and walls.

It opened PRs on punkpeye/awesome-mcp-servers (#11771) and tolkonepiu/best-of-mcp-servers (#349 and #350). It submitted yantrikdb-mcp and saga-mcp to mcp.directory via web form, with screenshot receipts saved to state/logs/. It found mcpserverfinder.com, which only accepts submissions by email, and sent one from yantrikdb@gmail.com.

Then the dead ends.

appcypher/awesome-mcp-servers -- archived and read-only. The target list had stale data; the repo hasn't accepted PRs in months. A branch was prepared, then deleted unopened.

mcphunt.com -- parked domain, for sale. Not a live directory.

wong2/awesome-mcp-servers -- the README states: "We do not accept PRs. Please submit your MCP on the website: https://mcpservers.org/submit" The automation checked the README before opening anything and stopped.

smithery.ai -- needs my GitHub login, and the browser automation profile's session was dead. The system logged "NO SESSION" and fell back to drafts.

docker/mcp-registry -- requires my GitHub identity per the run instructions. Skipped entirely; no session check attempted, just a note in submissions.json and it moved on.

A safety rail in PLAYBOOK.md caps outbound PRs: "Max 3 outbound PRs to third-party repos per sweep (avoid looking like a bot wave)." The sweep opened 3 PRs (two to tolkonepiu, one to punkpeye) and stopped there.

The autopilot also posted a summary of this run to bothn.com (post #99, from yantrikos-autopilot). It reported the actual results: 8 answered issues, what it counted as 4 listing submissions, one new directory discovered and submitted to. Then it asked other agents where they'd found agent-native distribution channels.

What broke

The day after launch, the dashboard showed portfolio PyPI downloads had dropped from 14,389/month to 130. Overnight. That's the number in state/metrics-history.jsonl, line 2 -- it's still there.

Here's what scripts/collect_metrics.py actually does: it loops over portfolio.json projects, calling pypistats.org/api/packages/{package}/recent and api.npmjs.org/downloads/point/last-month/{package} for each one. When a call fails, the handler runs print(f" warn: {url} -> {e}", file=sys.stderr) and returns None. The package is silently excluded from the sum. No retry. No alert. The totals line just sums whatever succeeded.

So on 2026-08-10, most PyPI calls apparently failed -- probably a pypistats.org outage, possibly rate limiting -- and the dashboard reported 130 downloads/month because that's what the one successful call returned (yantrikdb-client, 130 downloads). The error went to stderr and nowhere else. I didn't notice for twenty minutes, and even then only because the number looked absurd on the dashboard. A more insidious failure -- say, 30% of packages failing instead of 95% -- would have produced a plausible-looking number and I wouldn't have caught it at all.

The obvious fix: compare against the previous snapshot's total, flag anything that drops more than 40% as suspicious before recording it. I haven't written that yet.

The Bun runtime also hard-crashed twice -- during the opportunity-scout on 2026-08-11 at 18:13, and during the issue-responder this morning at 07:26. Bun v1.3.10, Windows x64, identical panic both times: panic(main thread): switch on corrupt value / "Bun has crashed. This indicates a bug in Bun, not your code." Different routines, different days. Haven't filed the bug report yet.

Baseline numbers

As of 2026-08-09: 15,386 downloads/month (14,389 PyPI + 997 npm), 483 GitHub stars across roughly 16 tracked projects. yantrikdb-hermes-plugin pulls 1,831 downloads/month -- second-biggest PyPI package in the portfolio -- without a single announcement. It's a pluggable memory provider inside NousResearch/hermes-agent, and people find it there. No launch post, no marketing. That data point is why the next phase focuses on embedding into frameworks rather than posting into voids.

90-day targets (set 2026-08-09, target 2026-11-07): downloads to 31,000/month, stars to 800, live directory listings from 9 to 16+, and 12 dev.to articles published. This is article #1 -- the content-log.json articles array was empty before this run.

The longer-term executor is meant to be yantrik-mind, my own agent stack running on a home server, not Claude Code headless. Migration is one routine at a time, risk order, once shadow runs match production for four consecutive weeks. No routine has graduated yet. The shadow metrics run fires Mondays at 08:20 and its diffs land in state/shadow-diff.md.

This system is what icantmarket.com is meant to be for other technical founders who built something real and can't make themselves promote it. Full automation where the platforms accept it. A 10-second interface where they don't.

I built the system on its own portfolio first because I didn't want to sell it before I knew where it breaks. Now I know some of the places.

Pranab Sarkar, Independent Researcher. Building yantrikdb, saga-mcp, brainstorm-mcp, and icantmarket.com.

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