DEV Community: Daniel Nwaneri

Hi @ben . you liked this yesterday: https://dev.to/dannwaneri/the-loop-is-not-the-product-466d hours later Sloan flagged it as AI-generated. Your founder liked the piece. Your bot flagged it. Sloan isn't catching AI. It's catching good writing.....

Daniel Nwaneri — Wed, 10 Jun 2026 01:45:57 +0000

AI compute costs vs human labor

Daniel Nwaneri

Jun 9

The Loop Is Not the Product

#discuss #ai #webdev #productivity

6 min read

The Loop Is Not the Product

Daniel Nwaneri — Tue, 09 Jun 2026 14:35:13 +0000

A tweet landed on my timeline from Peter Steinberger — OpenClaw founder, now at OpenAI:

"Here's your monthly reminder that you shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."

He's right about the mechanic. He's not asking the harder question.

Before agents, we had cron jobs.

0 2 * * * ./process_reports.sh

That's the whole contract. Run at 2am. Do what you said. Fail loudly or silently. Nobody wrote a think piece about cron jobs disrupting knowledge work. Nobody raised a seed round on a well-tuned crontab.

But structurally? A cron job is a loop that prompts a process on a schedule. It just had the decency to be honest about what it was.

Cron jobs → Airflow → event-driven pipelines → agents. Each layer added adaptability and removed legibility. Cron is maximally legible. You can read the entire logic in one line. An agent doing "the same job" is a probability distribution with a system prompt and a credit card attached.

Now we've gone further. We have multi-agent systems. Specialist agents. Orchestrator agents that decide which specialist to call. Verification agents that check the output. Agents that self-correct when they fail.

And companies are quietly running the math and going pale.

Uber burned through its entire annual AI budget in four months. An NVIDIA vice president said publicly that AI computing costs now exceed employee labor costs. The FinOps Foundation's 2026 State of FinOps report found 73% of enterprises say AI costs exceeded original projections. Not a few bad actors. Not early adopters who didn't know better. Seventy-three percent.

The mechanism has a name now: the agentic loop multiplier. A simple query in 2023 cost $0.04 per interaction. A multi-step orchestrated agent workflow in 2026 costs $1.20 — thirty times higher. Gartner puts the range at 5-30x more tokens per task than the chatbot pilots that justified the budget. The ROI calculations that approved the deployment assumed chatbot-level consumption. The invoices arrived with agent-level reality.

A mid-level developer runs $80-120k. Fully loaded with benefits and overhead, maybe $250k. That sounds expensive until the token bill lands.

The human compounds. They learn your codebase, your culture, your shortcuts. They remember the decision you made last quarter and why. The agent starts fresh every session. Every morning you're paying for the same orientation meeting. Context reconstruction — re-reading docs, re-loading state, re-establishing what "done" means — isn't free. You're billing for memory the human already had.

The demo never shows you this. The demo is a single agent, single task, cherry-picked problem, running for 90 seconds while someone claps at a conference. The production reality is a fleet burning tokens on retries, tool calls that fail and get reattempted, coordination overhead between agents nobody budgeted for.

You've built a bureaucracy. A token-denominated bureaucracy with no union and no lunch breaks and no salary cap.

Back to Steinberger's tweet.

"Designing loops that prompt your agents" is a real architectural upgrade over manual prompting. If you're still narrating every step to an agent like you're dictating to a secretary, the loop is the upgrade. Prompts from state — test results, diffs, error logs — not from you typing.

But designing the loop is just procrastination with better posture if there's no customer at the end of it.

Because someone still has to decide what the loop optimizes for. What "done" looks like. When to break. What counts as a failure worth stopping for. That's not automation — that's system design with higher stakes, because now the mistakes compound before anyone sees them.

And "designing loops" is genuinely hard in a way prompting isn't. Most people who can write a good prompt cannot design a feedback loop with appropriate exit conditions, cost governors, and human checkpoints. The tweet makes the upgrade sound like switching from tabs to spaces. It's closer to switching from writing functions to designing distributed systems.

What I want to know: what breaks in the loop that a prompt would have caught? Every abstraction hides something. Prompting hides scale. Loops hide drift. At some point the agent has been running for six hours optimizing a metric nobody remembers choosing, and the loop is beautiful and the output is garbage.

Here's what nobody in the agent hype cycle wants to sit with:

The old model had a forcing function built in. You shipped, a human used it, something broke, you fixed it. Feedback was physical. A user opened a ticket. A client called. Reality interrupted the loop.

Agents don't have that governor. The loop is the product. And when the loop is the product, you can optimize indefinitely without ever confronting whether the output matters.

Token burn becomes a proxy for progress. Iteration velocity becomes a stand-in for value creation. The agent looks productive because it never stops — but stopping is exactly what would force the question.

Autonomy used to mean delegated judgment. You trust someone to make calls because they understand the goal and can feel when something's off. What most agents have is delegated execution. They can do the steps. They have no stake in the outcome, no access to the silence that follows a bad result, no way to know the customer churned three weeks later because the feature was technically correct and completely wrong.

Automate the tedious middle of a known, stable process. Data pipeline, alert triage, code linting, content reformatting. Stuff where the definition of done is actually defined. That's real. That's useful. A cron job with taste.

The inflated version — the one burning the tokens — is the agent as a substitute for product thinking. If you don't know what to build, an agent that builds constantly feels like momentum.

It isn't. It's expensive randomness with good logging.

Consider Spotify.

A company that built its entire brand on one rule: only ship what users ask for. Feature requests drove the roadmap. That's it.

Then AI became mainstream and the calculus changed publicly. Spotify's workforce went from 7,721 employees at the start of 2024 to 7,242 by Q3 — shrinking every quarter while revenue grew 19% year over year. Their filings note it plainly: profitability driven by "lower personnel and related costs." They're doing more with fewer people. The numbers look good on a slide.

But nobody's asking the follow-up question. The features that built Spotify's loyalty — Discover Weekly — came from people who understood the product, the listener, the culture of music discovery. Accumulated judgment. What does the agent fleet ship? What user asked for it? What happens when "only build what users want" gets replaced by "ship what the loop produces"?

We don't know yet. The invoices look better. The product debt is still accumulating.

I built seo-agent — an open-source SEO audit agent using Python, Browser Use, Claude API, and Playwright.

I could leave it burning tokens 24/7. I didn't. Not because of the money. Because I couldn't answer the basic question: what would it actually be doing?

I wired a cron job to run it on schedule. It analyzes logs. It surfaces what's broken. Then I look at the output, decide what matters, and go into my codebase with Claude Code to write the fix and the test. The agent handles the tedious middle. I handle the judgment at the edges.

Call that old fashioned. I'd call it honest.

The loop runs. But it runs to me. Not into a void.

My Bookmark Brain — a RAG system trained on 50,000 of my own X bookmarks — flagged this pattern when I showed it the tweet:

"Designing the loop is just procrastination with better posture if there's no customer at the end of it. Automated nobody is still nobody."

The stack was never the problem. It was always the most comfortable place to hide from the problem.

Cron jobs ran quietly and failed loudly. Agents run loudly and fail quietly. The failure is just spread across enough API calls that the bill arrives before the reckoning does.

Design better loops. Ship to someone who asked.

This article used AI tools for research verification and editing.

I built a tool to stop Claude from forgetting everything then forgot about it myself

Daniel Nwaneri — Wed, 03 Jun 2026 14:45:42 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

I wired edge-context-mode into my own Claude Code setup. Then I stopped using it. Not because it didn't work — because I didn't understand what I'd built.

Six weeks later, this challenge made me come back. What I found: a tool that was half-finished, a Durable Object secretly lying to me, and — when I finally looked at the code honestly — something actually worth finishing.

What I Built

The problem is simple to describe and annoying to live with.

You start a session with Claude. You read a file, run a command, ask a question. Twenty minutes in the answers get worse. Forty minutes in it's forgotten the context. An hour in you're hitting limits and starting over.

The cause: raw output floods the context window. A cat on a 500-line file puts 500 lines in context. npm list adds 200 more. git log adds more. The context fills with output the LLM will never reference again, and the things that actually matter — decisions, architecture, what you chose and why — get pushed out.

edge-context-mode intercepts that:

Normal:        cat large-file.ts  →  500 lines flood into context
edge-context:  ctx_execute(...)   →  [ctx:ab3f9x] + "12 line(s): interface User..."

The raw output goes to Cloudflare D1 at the edge. The LLM gets a reference token and a 50-word summary. Context stays clean. Sessions stay coherent.

Search is hybrid: D1's FTS5 gives you BM25 keyword matching out of the box. Pair it with vectorize-mcp-worker — another tool I built — and ctx_search runs semantic vector search on top. Same stored data, same reference tokens. The retrieval layer just gets smarter.

That's the design. What was actually shipped in April was a different story.

This directly solves the compaction problem

If you've used Claude Code for a long session, you've probably seen this:

"Anyone else notice that compaction seems to lose more details than normal? It never seemed to matter before, but I'm seeing it frequently now."

That's the same problem, one layer up. When Claude Code hits context limits, it compacts — auto-summarises the conversation to make room. The details that disappear are the exact things that matter: error messages from 30 minutes ago, what was tried and failed, the architectural choice that explains why the code looks the way it does.

They disappear because they were sitting raw in the context window. Compaction summarises them aggressively and the specifics are gone.

edge-context-mode attacks this in two ways. First, prevention: every ctx_execute call keeps raw output out of the context entirely — only a 50-word summary and a reference token go in. Less in context means compaction triggers less often. Second, survival: everything stored via ctx_execute and ctx_annotate lives in D1, outside the context. Compaction can't touch it. After compaction wipes your conversation:

ctx_history(session_id: "myproject-2026-05-22")
→ full chronological list of everything that happened, pulled from D1

ctx_reflect(session_id: "myproject-2026-05-22")
→ "Session has 14 entries over ~47 min. Fixed D1 FK constraint, added
   ctx_get tool, updated README, decided 512KB cap on raw_output..."

The session memory didn't compact. Only the conversation did.

The same day I wrote this, this appeared on X:

@ankkala: "There should be an entire new class of LLM dedicated just to compaction." My reply: "Compression without loss is the oldest hard problem in cognition. Summarization fails the same way bad thinking fails — not because the words are wrong, but because the underlying structure was never identified in the first place. A specialized compaction model doesn't fix that. It just obscures where the reasoning broke down."

The argument for a dedicated compaction model assumes the problem is compression efficiency. It isn't. The problem is that the wrong things are in the context in the first place. A better compressor produces confident-sounding summaries of the wrong things. edge-context-mode doesn't make compaction smarter — it reduces what has to be compacted at all.

One caveat, now partially lifted: edge-context-mode is an MCP server. When I wrote this it was wired only into Claude Code. By the time I finished, I'd registered it in VS Code and GitHub Copilot discovered all 8 tools automatically — same server, zero changes to the code. ChatGPT and Gemini still require function-calling adapters (v1.1). But "Claude Code only" undersold it from the start.

Demo

GitHub: https://github.com/dannwaneri/edge-context-mode
Release: https://github.com/dannwaneri/edge-context-mode/releases/tag/v1.0.0

Local setup — 4 commands, no cloud account:

git clone https://github.com/dannwaneri/edge-context-mode
cd edge-context-mode
npm install
npm run migrate:local
npm run local

claude mcp add edge-context-mode -- node /path/to/edge-context-mode/src/local.ts

What a session looks like now:

# Run a command — only a reference token enters context
ctx_execute("node -e \"require('./package.json').dependencies\"", "check deps")
→ [ctx:kx92ma3b1p]
→ 1 line(s): { hono: '^4.7.11', '@modelcontextprotocol/sdk': '^1.12.0'...

# Need the actual output? Pull it by reference
ctx_get("[ctx:kx92ma3b1p]")
→ ref:     [ctx:kx92ma3b1p]
→ summary: 1 line(s): { hono: '^4.7.11'...
→ --- raw output ---
→ { hono: '^4.7.11', '@modelcontextprotocol/sdk': '^1.12.0', ... }

# Save a decision without running a command
ctx_annotate("decided to cap raw_output at 512KB — D1 row limit is ~1MB, leaving headroom")
→ [ctx:mw71nx4d2q]

# Search past context semantically
ctx_search("D1 storage decisions")
→ [ctx:mw71nx4d2q] [score:1.84] annotation: decided to cap raw_output at 512KB...

# Health check
ctx_doctor
→ { "d1": "ok", "execution_mode": "local-stdio", "vectorize_mcp": "configured", "sessions": 6, "entries": 9 }

The Comeback Story

On April 15th, I shipped the initial release. Two commits, deployed to Cloudflare, wired into my own setup. Then I moved on.

Coming back for this challenge, I read the code properly for the first time. Here's what was actually there.

The Durable Object was returning a placeholder.

This is the one I'm most embarrassed about. ExecutorDO.ts — the Cloudflare Durable Object that was supposed to sandbox execution in Workers mode — had this in production:

return {
  stdout: `[DO received: ${command} ${args.join(" ")}]`,
  exit_code: 0,
  timed_out: false,
};

If you deployed to Cloudflare Workers and called ctx_execute, you'd get back a fake success. No output. No error. Just a quietly wrong result. I'd left a comment: "integrate with a Workers AI function or trusted external runner" — and never did it.

The fix wasn't to build the external runner. Cloudflare Workers genuinely cannot spawn subprocesses, and building a remote execution service in two weeks isn't the right call. The honest fix was to say so: replace the silent stub with a clear error that tells you exactly what to run instead.

ctx_get didn't exist.

The entire architecture depends on [ctx:id] references being retrievable. Store a summary, get back a token, pull the original when you need it. That was the design. There was no tool to do the pulling. Every reference was write-only. I'd built half a memory system and hadn't noticed.

Added ctx_get — strips the [ctx:] prefix, queries D1 by ID, checks expiry, returns the summary and raw output. If it's gone: "Entry not found or expired." No crash, no drama.

ctx_annotate didn't exist either.

Context only accumulated through ctx_execute — shell commands. You couldn't save why you made a decision. You couldn't annotate an architectural choice. You couldn't store a note without wrapping it in a fake command. The tool only captured what you ran, not what you thought.

Added ctx_annotate — takes text, stores it as type: "annotation", shows up in ctx_search and ctx_history. The session history now reflects intent, not just execution.

Raw output was never stored.

There's a comment in the original schema that says exactly this: "raw output is NEVER stored here — only the summary." Deliberate design. The problem: ctx_get needs something to return. You can't have a retrieval tool with nothing to retrieve.

Migration 0002_raw_output.sql recreates the table with a raw_output TEXT column and an updated CHECK constraint to include annotation as a valid entry type. Full stdout now stored in D1, capped at 512KB. Old entries retain NULL gracefully.

Setup required three services before anything ran.

The original README listed as prerequisites: Cloudflare account with Workers Paid plan, a D1 database, and a separately deployed vectorize-mcp-worker. Three services, three secrets, before the server would start. Most people would give up at step two.

Local mode now works with zero cloud setup. Four commands. The vectorize-mcp-worker is an optional semantic search upgrade — worth deploying once you're running sessions regularly, but not a requirement to get started.

ctx_search had a silent phrase-matching bug — found it live.

This one I found after v1.0.0 shipped, while testing the tools in a real session. I stored an annotation, then searched for words I knew were in it: "Vectorize optional". No results.

The bug was in ftsPhrase() in store.ts. It wrapped the entire query in double quotes:

// Before — strict phrase search
return `"${q.replace(/"/g, '""')}"`;
// "Vectorize optional" only matches if those two words are adjacent

The annotation text said "Vectorize **stays* optional"*. One word between them. No match.

The fix: quote each term individually so FTS5 treats them as implicit AND — all terms must appear in the document, anywhere, not consecutively:

// After — per-term quoting
return q.trim().split(/\s+/).filter(Boolean)
  .map(word => `"${word.replace(/"/g, '""')}"`)
  .join(" ");
// "Vectorize" "optional" — matches regardless of what's between them

Special-char safety (hyphens, numbers) preserved. Fixed and shipped as a post-v1.0.0 patch the same day.

The migration runner was silently wiping all data on every restart.

This one I found after the article was mostly written, while investigating why ctx_get returned (raw output not available) on every annotation.

The migration runner in local.ts used a try/catch pattern:

try { db.exec(sql); } catch { /* already applied */ }

The assumption: if the SQL fails, the migration was already applied. The problem: migration 0002 starts with DROP TABLE IF EXISTS context_entries. IF EXISTS never throws — so the catch never fires. Every server restart ran 0002 from scratch, dropping the entire context_entries table and recreating it empty. All stored context wiped. Silently.

The fix: a _migrations table that records each .sql file by name. On startup, already-applied files are skipped entirely:

db.exec(`CREATE TABLE IF NOT EXISTS _migrations (name TEXT PRIMARY KEY, applied_at INTEGER)`);
// ...
const already = db.prepare("SELECT 1 FROM _migrations WHERE name = ?").get(f);
if (already) continue;

Data now survives restarts. This is the kind of bug that only shows up when you actually use the thing — not in tests, not in code review, only when you store something, close the terminal, reopen it, and find nothing there.

My Experience with GitHub Copilot

I want to be honest here because vague Copilot praise is exactly what's eroding trust in challenge submissions right now.

The code work in this finish-up — the migration, the new tools, the server fixes — I did with Claude Code. Copilot was where the project had been failing silently since April: tests.

vitest was in package.json from the initial commit. Zero tests had ever been written. I'd been aware of this the way you're aware of a leak you haven't fixed.

I opened src/tools/executor.ts in VS Code and gave Copilot Chat this prompt:

"Write vitest unit tests for the validateCommand function in this file. Test: a whitelisted command like 'node' passes, an unknown binary like 'rm' is rejected with COMMAND_NOT_ALLOWED, a path traversal attempt with '../etc' is blocked, and a git subcommand not in the allowlist is rejected."

Copilot opened package.json to check the test configuration, created executor.spec.ts (+51 lines), ran npm test --silent to verify, and reported back: "Tests added and run: all 4 passing." The agentic loop — read config, write file, run tests, confirm results — without me prompting each step.

Then I asked it to look at summarise for missing coverage. It came back with eight specific edge cases: empty output, whitespace-only lines, Windows line endings where \r could leak into summaries stored in D1, lines with leading spaces, the SUMMARY_MAX_CHARS boundary, mixed empty and non-empty lines.

The Windows one stopped me. I'm on Windows. \r\n line endings are something I live with and had completely stopped thinking about. A summary with a trailing \r stored in D1 and returned to the LLM is a subtle, real bug I would not have found on my own.

That's what honest Copilot use looks like. It found what I'd been ignoring and made me own it.

Post-Publication: It Runs in GitHub Copilot Too

After the article went live, I added two lines to .vscode/mcp.json and restarted VS Code. GitHub Copilot discovered all 8 tools automatically.

Same server. Zero code changes. The claim that this is "Claude Code only" was wrong the moment MCP support shipped in VS Code.

The .vscode/mcp.json config:

{
  "servers": {
    "edge-context-mode": {
      "type": "stdio",
      "command": "cmd",
      "args": ["/c", "C:\\path\\to\\edge-context-mode\\start-mcp.cmd"]
    }
  }
}

What's Next

The question I keep getting: can this work outside Claude Code?

Already answered: Cursor, Windsurf, Claude Desktop, GitHub Copilot in VS Code — anything that speaks MCP works today. "Claude Code only" was underselling it from the start.

Genuinely universal requires one more step: function-calling adapters for OpenAI and Gemini. The storage layer — D1, FTS5, the reference system — doesn't change at all. Same data, same search, same [ctx:id] tokens. You'd just expose the tools as OpenAI function definitions or Gemini tool declarations instead of MCP tool registrations.

The Workers HTTP mode is already the bridge. Any LLM with tool/function calling can hit the deployed endpoint directly if you wire up the schema on their side.

The seamless part — where raw output is automatically kept out of context before you even think about it — still requires the client to route through edge-context-mode. MCP does that natively. For non-MCP LLMs you'd call ctx_execute manually instead of running commands directly. Less automatic. Still useful. The memory survives either way.

That's v1.1: OpenAI and Gemini adapters, same core, no storage changes. If you're building on a different stack and want to help, the repo is open.

One more gap worth naming: you can't retroactively capture a session that started before edge-context-mode was running. If you worked for an hour before registering the MCP server, that context lived in the Claude Code conversation window only — edge-context-mode never saw it.

The workaround right now is ctx_annotate — manually summarise what happened before the tool was active. It works but it's manual.

I tested this on the very session in which I'm writing this article. It hit context limits once, compacted, and continued. I opened the .jsonl file, found the compaction summary (stored as a type: "user" entry with isCompactSummary: true), and ran one ctx_annotate call:

ctx_annotate("SESSION IMPORT (finishupathon, 2026-05-22) — edge-context-mode v1.0.0 decisions:
ExecutorDO stub → honest error. ctx_get added. ctx_annotate added. raw_output migration.
Local mode: 4 commands, zero cloud. ftsPhrase() per-term fix.")
→ [ctx:8wo1rh1buy]

One compaction, one call. That context is now in D1. If this session compacts again tomorrow, ctx_search("edge-context-mode v1.0.0") will surface exactly what was decided and why.

The proper fix: Claude Code stores every session as a .jsonl file in ~/.claude/projects/. Full conversation, every tool call, every output. A ctx_import command that reads those files and bulk-loads them into D1 would close the gap completely — retroactive context, searchable, surviving all future compaction. The storage layer already handles it. It just needs a reader for the .jsonl format (compact summaries are the isCompactSummary: true entries) and a bulk insert path. That's v1.2.

Built with TypeScript, Cloudflare Workers, Durable Objects, D1, and a belated appreciation for what I'd actually made.

Google Is One Feature Away From Killing an Entire Startup Category

Daniel Nwaneri — Tue, 02 Jun 2026 08:14:41 +0000

I use NotebookLM as an attack layer before I publish anything.

Not for summaries. Not for research. I upload my draft, let the audio overview run, and listen to two AI hosts interrogate my argument. If the narration exposes a gap — a claim that doesn't land, a section that wanders — I go back and fix it before the article goes live.

It works. Better than re-reading. Better than asking a colleague. The distance of hearing your argument spoken back at you by something that doesn't share your assumptions is genuinely useful.

One thing is missing.

The voice. My voice.

What NotebookLM already does

The hard problems are solved.

NotebookLM ingests PDFs, Google Docs, audio files, YouTube links, and web URLs. It grounds its narration in your sources — it doesn't hallucinate beyond them. It produces coherent two-host audio that actually sounds like a conversation, not a text-to-speech dump. It maintains source fidelity across long documents.

These are not small engineering problems. Source grounding alone eliminates an entire class of failure that plagues every generic AI summarizer. The coherence of the narration — the way the two hosts disagree, interrupt, and redirect — required significant work to build.

Most people use it to summarize research papers. Some use it for meeting notes. I use it to stress-test arguments before they're public.

What nobody is talking about: Google solved the hard part already.

The one feature that changes everything

Personalized voice.

Not a voice clone of a podcast host. Not a generic British narrator. Your voice. Trained on your recordings, matched to your cadence, deployed on your content.

The moment Google ships that, three things happen simultaneously:

Audio overviews stop sounding like someone else reading your work. They start sounding like you, presenting your argument, in your register. The use case expands from "summarize this" to "publish this." And every startup selling AI-powered personal audio becomes a feature comparison in a product Google already owns.

The countdown timers

Let's name them.

ElevenLabs built a genuinely impressive voice cloning product. The quality is real. The API is well-documented. Developers use it. But ElevenLabs' core value proposition — "your voice, anywhere" — is exactly what Google would ship as a NotebookLM toggle. Not a new product. A settings page.

Podcastle sells AI-powered podcast creation with voice cloning and audio cleanup. It's a prosumer tool aimed at creators who want professional audio without a studio. It's also a collection of features that sit inside what NotebookLM already does structurally, minus the voice layer.

Wondercraft is an AI audio platform for turning written content into audio. Good product. Direct overlap with NotebookLM's architecture. One product update away from redundancy.

Descript is the most defensible of the group — it has a video editing layer, a timeline, a collaboration workflow. It isn't purely an audio generation tool. But its AI voice layer, "Overdub," is exactly the feature that would become noise the day Google ships personal voice to NotebookLM.

None of them are bad products. That's not the argument.

The argument is that their moat is a gap Google hasn't prioritized filling. That's a countdown timer, not a competitive advantage.

The Google tax

This pattern has a name. Developers who've been around long enough know it.

Google Workspace has a task manager. It's called Tasks. It's fine. Todoist, TickTick, and Things 3 all exist because Tasks is fine and not great, and "fine" left a gap big enough to build companies in.

Google Calendar handles scheduling. Calendly became a $3 billion company because Calendar doesn't do one specific thing — let other people book time in your calendar without an email thread. One feature. Entire company.

Google Keep exists. Notion exists anyway. The overlap is real; the gap was real enough to matter.

Some of these survive. Calendly survived because the booking workflow is genuinely distinct from what Calendar does natively. Notion survived because it expanded beyond the gap — documents, databases, wikis — before Google closed it.

The AI audio startups don't have that runway. They're not building adjacent to NotebookLM. They're building inside it. Their entire value proposition sits in the gap between what NotebookLM already does and the one feature Google hasn't shipped.

Why Google probably won't ship it next quarter

Let's be honest about the timeline.

Google is not aggressively pursuing this. NotebookLM is a Google Labs product — impressive, genuinely useful, and clearly not the company's primary focus. The team is small relative to the broader Gemini push. Personal voice cloning has real regulatory and ethical baggage — deepfakes, consent, liability — that slows any large company down in ways a startup can ignore.

The AI audio startups might have 18 months. Maybe 24.

But here's the thing about building on a platform gap: the clock isn't running on whether Google ships it. The clock is running on whether the market believes Google will ship it. The moment that belief takes hold — a Google I/O demo, a leak, a product page — the fundraising environment for AI audio personalization startups changes overnight.

They're not being hunted. They're being ignored.

Ignored by Google is its own kind of death sentence.

What this actually means for developers

If you're building in this space, the question isn't "can we build a better voice cloning product than ElevenLabs?" The question is: "What does this product do that would survive a Google I/O keynote?"

The companies that survive the Google tax survive it by expanding beyond the gap before it closes. Calendly survived by becoming a scheduling platform — reminders, routing, integrations — not just a booking link. Notion survived by becoming a workspace, not just a note-taking tool.

AI audio startups that survive will be the ones that embed voice into a workflow Google doesn't own. Video production pipelines. Podcast distribution. Live audio. Language learning. The ones that build deep into a workflow Google has no reason to touch.

The ones building "NotebookLM but with your voice" are the countdown timers.

I still use NotebookLM every time I publish. I still listen to two AI hosts interrogate my arguments while I cook.

I just do it in someone else's voice.

For now.

What Building My Own AI Bot Taught Me About Generative AI

Daniel Nwaneri — Wed, 27 May 2026 19:57:35 +0000

I built a bot trained on my own X bookmarks and likes. Around 50,000 of them, accumulated over years of lurking, arguing, and clicking the save button on things that made me stop scrolling.

The technical part isn't complicated in principle. You pull your export, embed the text, build a RAG pipeline, add a style prompt derived from your own writing patterns, and you get something that responds to prompts by retrieving your most relevant saved content and riffing from there. I called it Bookmark Brain, which is either clever or embarrassing — I haven't decided.

What I didn't expect was how much it would clarify my thinking about what generative AI actually is.

The bot works too well. That's the problem.

When I ask it about API design opinions or takes on the current AI hype cycle, it returns something that sounds like me — specific, slightly annoyed, grounded in a particular set of concerns — better than most general-purpose LLMs do when I prompt them with "write in my voice." The difference isn't the model. It's the retrieval layer. The model in both cases is doing the same approximate thing. What changes is what it retrieves before it starts generating.

That realization landed harder than I expected: a significant chunk of what we call AI "intelligence" is retrieval. The system finds related content, mixes it with the query, and produces output shaped by that specific neighborhood of the embedding space. It's not thinking. It's not understanding. It's doing something closer to extremely sophisticated autocomplete with a memory. The illusion of reasoning comes from the quality of what was retrieved, not from inference happening in any deep sense.

The uncomfortable follow-on: I started noticing the same thing in myself. A lot of what I'd been calling original thinking was my brain doing something structurally similar — retrieving from a curated internal dataset of influences, combining them in ways that felt novel, outputting with enough fluency to pass as insight. The bot didn't make me feel smarter. It made me suspicious of my own cognition.

My bot sounds coherent because my bookmarks are coherent. I've spent years curating a specific worldview — skeptical of tech hype, interested in systems and incentives, irritated by vague abstraction. That worldview is baked into the dataset. Retrieval finds it. The model outputs it in grammatical sentences. The whole thing looks like intelligence from the outside.

Then the Granta thing happened.

If you missed it: Granta, the literary magazine, ran a piece flagged by AI detectors. Turns out the writing was human — and older than the detectors themselves. Pre-2022, written before the tools they were being assessed with even existed.

The writer, understandably, was furious. The editorial response was clumsy. What struck me was the confidence behind the process — the idea that a detector score constitutes evidence of anything meaningful.

It doesn't. AI detectors are probabilistic classifiers trained on distributional differences between human and AI writing. Dense, formal, or unusual prose trips them constantly. Academic writing, translated text, anything with a compressed or structured style — all of these get flagged. The detector isn't reading. It's pattern-matching statistical features. And those features shift as models improve, as writing styles evolve, as the gap between the training distribution and current reality widens.

Watching publications, employers, and universities lean on these tools as if they're reliable is the same energy as relying on a polygraph. The tool isn't detecting deception. It's detecting nervousness, or formality, or the wrong register for the context. The conclusion isn't what the tool thinks it is.

What the Granta situation made concrete for me: we have a collective problem with mistaking a signal for the thing the signal supposedly measures. Perplexity score is not authenticity. Semantic similarity is not understanding. And this is the same confusion that inflates most AI capability claims.

Here's the irony I live with every day.

I use AI heavily. I build with it, write with it, prototype faster because of it. I'm not performing skepticism while secretly relying on it — I'm actually relying on it, out in the open, and also genuinely skeptical of what it's doing and why the claims around it are so often overconfident.

Yes, I'm part of the problem. I know that. But I built Bookmark Brain precisely because I wanted to understand what the problem actually is — not at the level of takes and op-eds, but at the level of retrieval logs and embedding distances and why a particular output came out the way it did. The people most confident about AI — evangelists and critics alike — are usually the ones who haven't built anything with it. They're responding to the outputs. I wanted to see the pipes.

My bot makes this concrete in a specific way. Because I can see exactly what it's doing — retrieve, compose, style-match — I can no longer pretend the underlying process is mysterious. It isn't. It's a very good pattern engine. And the patterns it's good at are the ones humans have already made enough times to constitute a retrievable signal.

The things it can't do are equally clear. It can't tell me something genuinely new. It can't resolve contradictions in my bookmarks; it just retrieves whichever side of an argument is more semantically proximate to my query. It has no persistent sense of what I care about most — that's in the embedding weights and the retrieval ranking, not in anything like a value structure. If I've saved content across five years on Nigerian economic policy, it can retrieve that content. It cannot tell me what I should think about a new development that doesn't yet exist in those embeddings.

That's not a criticism. It's just an accurate description of what the tool is. The criticism is when people — including, honestly, past me — talk about these systems as if they're operating at a different level entirely.

Most people initially misunderstand generative AI the same way. They see the output and map it to human cognition because that's the only reference frame available. The output sounds like thinking. Therefore it is thinking. The logic is understandable and wrong.

What's actually happening is closer to: the system has compressed a large representation of existing human expression, retrieves the most contextually relevant parts, and generates a continuation that's statistically consistent with that neighborhood. That's not nothing. In fact it's remarkable. But it's not reasoning. It's not understanding. And it absolutely is not reliable in domains where the training distribution doesn't match the actual problem.

Building Bookmark Brain made this concrete rather than abstract. I could watch the retrieval logs. I could see what it was pulling. I could trace why a particular response came out the way it did. That transparency — available only because I built it — is exactly what's missing when people interact with closed systems and anthropomorphize the outputs.

The piece of this I'm still sitting with is about curation.

My bot is useful because I curated carefully for years. The quality of the output is downstream of the quality of the input — not the model, not the prompt engineering, the input. 50,000 bookmarks that reflect a consistent set of concerns, an identifiable worldview, real opinions.

If I'd bookmarked everything uncritically, the bot would be incoherent. Garbage in, garbage out, but at scale and with a convincing fluency that would make the garbage harder to spot.

That's the thing about generative AI broadly: it doesn't make bad data good. It makes it fluent. And fluency is exactly the property that makes it hard for people — including detectors, including reviewers, including people who should know better — to evaluate what's actually in front of them.

I built a tool that sounds like me. It works because of what I put into it, not because of anything the model does that's particularly special. The model is a compositor. The dataset is the author.

That's the most clarifying thing I've learned. It's what almost every discussion about these systems gets wrong.

Toward a Standard Model for Agent Memory

Daniel Nwaneri — Tue, 26 May 2026 17:29:36 +0000

Most agent memory systems are digital attics.

You put things in. You hope to find them later. You mostly don't. The retrieval is fuzzy, the context is lost, and the agent that needs to remember why a deployment failed three weeks ago gets back something that looks related but carries none of the causal weight.

This is the wrong mental model for memory. Not because the retrieval is bad — though it often is but because storage is the wrong frame entirely.

If memory is storage, you're building a place things go to accumulate. If memory is infrastructure, you're building something load-bearing. Agents depending on memory for causal context — why this failed, what fixed it, how that decision connected to this outcome — need load-bearing infrastructure. Not a warehouse. A power grid.

The difference is consequential. Storage fails silently. You put something in and nothing comes out, or something wrong comes out, and the agent keeps going with degraded information it can't see is degraded. Infrastructure fails loudly, because the system depending on it stops working. Load-bearing memory makes failures visible. That's not a downside. That's the point.

I've been building production agent workflows on Cloudflare Workers for two years, long enough to feel this distinction in concrete terms. The vectorize-mcp-worker — hybrid vector + BM25 search, cross-encoder reranking, a Gemma 4 MoE reflection layer — started as a storage system. Every architectural decision I've made since has been moving it toward infrastructure. That shift didn't happen all at once. It happened because the storage model kept producing the same failure: agents that couldn't distinguish between what looked relevant and what caused the thing they were trying to understand.

A comment thread on Ken Walger's "Engineering Agent Memory" article clarified something I'd been working around without having language for.

The Sequencing Problem

The obvious fix for agent memory is write-time tagging. Tag what you know when you know it. Mark failures as failures. Mark resolutions as resolutions. Build the causal chain at the moment it happens.

The problem is that causality is only visible in retrospect.

An agent logs: "deployment failed due to timeout." That's a real memory. It happened. It's worth keeping. Later — same session, different session, a week later — the agent logs: "switched to async pattern, deployment succeeded." Also real. Also worth keeping.

These two memories belong together. They're the before and after of the same causal chain. But at write-time, you don't know that. When the failure happens, there's no resolution to link it to. When the resolution happens, the failure might be in a different session, under a different key, already buried in the retrieval index.

Vector search won't find the link reliably either. "Deployment failed due to timeout" and "switched to async pattern" don't look similar in embedding space. They're semantically distant. A similarity search for one won't surface the other. The causal connection is invisible to the retrieval layer.

This is the sequencing problem. Write-time tagging is premature because the thing you need to tag — the causal relationship — doesn't exist yet when the first memory lands. And post-hoc retrieval is unreliable because the link you need to recover isn't semantic. It's structural. It's temporal. It's the kind of connection that requires knowing what happened before and after, not just what looks alike.

Most memory systems stub this out. Summarize the session. Hope the summary captures enough. Move on.

It doesn't. And the failure mode is subtle enough that you don't notice until the agent is confidently reasoning from a memory that's missing the half that would have changed the conclusion.

Instrumented Capture + Temporal Mirror

The sequencing problem has two parts. They need two different solutions.

The first part — what to capture at write-time — is solved by instrumented capture. Not tagging outcomes. Tagging intent. When an agent makes a tool call, the instrumentation layer sees not just the result but the active context: what the agent was attempting, what state it was in, what it expected to happen. "Attempting calibration sequence v2" is richer than "calibration failed." The failure is the outcome. The attempt is the context. You need both, and only one of them exists at write-time.

MCP is the right layer for this. If the tool call routes through an MCP server, the server sees the full reasoning context — intent, failure mode, action taken — in real time, not reconstructed from a cold transcript later. Instrumentation at the call site captures signal that post-hoc analysis can't recover. The question is fidelity, which I'll come back to.

The second part — bridging the gap between a failure tag and a resolution that lands later — is what Ken Walger calls the Temporal Mirror. A post-write reflection pass that runs across recent entries and surfaces causal candidates: memories that aren't similar in embedding space but are temporally adjacent and structurally complementary. The failure and its resolution. The question and the answer it didn't know was coming.

In my setup, that reflection pass runs via Gemma 4 MoE after ingestion. Not a local model. The reason is specific: causal candidate identification requires enough reasoning capacity to recognize structural complementarity across entries that don't look alike on the surface. A smaller local model handles classification well. It misses the non-obvious links. And the non-obvious links are exactly where the causal chain value lives — if the link were obvious, vector search would have found it already.

The token cost is real. It's also bounded. The reflection pass runs once per ingestion event, not per query. A fixed overhead at write-time rather than a compounding cost every time the memory is accessed. That trade-off only makes sense if the reflection pass actually improves retrieval precision — which brings us to how the link gets stored once it's found.

Forensic Receipt: Pre-paying for Precision

Once the reflection pass identifies a causal link, the question is how to store it so retrieval can use it deterministically.

The answer isn't another embedding. It's a UUID.

Ken Walger calls this the Forensic Receipt — a unique identifier that links a failure entry to its resolution entry, independent of their semantic similarity. The agent doesn't need to search for the connection. It's already encoded. "deployment-failure-2024-11-04" links directly to "async-resolution-2024-11-07" via a stored causal edge, not via a similarity score that might or might not surface the right entry depending on how the query is phrased.

This is the difference between a Reasoning Ledger and a Digital Attic. The attic accumulates. The ledger traces. When an agent queries memory for context about a deployment failure, the ledger doesn't return what looks like deployment failures — it returns the specific failure and its resolution, linked by a chain of evidence that was built deliberately at ingestion time.

The cost argument is cleaner than it sounds. Every fuzzy vector search that fails to surface the right memory is a cost: tokens spent, context window consumed, agent confidence degraded on a premise that's missing a piece. The reflection pass that builds the Forensic Receipt is an upfront investment against that compounding failure cost. You're pre-paying for retrieval precision at ingestion rather than paying repeatedly for imprecision at query time.

The attic charges you every time you look for something and can't find it. The ledger charges you once, when you put it in correctly.

The Observer's Tax

There's a constraint that sits underneath all of this that the architecture can't ignore.

Ken Walger, whose background is in forensic auditing, named it the Observer's Tax: if your instrumentation is heavy enough to change the latency or behavior of the agent, you've lost the high-fidelity signal you were trying to capture. The agent you're logging isn't the agent anymore. The causal chain you're preserving is the chain of a degraded system.

Instrumented capture only works if the instrumentation is cheap enough to leave on in production. An MCP layer that adds 400ms to every tool call changes the agent's decision timing. A reflection pass that blocks ingestion until it completes changes the agent's memory availability mid-session. The Observer's Tax isn't a theoretical concern — it's the boundary condition that determines whether the whole architecture is describing a real system or an idealized one.

The practical implication: lightweight instrumentation over comprehensive instrumentation. Every additional signal the capture layer records is a cost paid in latency and behavioral change. The goal isn't maximum fidelity. It's minimum-viable fidelity — enough signal to build the causal chain, cheap enough to not corrupt it.

Event-driven triggering applies the same principle to the reflection pass. Running it after every write is expensive. Running it on a schedule risks the gap: a failure tag sitting unlinked for hours before the next sweep. The better trigger is structural: the reflection pass fires when a write contains specific signals — error states, resolution markers, state transitions — rather than on a timer or on every entry. The signal-to-noise ratio on causal candidates improves significantly. The cost stays bounded.

Toward a Standard Model

That's what infrastructure does. Storage charges you at query time. The Reasoning Ledger charges you once, when you build it correctly.

I'm calling this a proposal, not a standard. The pieces are real — they come from production systems, from a comment thread that surfaced the right vocabulary, from architectural decisions made under Cloudflare's CPU constraints where every overhead is visible immediately. But the boundary conditions aren't fully mapped. High-fidelity capture as the load-bearing requirement is the right frame. How cheap is cheap enough? What's the minimum-viable reflection pass for a given workflow complexity? Those questions don't have clean answers yet.

What the architecture gives you right now is a way to think about the problem that storage framing doesn't. Not where to put things. What to build so that agents can reason from them.

The Open Problem

The open problem isn't retrieval. It's capture fidelity.

Every part of this architecture downstream of the instrumentation layer depends on the capture layer getting the signal right. The Temporal Mirror can only find causal connections that the ingestion pipeline actually received. The Forensic Receipt can only link entries that contain enough structural signal to recognize as complementary. The Observer's Tax names the constraint but doesn't solve it: we don't yet have a principled way to determine what minimum-viable instrumentation looks like for a given agent workflow.

That's the next thing to figure out. Not how to retrieve memory better — vector search, BM25, cross-encoder reranking, all of that is solved enough to build on. How to capture what the agent actually did in a form that makes causal reasoning possible later, without the capture itself changing what the agent does.

Most of this piece came out of a comment thread on Ken Walger's "Engineering Agent Memory" on DEV.to. Ken coined both sides of the central frame — "digital attic" and "power grid for reasoning" — in the same sentence, and named the Temporal Mirror, the Forensic Receipt, the Observer's Tax, and the Standard Model. The sequencing problem, event-driven triggering, and Instrumented Capture came from my end. The production specifics — Gemma 4 MoE reflection pass, Cloudflare CPU constraints, vectorize-mcp-worker architecture — are mine. Everything else emerged from the exchange.

If you want to read the thread before the write-up arrived here, it's worth reading. Ken thinks carefully about forensic integrity in ways that transfer directly to agentic systems.

The Standard Model isn't finished. The open constraint — how cheap is cheap enough for a given workflow — doesn't have a clean answer yet. But the frame is more useful than the one it replaces. You can build on infrastructure. You can't build on an attic.

Built a 100k-Document RAG System by Hand. Hermes Read the Architecture in 47 Seconds.

Daniel Nwaneri — Thu, 21 May 2026 15:43:57 +0000

This is a submission for the Hermes Agent Challenge

For the past six months, I have been building what Hermes does by hand.

Not as a thought experiment. Actually building it: a hybrid BM25 + vector search engine on Cloudflare Workers, a Gemma 4 MoE reflection layer, 100,000+ documents indexed, an MCP server with Durable Objects, multimodal image ingestion with Llama 4 Scout. I won the OpenClaw Challenge writing about spec-writing agents. I built bookmark-cli — a personal knowledge engine with 45,053 tweets indexed from years of reading.

When the Hermes Agent Challenge dropped, I had one question: does the tool do what I taught myself to do?

This is that experiment.

The Setup

My machine: Windows 11, Python 3.14, Git Bash (MSYS2), no WSL2.

The repo: vectorize-mcp-worker — my production hybrid RAG system. Six months of architectural decisions baked into TypeScript. V4 routing. Six specialized query routes. Cost analytics down to the millisecond. The kind of codebase where you know exactly what a competent agent should say about it.

The goal: Install Hermes, configure it to use Claude, have it summarise the architecture in 5 bullets, document every friction point.

Friction Point 1: The Installer Doesn't Know You Exist

The official install command:

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

I ran it. The script loaded, detected my OS, and exited immediately:

Windows detected. Please use the PowerShell installer:
  irm https://raw.githubusercontent.com/.../install.ps1 | iex

That's not in the README. The PowerShell installer exists — it's right there in the repo — but nothing in the public docs points Windows users to it. You find out by reading the bash script's source.

The install UX assumes you're on Linux or macOS. Windows is supported, but you're expected to find your own way there.

Friction Point 2: WSL2 Would Have Saved Me This

I don't have WSL2 installed. That's on me. Every agent tooling project I've touched in the last year has quietly assumed it. Hermes is no different.

If you're on Windows and planning to work with CLI agents: install WSL2 first. Don't assume Git Bash is equivalent. It almost never is.

Friction Point 3: PyPI to the Rescue (Unofficially)

Rather than chase the PowerShell installer, I checked PyPI:

pip index versions hermes-agent
# Available versions: 0.13.0

hermes-agent 0.13.0 exists on PyPI. The official flow never mentions this. I installed it directly:

pip install hermes-agent

Four minutes, some progress bars, done.

Friction Point 4: Dependency Hell

The install succeeded but left me with this:

browser-use 0.12.6 requires openai==2.16.0, but you have openai 2.24.0
browser-use 0.12.6 requires requests==2.32.5, but you have requests 2.33.0
browser-use 0.12.6 requires rich==14.3.1, but you have rich 14.3.3

Hermes bumped openai from 2.16.0 to 2.24.0. Another tool I use (browser-use) pins the older version. Pip resolved it in Hermes's favor. Something will break later. I don't know what yet.

This is the tax you pay for a rich ecosystem. Every major agent framework is in a dependency arms race.

Friction Point 5: The Binary Isn't on PATH

After install, hermes doesn't work:

$ hermes doctor
bash: hermes: command not found

The executables land in %APPDATA%\Python\Python314\Scripts, which isn't on PATH by default. Pip warns you — in small print, at the end of a long install log.

Fixed with the full path:

/c/Users/DELL/AppData/Roaming/Python/Python314/Scripts/hermes.exe doctor

`hermes doctor` — Where It Gets Good

Once you find the binary, the experience shifts. hermes doctor:

◆ Python Environment
  ✓ Python 3.14.4
  ⚠ Not in virtual environment (recommended)

◆ Required Packages
  ✓ OpenAI SDK
  ✓ Rich (terminal UI)
  ✓ python-dotenv

◆ Tool Availability
  ✓ browser
  ✓ terminal
  ✓ file
  ✓ memory
  ⚠ browser-cdp (system dependency not met)
  ⚠ web (missing EXA_API_KEY, TAVILY_API_KEY...)

Every warning includes the fix. ✓ or ⚠, then the exact command. You don't go looking for the next step. After an install that gave you nothing, this lands differently.

Friction Point 6: `hermes model` Is Interactive-Only

I wanted to configure Claude from a script:

hermes model --provider anthropic --model claude-sonnet-4-5

No such flags. hermes model opens an interactive TUI. There's no way to set the model non-interactively from the CLI.

I wrote the API key directly to ~/.hermes/.env:

ANTHROPIC_API_KEY=sk-ant-...

Then passed the model inline at runtime:

hermes chat -m "anthropic/claude-sonnet-4-5" -q "..."

Friction Point 7: `--source` Doesn't Set the Working Directory

I tried:

hermes chat --source "C:/path/to/vectorize-mcp-worker/src" -q "Summarise..."

Hermes ignored the path and started from my home directory, listing unrelated projects:

I can see:
- bookmark-cli
- dannwaneri
- siteclinic

Which project should I analyze?

--source doesn't mean "work in this directory." I had to cd into the repo first. Small thing, confusing when you're scripting.

The Actual Session

Running from the repo directory with Claude as the model:

cd vectorize-mcp-worker
hermes chat \
  -m "anthropic/claude-sonnet-4-5" \
  -q "Summarise the architecture of this codebase in exactly 5 bullet points." \
  -Q

Output (verbatim, 47 seconds):

Cloudflare Workers-based RAG Platform — Serverless hybrid RAG system deployed on Cloudflare Workers with Vectorize (384d/1024d vector store), D1 (SQLite for full-text and metadata), Workers AI (embeddings via bge-small/bge-m3/qwen3-0.6b), service bindings to multimodal-pro-worker for image processing, and MCP Durable Objects for stateful agent sessions.

Intelligent V4 Routing Architecture — Query router (RouteSelector) uses Llama 3.2 3B intent classifier to dispatch to 6 specialized routes: ENTITY_LOOKUP (SQL), SEMANTIC_SEARCH (vector), KEYWORD_EXACT (BM25), OCR_DOCUMENT (text extraction), VISUAL_ANALYSIS (Llama 4 Scout vision), and GRAPH_REASONING (relationship traversal), with automatic fallback to vector search on route failure.

Hybrid Search with RRF Fusion — Dual-path retrieval combining vector search (Vectorize query) and BM25 keyword search (D1 full-text index), merged via Reciprocal Rank Fusion (RRF) with k=60, followed by optional cross-encoder reranking (bge-reranker-base), semantic highlighting, and Cloudflare Cache API for cacheable queries.

Chunking and Multi-Tenancy Pipeline — Ingestion engine performs recursive chunking with 15% overlap, parallel batch embedding (up to 100 docs/batch), deduplication via parent_id, and tenant isolation enforced by middleware that injects tenant_id filters into all search/delete operations.

Model Context Protocol Server — Exposes tools via modern MCP Streamable HTTP transport backed by VectorizeMcpAgent Durable Object at /mcp endpoint, with legacy JSON-RPC endpoints, cost analytics tracking (totalMs/embeddingMs/vectorMs/rerankerMs), rate limiting on mutating endpoints, and reflection system for synthetic training data generation.

I read that three times.

It got every major component right. RRF with k=60 — correct. Six routing modes, named accurately. The Durable Objects backing the MCP server. I've had reviewers describe the search as "just Vectorize" — missing the BM25 path entirely. Hermes got all of it in 47 seconds.

It missed the Gemma 4 MoE reflection layer specifically, and didn't distinguish between embedding model options by dimension size the way I would. Details inside details. The architecture read is accurate.

What I Actually Think

Hermes got the architecture right. Not close enough — right. And that's the thing that mattered most to me, because it's the hardest thing to fake. You can summarise README bullet points. You can't summarise a codebase you didn't actually read.

The install is rough if you're on Windows. Not broken — rough. The PyPI path works, the dependency conflicts are manageable, but "check the bash script source to find the PowerShell installer" is not an onboarding flow.

The gap I expected — between six months of building this by hand and a first session with a tool someone else built — was smaller than I thought it would be. That means either Hermes is further along than the install suggests, or I built something closer to commodity than I wanted to admit.

Probably both.

Multi-step sessions are what I actually want to test next — whether Hermes holds architectural context across a conversation the way I hold it across a codebase. That's the harder question. This was one query.

The Honest Take

If you're a Windows developer coming to Hermes cold: budget 30 minutes to fight the install, not 5. Once you're past it, the tool is real.

If you're a builder who's been assembling RAG pipelines by hand: Hermes won't replace what you know. It uses what you know. The architectural understanding you built making those systems is exactly what makes you dangerous with a tool like this.

The difference is now I can ask the codebase questions instead of just reading it.

That's not nothing.

All commands run on Windows 11, Python 3.14, Git Bash. Hermes Agent v0.13.0. Claude Sonnet 4.5 via Anthropic API.

vectorize-mcp-worker: hybrid RAG on Cloudflare Workers — github.com/dannwaneri/vectorize-mcp-worker

MCP Just Landed on Your Phone: What Google AI Edge Gallery Actually Does

Daniel Nwaneri — Wed, 20 May 2026 17:09:24 +0000

This is a submission for the Google I/O Writing Challenge

I was already running MCP servers on my desktop — connected to Claude, wired into my daily workflow — when Google announced at I/O 2026 that AI Edge Gallery now supports MCP connections on Android. I pulled out my Pixel and started testing.

First attempt: "No eligible devices." The app requires capable hardware. Second device — it opened.

What I found is more interesting than the announcement.

What Google AI Edge Gallery Is

Google AI Edge Gallery is an open-source Android app from Google Research. Large language models run entirely on your device — no internet required for inference, no data leaves your phone. Every prompt, every image, every audio clip stays local.

That part isn't new. What changed at I/O 2026: the app now supports agents. Not a chat interface with a web search button — a proper agent runtime with toggleable skills, calendar integration, scheduled reminders, and experimental MCP connections. The same protocol the rest of the serious agent ecosystem runs on.

The Model List Surprised Me

Opening the Models panel, I expected a Gemma showcase. That's not what this is.

Model	Size	Notes
Gemma-4-E2B-it	2.6 GB	Recommended across most use cases, 32K context
Gemma-4-E4B-it	3.7 GB	Multi-modal, 32K context
Gemma-3n-E2B-it	3.7 GB	Text, vision, audio, 4096 context
Gemma-3n-E4B-it	4.9 GB	Text, vision, audio, 4096 context
Gemma3-1B-IT	584 MB	4-bit quantized
Qwen2.5-1.5B-Instruct	1.6 GB	Alibaba's model, LiteRT-LM ready
DeepSeek-R1-Distill-Qwen-1.5B	1.8 GB	Reasoning model, fully on-device
TinyGarden-270M	289 MB	Fine-tuned FunctionGemma, task automation
MobileActions-270M	289 MB	Fine-tuned FunctionGemma, device control

DeepSeek and Qwen sitting in a Google app isn't accidental. The actual product here is LiteRT-LM — Google's mobile inference runtime — not Gemma. Which model you run on top is your choice.

Gemma 4: The Number That Matters

Gemma 4 E2B runs in 2.6 GB and opens a 32K context window. Gemma 3n had 4096 tokens. Multi-modal input — text, images, and audio — in one model.

That context gap is what makes the agent use case real. Tool call outputs, calendar data, conversation history — there's room to feed all of it back to the model without truncating. Running a 32K context window offline on a phone wasn't viable when the best on-device options topped out under 2K.

All models run through LiteRT-LM — previously TensorFlow Lite, now meaningfully upgraded.

Agent Skills: What It Actually Looks Like

This is the part I came to test. Here's what's actually inside.

The Skills Architecture

Agent Skills runs on 12 skills total — split into two tiers:

Built-in skills (Google's own):

calculate-hash — hash a given text
create-calendar-event — write to OS calendar
interactive-map — show a map view for a location

Community skills (user-created, same interface):

read-calendar-events — read OS calendar for a specific date
schedule-notification — schedule a one-time or repeating daily notification
query-wikipedia — pull a Wikipedia summary on a topic
qr-code — generate a QR code for a URL
mood-tracker — stores daily mood and comments, tracks history
send-email — send an email
learn-something-new — daily learning companion with image card and scheduled notification
kitchen-adventure — dungeon master RPG set in a world of sentient kitchen appliances
text-spinner — "Spin the given text on my head"

Two things worth noticing. First: calendar read and calendar write are separate skills with separate toggles. That's a granular permissions model — the agent can write events without having read access, or vice versa. Second: send-email means an offline on-device model can send emails through a skill. That's not a demo capability.

Every skill has a "View" button — inspect the full skill definition before enabling it. Each is individually toggleable. The chat bar shows a live count: Skills 8 | MCP 0. Skills and MCP are tracked separately in the same toolbar.

Four ways to add skills:

Featured list — curated community contributions
Load from URL — any web-hosted skill directory
Import local skill — from the device directly, no server needed
GitHub Discussions — browse the full community

Local import is the developer detail. You can build and test a skill entirely on-device without hosting anything. The iteration loop for custom skill development doesn't require a deployed server.

Agent Skills only accepts two models — both Gemma 4. Gemma 3, DeepSeek, Qwen: available for AI Chat, locked out of agents. Google drew a capability line and stuck to it.

The MCP Setup

Tap the MCP counter in the toolbar → empty state with a single button: + Add MCP server.

The dialog asks for:

Your MCP server URL
Authorization: None, Request header, or OAuth (WIP)

OAuth isn't ready yet. That's the honest limitation for anyone planning to connect enterprise or authenticated MCP servers — you're working with no auth or bearer token only, for now. Public MCP servers work today. Authenticated production servers will have to wait for OAuth to ship.

Worth noting what this architecture means even without OAuth: tool-selection logic runs on-device, and only the structured API call leaves the phone. For healthcare or legal tooling that can't send raw queries to a server, that's a meaningful trust boundary — not a workaround.

For developers already running public MCP servers: enter the URL, the app fetches the tool manifest, tool definitions load into the system prompt alongside your active skills. The model handles invocation from there.

The Rest of the App

Each use case — AI Chat, Ask Image, Audio Scribe, Prompt Lab — links directly to API documentation and example code from its own screen. This is a teaching environment, not just a demo. Google built it for developers to read, fork, and build on.

AI Chat supports Thinking Mode — Gemma 4's step-by-step reasoning exposed inline. Useful before you wire a model into anything production-facing.

Mobile Actions runs on MobileActions-270M — 289 MB, fully offline. A 270M parameter model doing device automation. For context, Gemma 4 E2B is roughly 10x that size and handles general reasoning. The argument being made with that design: narrow fine-tunes at sub-300MB can do discrete tasks better than a general model, and they fit anywhere.

Tiny Garden — 289 MB, natural language gardening game — is the same point made playfully. Watch how function-calling works on-device in a consequence-free environment.

Getting Started

1. Install Google AI Edge Gallery (Play Store)
   Requires capable Android hardware — tested on Pixel

2. Download Gemma-4-E2B-it (2.6 GB)
   Only Gemma 4 models run Agent Skills

3. Open Agent Skills → tap the Skills or MCP button in the toolbar

4. For built-in skills: toggle on what you need
   For MCP: tap MCP → Add MCP server → enter URL + auth

5. Start chatting — the model sees your active skills and connected tools

Source code: github.com/google-ai-edge/gallery. Community skills shareable via GitHub Discussions.

What Developers Should Take From This

The Gemma 4-only lock on Agent Skills is the tell. This isn't a checkbox feature. Google shipped agentic tool use where the model can handle it reliably, and locked out weaker models until that changes. That's a better decision than letting anything run and degrading silently.

The OAuth (WIP) flag on MCP auth is the other honest signal. Public MCP servers work today. Enterprise-grade authenticated connections aren't there yet. That's not a failure — it's a preview of where this is going, with the current edges visible rather than hidden.

The 270M fine-tuned models are the underrated part of this release. MobileActions and TinyGarden are evidence of a different architecture: specialized micro-models for narrow tasks, general models for reasoning, LiteRT-LM as the runtime connecting them. At 289 MB each, those models fit anywhere.

MCP being here matters because it's the same protocol across Claude, Cursor, VS Code extensions, and now Google's on-device runtime. Build a tool as an MCP server once and every compatible client picks it up. That's not small.

Verdict

AI Edge Gallery is the most developer-forward release from Google I/O 2026. Not a consumer product — a reference implementation of what on-device agents look like when an open protocol, a capable model family, and a mobile inference runtime land in the same place.

If you're building with MCP today, install the app and point it at your existing server. Your tools already work. That's not a coincidence — it's what a protocol looks like when it actually wins.

Written with assistance from Claude (Anthropic). Hands-on testing on Pixel: model list, Agent Skills interface, MCP setup flow, and skills management observed directly. Gemma-4-E2B-it downloaded; model inference and chat results not included in this article.

Cloudflare Deprecated My Production Model. The Recommended Upgrade Costs $4/M Tokens. Gemma 4 MoE Doesn't.

Daniel Nwaneri — Tue, 19 May 2026 11:55:01 +0000

This is a submission for the Gemma 4 Challenge: Build with Gemma 4

What I Built

On May 8, Cloudflare posted a deprecation notice.

@cf/moonshot/kimi-k2.5 — the model synthesising knowledge across 45,000 of my saved tweets — was going away on May 30.

I had a live production system, a daily cron, and 100,000+ indexed documents depending on that model. I had 22 days.

Cloudflare's recommended replacement: @cf/google/gemma-4-26b-a4b-it.

So I migrated and benchmarked every step. Here's what I found, what broke, and why Gemma 4 MoE was the right call even after a better Kimi arrived.

bookmark-cli is a personal knowledge engine I built after getting frustrated with X's native search. It syncs my bookmarks and likes into local SQLite, then pushes everything into a Cloudflare Worker for semantic retrieval.

The numbers:

45,053 tweets (11,835 bookmarks + 33,218 likes)
7,155 photo tweets enriched by Llama 4 Scout vision descriptions
100,302 total documents in the vector index
Daily cron syncing new content automatically
$5/month total running cost

The architecture: bookmark-cli calls vectorize-mcp-worker, which runs hybrid BM25 + vector search, cross-encoder reranking, and a knowledge reflection layer that synthesises connections across documents.

One question worth answering upfront: if the data is from 2023, what good is it?

This isn't a news feed — it's a thinking tool. When you liked a tweet about RAG failure modes two years ago, you were signalling "this matters to me." The reflection engine connects that to four other things you saved that week across different topics and surfaces the thread you didn't consciously notice. The index only contains what you chose to save. No engagement algorithm, no ads, no recency bias — just your own curation, made searchable and cross-referenced. Google searches the internet. This searches your mind.

A reflection the engine generated from tweets I saved about AI and work — none of which said this:

"Non-technical users are increasingly using AI agents to 'vibe-code' large amounts of software without manual code review or verification. This reliance on generated outputs often involves a level of blind trust that bypasses the rigorous research and scrutiny essential to traditional programming. Although this method can appear highly productive, the lack of technical expertise makes debugging these systems exceptionally difficult and prone to subtle, painful failures."

That's three fragments from different weeks, connected by the model into one coherent insight. The technical details are below.

Demo

Live dashboard: vectorize-mcp-worker.fpl-test.workers.dev/dashboard

Code

vectorize-mcp-worker: github.com/dannwaneri/vectorize-mcp-worker
bookmark-cli: github.com/dannwaneri/bookmark-cli
Benchmark endpoint: POST /benchmark with Authorization: Bearer header

How I Used Gemma 4

Why Gemma 4 MoE specifically

Three Gemma 4 variants exist on Workers AI. I needed to pick one.

Model	Active params	Best for
gemma-4-e4b-it	4B total (dense)	Local / memory-constrained
gemma-4-27b-it	27B dense	Max quality, more compute
gemma-4-26b-a4b-it	26B total, 4B active (MoE)	Edge inference, reasoning depth

The reflection layer does multi-document synthesis — it reads 5 related chunks and produces a structured 3-sentence insight. That's not a summarisation task, it's a reasoning task. The 4B dense model would have been too shallow. The 27B dense would have been too slow at the edge.

4B active parameters per forward pass. 26B total. At the edge, you need the first number. For multi-document synthesis, you need the second. The MoE architecture is the only way to have both.

The entire pipeline — embed, retrieve, rerank, reflect — runs inside one Cloudflare Worker. Gemma 4 MoE is a native Workers AI binding. No external API call. No data leaving the edge.

The migration

The codebase already had a REFLECTION_MODEL env var. The model registry needed one addition:

export const REFLECTION_MODELS = {
  'gemma-4': {
    id: '@cf/google/gemma-4-26b-a4b-it' as const,
    label: 'Gemma 4 26B MoE (4B active)',
    note: 'Recommended. 4B active params via MoE — edge-native, no external hop.',
  },
  'kimi-k2.5': {
    id: '@cf/moonshotai/kimi-k2.5' as const,
    label: 'Kimi K2.5',
    note: 'Deprecated May 30 2026.',
  },

Then:

wrangler secret put REFLECTION_MODEL
# enter: gemma-4

wrangler deploy

That was the migration. The reflection engine reads env.REFLECTION_MODEL dynamically. Nothing else changed.

Three gotchas worth knowing

1. max_tokens. Gemma 4 is a thinking model. It writes a full reasoning chain before producing output. With max_tokens: 180 set for the old model, Gemma 4 was spending all its tokens on internal reasoning and returning empty content. Bumping to max_tokens: 2048 fixed it.

2. Response extraction. For thinking models, use choices[0].message.content — not .reasoning and not .response. The reasoning field is the internal chain of thought, not the answer.

3. Prompt format. Verbose rule-lists trigger Gemma 4's constraint-analysis behaviour — it restates your rules as bullet points instead of following them. Keep prompts simple and end with a direct action cue:

Read the new source and related sources below, then write 3 plain prose sentences
that synthesise them into a knowledge base entry. No bullets. No analysis. No preamble.
Just 3 sentences.

New: "..."
Related: ...

Write the 3-sentence synthesis now:

The benchmark

I built a /benchmark endpoint that runs both models in parallel against the same query, logs latency and response to D1, and returns side-by-side results.

POST /benchmark
{ "query": "What are the common failure modes of RAG systems?" }

Results from D1 (9 real queries):

Query	Gemma 4 MoE	Kimi K2.5
RAG failure modes	12.9s	12.4s
Embedding model selection	9.9s	90.7s ⚠️
BM25 vs vector search	19.6s	7.3s
Reducing hallucination	19.0s	6.9s
Chunking strategies	9.3s	9.0s
Edge AI model selection	11.8s	8.3s
MoE efficiency at scale	16.5s	8.0s
Cloudflare Workers AI	22.8s	FAILED
KB maintenance	10.1s	5.5s

Kimi K2.5 was faster on 7 of 9 queries. But it produced a 90-second response on one query and failed outright on another — within a single benchmark run. A model that's faster on average but unreliable under load isn't a production model.

Gemma 4 MoE was consistent. Every query returned. Every response was coherent. Latency was predictable.

Beyond the latency numbers, the Kimi K2.5 reflections in the index all started with "Here are the 3 sentences:" — the model was leaking the instruction prefix into every stored reflection. Gemma 4 produces clean prose output with the right prompt.

What's live now

GET /stats → models.reflection: "@cf/google/gemma-4-26b-a4b-it"

The live dashboard is at vectorize-mcp-worker.fpl-test.workers.dev/dashboard — open it and the active reflection model is listed in the stats panel. Gemma 4 MoE, running in production.

1,525 reflections generated since the migration. The cron added more this morning. Verify live: /public-stats — no API key needed.

A second reflection, this one on AI and management:

"AI is increasing individual contributor leverage and is frequently marketed as a labor replacement, driving companies to prioritize cost-cutting and individual productivity. This trend often places pressure on managers to perform individual contributor roles, potentially devaluing the necessity of human oversight and organizational management. Relying on these technologies also introduces risks involving accountability for failures, misunderstandings of AI's true capabilities, and the loss of human-centric benefits like upskilling."

This came from unrelated tweets saved across different weeks, connected by the engine into a single coherent insight, stored back into the index so it surfaces when I search anything adjacent to AI, management, or developer tooling. That's the reflection layer working as intended.

Full pipeline:

bookmark-cli → vectorize-mcp-worker
  embed (BGE Small) →
  retrieve (Vectorize + BM25) →
  rerank (BGE cross-encoder) →
  reflect (Gemma 4 MoE) ← NEW

Everything stays inside one Cloudflare Worker. No external hop for the reasoning layer.

Gemma 4 MoE isn't here because of a challenge. It's here because Cloudflare deprecated the model it replaced and this was the right call. It will still be running after June 4.

The verdict

Gemma 4 MoE is not faster than Kimi K2.5 was on average. If raw speed were the only metric, and if Kimi K2.5 were staying around, I'd have a harder decision.

But it isn't staying around.

Cloudflare has since released Kimi K2.6 — 1T parameters, 262k context window, reasoning, vision, tool calling. It's impressive. It's also $0.95/M input tokens and $4.00/M output tokens. The reflection layer synthesises on every ingest. At that pricing, running it across a 100k-document backlog would end the $5/month cost story in a single batch. Gemma 4 MoE, as a native Workers AI model, stays within the free tier. The upgrade path wasn't really an upgrade for this use case.

And for a reflection layer specifically — where the task is multi-document synthesis, where you need reasoning depth more than raw throughput, and where you want the entire pipeline to stay edge-native — Gemma 4 MoE is the right model. The MoE architecture is why. 4B active parameters gives you the inference speed you need at the edge. 26B total parameters gives you the knowledge depth the task requires.

At $4/M output tokens, the upgrade wasn't an upgrade. Gemma 4 MoE still is. The daily cron doesn't know it's in a challenge. It ran this morning.

What's next for Gemma 4 MoE in this pipeline

The reflection layer is one use. The code already has a second.

Every 3 new ingests, the pipeline runs a consolidation pass — Gemma 4 MoE reads the 10 most recent reflections and merges them into a single doc_type='summary': dominant theme, two or three specific non-obvious facts, and the most persistent open question across all the reflections. The summary lands in Vectorize and surfaces in search exactly like a reflection does. Reflections capture individual connections. Summaries capture patterns across connections. Both are Gemma 4 MoE, both are edge-native, both add to the index without touching the $5/month cost ceiling.

That's the current state. Three extensions are already scoped:

Query-time answer synthesis. Right now the pipeline retrieves chunks and returns them. The next layer uses Gemma 4 MoE to read the top 5 retrieved chunks and produce a direct answer — not a list of results, an actual response grounded in what you saved. The retrieval already works. The synthesis step is the same task the reflection layer already does, with a different prompt.

Routing upgrade. The V4 intelligent router currently runs on Llama 3.2 3B — fast classification into six query routes (SQL, BM25, vector, graph, etc.). Moving that to Gemma 4 MoE's thinking mode means the router can reason about ambiguous queries instead of classifying them. A question like "what did I save about RAG that I disagreed with?" hits multiple routes simultaneously. A 3B classifier guesses. A 26B MoE reasons.

Gap detection. The reflection engine already identifies gaps — questions the combined knowledge doesn't answer. A weekly pass that reads all gap annotations across the index and surfaces the three most persistent unanswered questions would make the tool actively useful for research, not just reactive to search queries. One scheduled cron, one Gemma 4 MoE call per week, zero additional cost in the free tier.

Personal preference reranker. The index contains 100k+ documents across AI, politics, sports, and everything else saved since 2016. Every bookmark and like is a signal: this person found this worth keeping. The longer-term path is fine-tuning a small cross-encoder on that signal — not domain expertise, but preference prediction. A model trained on "did this person save this or not" beats every general reranker at one narrow task: knowing what you care about. It slots into the existing pipeline as a final reranking layer after BGE, before the reflection pass. The training data is a decade of curation. The narrow task is yours alone.

The reflection layer was the migration. These four are the reason it stays.

I Ran SERP Feature Detection on 8 Nigerian Creator Queries. Every Single One Had an AI Overview.

Daniel Nwaneri — Thu, 14 May 2026 14:40:49 +0000

I built a SERP feature detection module for my SEO agent. Then I ran it on the queries I'm targeting for a site about how Nigerian creators get paid online.

The results were more uniform than I expected.

What the Module Does

The module calls SerpApi for each target query and checks the structured JSON response for seven SERP features:

AI Overview
Featured snippet
People Also Ask (PAA)
Image pack
Video results
Local pack
Knowledge panel

Each query comes back with a feature matrix and a list of content opportunities. No browser, no CAPTCHA, no bot detection — SerpApi handles the residential proxy infrastructure on their end.

The free tier is 100 searches/month. I have 8 target queries. That's comfortable.

The Results

I ran it on these queries for naija-vpn.com:

does twitch pay nigerians
how to receive money from twitch in nigeria
cleva vs geegpay nigeria
payoneer nigeria freelancers
how nigerians get paid on youtube
how to receive fiverr payment in nigeria
does tiktok pay nigerians
best dollar account for nigerian freelancers

The output:

Query	AI Overview	Feat. Snippet	PAA	Images	Video	Local	KP
does twitch pay nigerians	✓	—	✓	—	✓	—	—
how to receive money from twitch in nigeria	✓	—	✓	—	✓	—	—
cleva vs geegpay nigeria	✓	—	✓	—	✓	—	—
payoneer nigeria freelancers	✓	—	✓	—	✓	—	—
how nigerians get paid on youtube	✓	—	✓	—	✓	—	—
how to receive fiverr payment in nigeria	✓	—	✓	—	✓	—	—
does tiktok pay nigerians	✓	—	✓	—	✓	—	—
best dollar account for nigerian freelancers	✓	—	✓	—	✓	—	—

8 out of 8 queries: AI Overview ✓, PAA ✓, Video ✓.

No featured snippets. No local pack. No knowledge panels. Clean organic SERPs with three consistent rich features sitting above the fold.

What This Actually Means

AI Overview on every query

Google is summarising all of these topics directly in the search results. The old model — rank #1, get the click — has a layer on top of it now. The AI Overview reads the top sources and generates a summary. If your content is the clearest, most direct answer, there's a chance you get cited inside the summary. If it's buried in context, you don't.

The implication for writing: the first paragraph of every article in this niche now needs to be a complete, direct answer. Not "In this article, we'll explore..." — an actual answer. 40–60 words, no preamble.

PAA on every query

People Also Ask boxes are Google surfacing the secondary questions that the same user is likely to have. They're also secondary ranking opportunities — each box is its own small search result.

The catch: to rank in a PAA box, your heading needs to match the question phrasing closely. "Common Questions" sections with paraphrased questions miss the slot. The exact wording matters.

I ran related_questions from the SerpApi response for my two priority queries:

"does twitch pay nigerians":

Is Nigeria eligible for Twitch monetization?
How much money for 1000 views on Twitch?
Does streaming pay in Nigeria?
How much is 20k gifted subs on Twitch in Nigeria?

"how to receive money from twitch in nigeria":

Is Nigeria eligible for Twitch monetization?
How to make money from Twitch in Nigeria?
How much is 20k gifted subs on Twitch in Nigeria?
How many viewers on Twitch to make $1000 a month?

These became the <h3> headings in my FAQ section — verbatim, with full answers under each one.

Video on every query

YouTube videos are ranking for all 8 queries. I don't have videos. That's a gap I'm noting but not chasing right now — text content first, get indexed and cited, video is a later play.

No featured snippets

The AI Overview is eating what would otherwise be featured snippets. This isn't surprising — Google uses featured snippets to feed AI Overviews. If you're getting cited in the AI Overview, the featured snippet slot effectively doesn't matter.

What I Changed on the Pages

I updated three pages (Twitch, TikTok, YouTube) with the same two interventions:

1. Opening paragraph rewrite

Before:

Quick Answer: Nigerian streamers receive Twitch payments by using virtual US dollar accounts...

After:

Yes, Twitch pays Nigerians. Nigerian streamers can earn from subscriptions, bits, and ads through the Twitch Affiliate and Partner programs. To receive payments, you need a virtual dollar account — Cleva or Geegpay — which gives you real US bank details for Twitch's ACH transfers. Setup takes under 10 minutes with your NIN and BVN.

The difference: the second version opens with "Yes" (direct answer to the query), names the mechanism (virtual dollar account), names the specific products (Cleva, Geegpay), and gives the time estimate. All within 55 words. That's extractable.

2. FAQ section with exact PAA wording

Replaced generic Q&A sections with <h3> headings matching the SerpApi PAA questions word for word. Full paragraph answers under each.

I also tested adding @type: FAQPage structured data. I removed it before publishing — Google deprecated FAQ rich results in August 2023 and pulled it from their documentation entirely in September 2024. The schema does nothing now. The <h3> headings with exact PAA wording are what actually matter for ranking in PAA boxes, not the schema.

The Tool That Did This

serp-features is a module in my open-source SEO agent. You give it a list of queries, it returns a feature matrix and opportunity notes. It's about 260 lines of Python.

# Install
pip install httpx

# Set your SerpApi key (free tier, no credit card)
export SERPAPI_KEY="your-key-here"

# Run on a single query
python main.py serp-features --query "does twitch pay nigerians" --project naija-payments

# Run on a file of queries
python main.py serp-features --queries queries.txt --project naija-payments

The output is a markdown file with the feature matrix and per-query opportunity notes.

GitHub: github.com/dannwaneri/seo-agent

What I Learned Building It

The first version used Playwright to visit the real Google SERP. It worked for 1–3 queries before Google's bot detection kicked in. I tried user agents, delays, networkidle waits — none of it made a meaningful difference. Google's detection isn't based on request timing; it's based on IP reputation at scale.

The solution was to stop trying to scrape Google and use an API that already solved the infrastructure problem. SerpApi uses residential proxy networks — the same approach DataForSEO uses, just accessible to individuals on a free tier.

The rewrite was cleaner than the original. No Playwright dependency, no browser window opening, no CAPTCHA prompts. One httpx.get() call per query, structured JSON in, feature flags out.

Sometimes the right answer is to not fight the infrastructure problem yourself.

This is part of an ongoing series on building an open-source SEO co-pilot. The full agent handles core audits, GSC analysis, backlink scoring, internal link mapping, SERP feature detection, and LLM visibility checking — all local, all free or near-free to run.

OpenSEO Has 1.7k GitHub Stars. I Built the Same Thing for $0.

Daniel Nwaneri — Thu, 14 May 2026 14:37:44 +0000

I saw OpenSEO trending and did what every developer does.

I starred it before reading the pricing.

Then I read the pricing.

The appeal is real

The pitch is clean: open source, self-hostable, pay-as-you-go. No Semrush subscription. No bloat. Fork it and add your own features. For developers tired of paying $200/month for tools that do 10x more than they need, it lands perfectly.

1.7k stars. 196 forks. Active releases. The community is real.

I get it. I would have starred it too.

Then I opened the pricing section

"OpenSEO itself remains free. It works by using DataForSEO's APIs, which is a paid third-party service."

So it's free the same way a printer is free.

Here's what DataForSEO actually costs:

Minimum top-up: $50
Backlinks API: $100/month commitment
100 keyword research requests: $3.50–$7.00
100 domain overviews: $4.01
Rank tracking at scale: climbs fast depending on keywords and devices

The stars came from developers who love the idea. The cost reality hits after setup.

What I built instead

Part of what I do is build real-browser SEO automation tools — agents that visit pages the way Google does, not the way a scraper does.

My SEO agent does a full site audit — titles, meta descriptions, H1s, canonical tags, broken links, GSC quick wins, internal link clusters — in a real Chromium browser.

Not an API. An actual browser visiting each page.

Here's what it costs to run:

Browser visits: $0. Playwright is free.
GSC data: $0. Google already collected it for you.
Claude API calls: fractions of a cent per page on Haiku.
Total for a full audit: under $0.01 for most sites.

I wrote about the exact cost breakdown here. The short version: I was paying $0.006 per URL until I realized most URLs needed $0.

The technical difference that matters

OpenSEO pulls data from DataForSEO's index. That index is updated periodically. It tells you what DataForSEO's crawlers saw, when they saw it.

My agent visits the page right now, in a real browser, and extracts what's actually there — rendered JavaScript, actual title tags, real canonical values, live broken links.

If a page has a client-side rendering issue that hides the H1 from crawlers, a scraper-based tool misses it. A real browser catches it.

This is the same principle behind the Cloudflare-based automations I build for clients — edge-deployed, real output, not cached assumptions.

That's not a criticism of OpenSEO. It's a different architectural choice with a real tradeoff.

What OpenSEO has that I don't

I'll be honest:

Rank tracking over time — I don't have this
Keyword research at scale — not built
Backlink analysis — not in my agent
A polished UI — mine outputs JSON

If you need those features and you're comfortable with the DataForSEO cost model, OpenSEO is a reasonable choice.

But if your core need is: does this page have what Google needs to rank it — a real browser costs less and sees more.

One more thing

OpenSEO's contributor list includes @claude.

So does mine.

We're both building production tools with the Claude API. The difference is what you're optimizing for — features, or cost per insight.

I chose cost per insight. My sites are proof it works.

The agent is open source

github.com/dannwaneri/seo-agent

Run it on your own site. It's resumable, so if it crashes at URL 47 it picks up at URL 48. No DataForSEO account needed.

If you want a version that runs on Cloudflare Workers at the edge, that's something I build for clients too.

I build AI agents and SEO automation tools at dannwaneri.com. Everything I ship, I've run on my own domains first.

The Language Wars Are Over. The Ground Shifted Without You.

Daniel Nwaneri — Tue, 12 May 2026 14:12:05 +0000

I stopped caring which language someone uses. Somewhere in the last eighteen months, that happened without me deciding it.

Not because I became a better person. Because the argument stopped mattering.

In August 2025, TypeScript surpassed both Python and JavaScript as the most-used language on GitHub for the first time ever. Not because developers sat down and decided TypeScript won. Because AI tools handle it better, so it spread. The debate didn't resolve. The ground shifted underneath it and most people are still fighting on the old map.

The War That Already Ended

The Python vs JavaScript argument ran for a decade. Rust evangelism became a personality type. C++ veterans looked down on everyone. The fight was never really about syntax — it was about belonging. Who gets to call themselves a real developer. Who gets filtered out at the interview. Who gets taken seriously in the architecture meeting.

That argument is over.

Not because anyone won. Because something else became the constraint.

What Replaced It

The new constraints aren't linguistic. Tokens — how much context a session can hold before the model starts forgetting what it's building. Context windows — how much of your codebase an agent can actually see at once. Prompt discipline — whether your instructions are tight enough that the agent doesn't guess. Three things. None of them are in any job description yet.

Nobody voted on this shift. There was no announcement. It just became true while we were arguing about whether Rust was worth learning.

The developer who ships consistently now isn't the one who knows the most syntax. It's the one who can structure a spec tightly enough that the agent doesn't hallucinate the requirements, manage a context window without losing architectural coherence across sessions, and catch what the model got confidently wrong before it reaches production.
I’ve been experimenting heavily with this in my own production AI agents and real-browser automation workflows.

That's a different skill. No bootcamp teaches it yet. Most job descriptions don't list it.

The Gate Didn't Disappear. It Moved.

Language gatekeeping excluded people by syntax preference. You didn't know pointers? Not a real programmer. You used PHP? Embarrassing. You learned with a framework instead of from scratch? Shortcuts.

The new gatekeeping is quieter. You're not excluded for your language anymore.

You're excluded for your context budget.

Token limits are a billing problem dressed as a technical one. But knowing how to structure prompts, manage agent memory, and stay coherent across a long multi-step workflow — these compound. The developer who can do this produces dramatically better output than the one who can't. The gap is real and it grows with complexity.

Same exclusion mechanism. Different surface. Less visible, which makes it harder to name and harder to argue against.

The old gatekeeping was at least honest about what it was filtering for. The new one looks like a productivity difference.

What Doesn't Change

Not everything shifted.

That person is still you.

The things that actually matter — judgment, accountability, knowing when the confident answer is wrong — those don't change with the terrain. They get more important as generation gets cheaper.

Uncle Bob Martin, who spent months coding with Claude and wrote about it publicly, noticed something: Claude codes faster, holds more details, but can't hold the big picture. It doesn't foresee the disaster it's creating. Someone still has to see that. Someone still has to slow down and ask whether this is right, not just whether it compiles.

But the marker of competence shifted. The proxy changed. The new proxy is harder to fake than the old one.

You can memorize syntax. You can pass a whiteboard interview on language trivia. You can't fake knowing how to structure a ten-step agent workflow without the context collapsing at step seven, or how to write a spec that gives an agent something real to work with instead of something it'll interpret five different ways.
This is exactly why I built my own SEO automation agent that runs unsupervised on Cloudflare.

The old gate was about what you'd memorized. The new one is about how you think.

The Part That's Still Unresolved

I don't know if the new gate is better than the old one.

The old gatekeeping protected a social hierarchy more than it protected code quality. CS degrees, whiteboard interviews, years-of-experience requirements — they controlled access. They decided who got to call themselves real engineers. That architecture was never really about quality.

The new constraints are at least about something real. Context discipline, prompt structure, verification habits — these produce actual output differences. The filter is less arbitrary.

But "less arbitrary" isn't the same as "fair." Token budgets cost money. The developer in Lagos with a $20 API limit and the developer in San Francisco with a $200 plan are not operating in the same environment. The new constraint is technical and financial simultaneously. That's not a coincidence — it's just the old hierarchy in different clothes.

We spent years arguing about languages. Now the argument is how well you can give instructions.

That's not obviously worse. It's just different.

And we haven't decided yet whether the new gate is better than the old one, or just less visible.

DEV Community: Daniel Nwaneri

Hi @ben . you liked this yesterday: https://dev.to/dannwaneri/the-loop-is-not-the-product-466d hours later Sloan flagged it as AI-generated. Your founder liked the piece. Your bot flagged it. Sloan isn't catching AI. It's catching good writing.....

The Loop Is Not the Product

The Loop Is Not the Product

I built a tool to stop Claude from forgetting everything then forgot about it myself

What I Built

This directly solves the compaction problem

Demo

The Comeback Story

My Experience with GitHub Copilot

Post-Publication: It Runs in GitHub Copilot Too

What's Next

Google Is One Feature Away From Killing an Entire Startup Category

What NotebookLM already does

The one feature that changes everything

The countdown timers

The Google tax

Why Google probably won't ship it next quarter

What this actually means for developers

What Building My Own AI Bot Taught Me About Generative AI

Toward a Standard Model for Agent Memory

The Sequencing Problem

Instrumented Capture + Temporal Mirror

Forensic Receipt: Pre-paying for Precision

The Observer's Tax

Toward a Standard Model

The Open Problem

Built a 100k-Document RAG System by Hand. Hermes Read the Architecture in 47 Seconds.

The Setup

Friction Point 1: The Installer Doesn't Know You Exist

Friction Point 2: WSL2 Would Have Saved Me This

Friction Point 3: PyPI to the Rescue (Unofficially)

Friction Point 4: Dependency Hell

Friction Point 5: The Binary Isn't on PATH

hermes doctor — Where It Gets Good

Friction Point 6: hermes model Is Interactive-Only

Friction Point 7: --source Doesn't Set the Working Directory

The Actual Session

What I Actually Think

The Honest Take

MCP Just Landed on Your Phone: What Google AI Edge Gallery Actually Does

What Google AI Edge Gallery Is

The Model List Surprised Me

Gemma 4: The Number That Matters

Agent Skills: What It Actually Looks Like

The Skills Architecture

The MCP Setup

The Rest of the App

Getting Started

What Developers Should Take From This

Verdict

Cloudflare Deprecated My Production Model. The Recommended Upgrade Costs $4/M Tokens. Gemma 4 MoE Doesn't.

What I Built

Demo

Code

How I Used Gemma 4

Why Gemma 4 MoE specifically

The migration

Three gotchas worth knowing

The benchmark

What's live now

The verdict

What's next for Gemma 4 MoE in this pipeline

I Ran SERP Feature Detection on 8 Nigerian Creator Queries. Every Single One Had an AI Overview.

What the Module Does

The Results

What This Actually Means

AI Overview on every query

PAA on every query

Video on every query

No featured snippets

What I Changed on the Pages

The Tool That Did This

What I Learned Building It

OpenSEO Has 1.7k GitHub Stars. I Built the Same Thing for $0.

The appeal is real

Then I opened the pricing section

What I built instead

The technical difference that matters

What OpenSEO has that I don't

`hermes doctor` — Where It Gets Good

Friction Point 6: `hermes model` Is Interactive-Only

Friction Point 7: `--source` Doesn't Set the Working Directory