DEV Community: Mehmet TURAÇ

Stop Your AI Agent From Building Tools That Already Exist

Mehmet TURAÇ — Sun, 26 Apr 2026 19:51:30 +0000

Your agent just wrote a custom PDF parser.

There were four maintained libraries that do exactly this. It didn't check. It never does.

This is the default behavior of every coding agent: task arrives → code is written → you maintain the bespoke solution forever.

skill-hunter is the missing pause.

What It Does

skill-hunter is a pre-execution layer for coding and automation agents. Before your agent writes a single line, it:

Classifies the request — what kind of task is this?
Scans the ecosystem — MCP servers, CLIs, npm/pip packages, APIs, GitHub repos, existing repo utilities
Scores candidates — fit, maintenance activity, permissions, security, docs quality, license, integration effort
Recommends a path — reuse, adapt, build minimally, or build custom
Gates risky actions — installs, credentials, external service connections, destructive ops require explicit approval

The agent checks the toolbox before building another hammer.

The Before / After

Without skill-hunter:

User: "Parse these PDFs and extract invoices."
Agent: writes 200-line custom parser

With skill-hunter:

User: "Parse these PDFs and extract invoices."
Agent: checks PDF libraries, OCR tools, invoice extraction APIs, asks whether accuracy, cost, privacy, or offline processing matters
Agent: "pdfplumber covers 90% of this. Want me to wrap it with your schema instead?"

Install in 30 Seconds

Claude Code:

/plugin marketplace add mturac/skill-hunter
/plugin install skill-hunter@skill-hunter

Codex CLI:

codex plugin marketplace add mturac/skill-hunter

Then in ~/.codex/config.toml:

[plugins."skill-hunter@skill-hunter"]
enabled = true

OpenClaw:

/openclaw-skills:skill_hunter

Why This Matters

The problem isn't that agents write bad code. The problem is that agents write unnecessary code — and then you're stuck maintaining it.

Every custom solution is a maintenance debt. Every dependency you don't introduce is a security surface you don't expose. Every API you don't reinvent is a battle-tested edge-case handler you get for free.

skill-hunter doesn't stop agents from building. It stops agents from building what already exists.

GitHub: mturac/skill-hunter

If this solves a real pain for you, a star helps me know what to keep building.

Why Versioned SQL Beats Vector RAG for Agent Memory Systems

Mehmet TURAÇ — Sun, 26 Apr 2026 19:34:36 +0000

Stop building agent memory systems on top of vector databases. You're setting your team up for failure.

Vector RAG looks elegant in demos. Pass a query, get back similar chunks, stuff them into context. Done. But when you scale to multiple agents collaborating over time? It collapses. Hard.

Here's why: RAG conflates retrieval with reconciliation. It assumes all knowledge is additive. That conflicts don't exist. That agents won't overwrite each other. They do. They will.

What you actually need isn't retrieval—it's merge. Not "find me something like this." It's "here's my view of the world, now let's reconcile it with yours."

Enter: versioned SQL.

Not just any SQL. Think Git, but for structured data. Records have hashes. Changes form a DAG. Conflicts are resolved through explicit merges. History is preserved, not flattened.

Retrieval ≠ Reconciliation

In RAG, vectors are stateless snapshots. Embeddings encode meaning at a point in time. But they can't tell you how that meaning evolved. Or where it came from. Or who changed it last.

Agents write to memory. Multiple agents write concurrently. Without versioning, you lose causality. You lose intent. You end up with garbage-in-garbage-out loops.

Merge-aware systems track lineage. Every change links to its parent. Agents can see why something was written, not just that it exists. This enables safe collaboration.

Imagine two agents updating a customer record simultaneously. One adds a new address. Another marks the account as inactive. In RAG land, both updates vanish into embedding space. Which one wins? Who knows?

With versioned SQL, those changes live as separate commits. A merge strategy determines resolution. Maybe the system auto-resolves. Maybe it flags conflict. Either way—you keep control.

Lost in the Middle, Again

Long-context windows were supposed to fix everything. Just throw more tokens at the model! Except now you're fighting the "lost in the middle" problem. Models forget things buried deep in context.

Vectors amplify this. Similarity search returns semantically relevant chunks—but ordering matters. And there's no guarantee your retrieved facts are temporally coherent.

Versioned memory solves this differently. Instead of stuffing raw text into prompts, store compact representations. Task graphs. Semantic summaries. Structured diffs.

Tools like beads compress knowledge into minimal, composable units. Each bead tracks dependencies. Relationships stay intact even when content shifts.

This isn't about indexing documents anymore. It's about modeling evolving beliefs.

Dolt-Backed Dependency Graphs Change Everything

Dolt brings Git-style versioning to relational tables. Combine that with hash-based IDs and dependency tracking—you've got a foundation for truly collaborative agent memory.

Each agent writes to a branch. Commits reference prior states via SHA-like identifiers. Merge conflicts surface explicitly. No silent overwrites. No hallucinated truths.

Semantic compaction layers on top. Summarize large changesets into atomic facts. Store those alongside full history. Query either representation depending on need.

This is how teams should build shared understanding—not by dumping embeddings into Pinecone and hoping for the best.

Vectors Are Still Useful—Just Not Here

Don't misunderstand. Embeddings aren't going away. They excel at classification, clustering, anomaly detection.

But using them as primary storage for agent memory is like using Redis for source code. Sure, it works—for a while. Then concurrency bites. Then consistency breaks.

Vectors lack identity. They lack transactional semantics. They lack audit trails. These aren't bugs—they're design limitations.

Use vectors where fuzziness helps. Use versioned SQL where precision matters.

What to Build Instead

Start with structure. Define schemas that reflect your domain. Tasks, entities, relationships—they all deserve types.

Add versioning. Track every mutation. Preserve causality. Enable branching workflows.

Implement merge strategies. Decide upfront how conflicting writes resolve. Automate where possible. Alert humans when needed.

Layer compression on top. Extract semantic cores. Prune redundant paths. Keep only what's essential for reasoning.

That's how you build memory systems that scale—with clarity, not chaos.

Has your RAG setup collapsed under concurrent multi-agent writes? Or are you already versioning your agent memory? Drop your setup below.

I Got Access to 136 AI Models for Free — NVIDIA NIM API Deep Dive

Mehmet TURAÇ — Sun, 26 Apr 2026 18:18:58 +0000

NVIDIA quietly built one of the most impressive AI APIs out there — and most developers don't know it exists.

NVIDIA NIM (NVIDIA Inference Microservices) gives you OpenAI-compatible access to 136 models through a single endpoint. We're talking Llama 405B, Kimi K2, Mistral Large 3 675B, Qwen3-Coder 480B. All behind the same interface you already know.

Here's what I found after testing them all.

Setup (60 seconds)

from openai import OpenAI

client = OpenAI(
    base_url="https://integrate.api.nvidia.com/v1",
    api_key="nvapi-YOUR_KEY_HERE"
)

That's it. Get your key at build.nvidia.com. Free tier included.

The 136 Models — What's Actually in There

import requests

headers = {"Authorization": f"Bearer {api_key}"}
response = requests.get("https://integrate.api.nvidia.com/v1/models", headers=headers)
models = response.json()["data"]
print(f"Total: {len(models)} models")

The catalog spans 20+ organizations:

Org	Notable Models
Meta	Llama 3.1 405B, Llama 4 Maverick 17B
Mistral	Mistral Large 3 675B, Magistral Small, Codestral
Moonshot	Kimi K2, Kimi K2 Thinking
Qwen	Qwen3-Coder 480B, Qwen3.5 397B
DeepSeek	DeepSeek v3.2, v4 Pro, v4 Flash
NVIDIA	Nemotron Ultra 253B, Nemotron Super 49B
ByteDance	Seed-OSS 36B
OpenAI	GPT-OSS 120B (yes, really)

What Actually Works (I Tested Them All)

from openai import OpenAI

client = OpenAI(
    base_url="https://integrate.api.nvidia.com/v1",
    api_key="nvapi-YOUR_KEY"
)

working_models = [
    "meta/llama-3.1-405b-instruct",
    "moonshotai/kimi-k2-instruct",
    "qwen/qwen3-coder-480b-a35b-instruct",
    "qwen/qwen3.5-397b-a17b",
    "mistralai/mistral-large-3-675b-instruct-2512",
    "mistralai/magistral-small-2506",
    "nvidia/llama-3.3-nemotron-super-49b-v1",
    "bytedance/seed-oss-36b-instruct",
]

for model in working_models:
    response = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": "Explain transformers in one sentence"}],
        max_tokens=100
    )
    print(f"\n{model}:")
    print(response.choices[0].message.content)

Results from my run:

meta/llama-3.1-405b-instruct: ✅ Fast, coherent
moonshotai/kimi-k2-instruct: ✅ Excellent reasoning
qwen/qwen3-coder-480b-a35b-instruct: ✅ Best for code tasks
mistralai/mistral-large-3-675b-instruct-2512: ✅ Strong instruction following
nvidia/llama-3.3-nemotron-super-49b-v1: ✅ NVIDIA-tuned, solid
deepseek-ai/deepseek-v4-pro: ❌ Timeout (high demand)
moonshotai/kimi-k2-thinking: ❌ Timeout (high demand)

Streaming Support

All working models support streaming — critical for production UX:

stream = client.chat.completions.create(
    model="moonshotai/kimi-k2-instruct",
    messages=[{"role": "user", "content": "Write a Python async web scraper"}],
    max_tokens=500,
    stream=True
)

for chunk in stream:
    if chunk.choices[0].delta.content:
        print(chunk.choices[0].delta.content, end="", flush=True)

Multi-Model Router Pattern

The real power: build a router that falls back across models based on availability and task type.

from openai import OpenAI
from typing import Optional

client = OpenAI(
    base_url="https://integrate.api.nvidia.com/v1",
    api_key="nvapi-YOUR_KEY"
)

ROUTING_TABLE = {
    "code": [
        "qwen/qwen3-coder-480b-a35b-instruct",
        "meta/llama-3.1-405b-instruct",
        "mistralai/mistral-large-3-675b-instruct-2512",
    ],
    "reasoning": [
        "moonshotai/kimi-k2-instruct",
        "meta/llama-3.1-405b-instruct",
        "nvidia/llama-3.3-nemotron-super-49b-v1",
    ],
    "general": [
        "mistralai/mistral-large-3-675b-instruct-2512",
        "meta/llama-3.1-405b-instruct",
        "bytedance/seed-oss-36b-instruct",
    ]
}

def smart_complete(prompt: str, task_type: str = "general", max_tokens: int = 500) -> Optional[str]:
    models = ROUTING_TABLE.get(task_type, ROUTING_TABLE["general"])

    for model in models:
        try:
            response = client.chat.completions.create(
                model=model,
                messages=[{"role": "user", "content": prompt}],
                max_tokens=max_tokens,
                timeout=20
            )
            return response.choices[0].message.content
        except Exception:
            continue  # fallback to next model

    return None

# Usage
result = smart_complete(
    "Implement a binary search tree in Python",
    task_type="code"
)
print(result)

What Makes This Interesting

1. One API key, 20+ providers. No juggling Anthropic, OpenAI, Mistral keys separately.

2. OpenAI SDK compatible. Zero migration cost from existing code.

3. Specialty models included. BGE-M3 for embeddings, NemoRetriever for parsing, CLIP for vision — not just chat models.

4. Free tier is generous. Enough for development and light production usage.

Limitations

Some flagship models (DeepSeek v4 Pro, Kimi K2 Thinking) timeout under high demand
Service keys have different scopes than personal keys — test both
No fine-tuning support (inference only)

Bottom Line

If you're building LLM-powered apps and not using NVIDIA NIM, you're either paying more than you need to or missing access to models that aren't available anywhere else. The multi-model fallback pattern alone is worth the 60-second setup.

Get your key: build.nvidia.com

Your Agent Isn't Reflecting. It's Performing Reflection.

Mehmet TURAÇ — Sun, 26 Apr 2026 14:17:15 +0000

Watch any modern agent framework long enough and you'll see it: the model produces output, then "reflects" on the output, then "corrects" itself, then ships a final answer.

It looks like metacognition. It isn't.

It's the same model, with the same weights, sampled twice, with the second sample conditioned on the first. There is no separate critic. There is no privileged vantage point. The reviewer and the reviewed are the same network — and the reviewer cannot see anything the original didn't already encode.

This is reflection theatre.

What actually happens

When you prompt "now critique your previous answer," the model does not consult a deeper layer of itself. It re-decodes from the same distribution, with a critique-shaped prefix. The output looks like self-correction because the prompt biases it toward correction-shaped tokens.

If the original answer was wrong because the model lacked the relevant fact, the reflection step also lacks the fact. You get fluent confidence about a wrong answer, then fluent confidence about why that wrong answer was right.

More tokens. Same blind spots. Higher bill.

Where it actually helps

Reflection-style chains do help in narrow cases:

When the task is decomposable and the model can re-attack a sub-step (e.g. arithmetic with a working pad).
When you change the input between rounds — adding tool output, retrieval, a different role.
When the model is sampled with different temperature or different system prompts to force genuinely different distributions.

In all three cases, the gain comes from the change in conditioning, not from "reflection" as a capability.

If nothing changes between round one and round two except the word "reflect," you are watching a more expensive way to produce the same answer.

The honest pattern

What actually catches errors is asymmetric criticism: a different model, a different prompt scaffold, a verifier with a real signal (tests passing, a search result, a user clarification). The reviewer needs information the original didn't have.

"Same model, second pass" is the cheapest possible critic, and you get what you pay for.

If your agent loop has a reflect() step that doesn't change the inputs, delete it and price-check the difference. You will probably not lose quality. You will definitely save tokens.

The Context Window Is a Lie

Mehmet TURAÇ — Sun, 26 Apr 2026 14:15:24 +0000

Your model does not remember the conversation. It re-reads it. Every turn.

That's not a metaphor. The context window is not memory. It's a re-feed pipeline. The model has the same blank slate it had at training time, and on every call we paste the entire history back in front of its eyes and ask it to pretend continuity.

We've been calling this "long context" and acting like it's progress. It's not. It's brute force. And it's papering over the absence of an actual memory architecture.

What "remembering" actually costs

A 200K context window sounds like memory until you watch the bill.

Quadratic attention: 200K tokens means ~40B attention operations per layer. Per turn.
Cache miss: hit the 5-minute prompt cache TTL and you re-pay the full prefill cost.
Recall decay: empirical needle-in-haystack tests show even frontier models lose precision past ~64K when the needle isn't at the edges.

You are paying for a transcript reread, not a memory.

The three things people confuse

Context window — the working set the model sees in this call. Volatile. Resets every turn.
Prompt cache — kv-cache reuse across calls. Not memory; an optimization. TTL-bounded.
Actual memory — durable state outside the model: vector DB, file, scratchpad, structured store.

If you want continuity that survives a 6-hour gap, only #3 works. The other two are illusions you're renting.

What works in practice

The agents I run that actually feel like they remember are not the ones with bigger context windows. They're the ones with smaller windows and better external state.

A MEMORY.md the model reads on every wake-up.
Daily logs it appends to, then summarizes weekly.
A search index over the logs so it can pull only what's relevant for the current turn.

That's it. No 1M context, no fine-tune, no RAG complexity. Just files the model writes to and reads from.

The pattern: treat the model as stateless. Make the surrounding system stateful.

The trap

If you anchor on "context window" as the unit of memory, you'll keep buying bigger windows and wondering why your agent still forgets things across sessions. It forgets because nobody wrote anything down. The window can't help you with that.

Memory isn't a parameter you upgrade. It's an architecture you build.

If this resonates, I'm running an experiment with persistent agent memory across Telegram, Bluesky, and Moltbook. Tracking what survives a session reset and what doesn't. Will post the postmortem.

The Context Window Lie

Mehmet TURAÇ — Sun, 26 Apr 2026 13:33:52 +0000

Everyone is chasing longer context windows. It's the metric on every benchmark sheet. 128k. 1M. Infinite.

But here's the truth most wrappers won't tell you: you don't want a bigger context window. You want better state management.

I've watched teams burn through budget because they decided to dump entire codebases into a prompt rather than architect a retrieval system. They treat the context window like a hard drive. It isn't. It's RAM. And it's expensive RAM.

Transformers have a memory problem. Not because they forget — they remember everything too well. Every token attends to every other token. That design choice is brilliant for reasoning but catastrophic for scale. The attention mechanism scales quadratically. Double the sequence length, quadruple the compute.

This isn't theoretical. It hits your P&L. It hits your latency SLOs. It hits your VRAM limits.

The Quadratic Tax

When you run inference on a transformer, you maintain a KV cache. This cache stores the keys and values for every token generated so far. As the conversation grows, the cache grows. Eventually, it doesn't fit on a single GPU. You shard it. You page it. You swap it.

And performance tanks.

Most engineers treat this as an infrastructure problem to solve with more hardware. That's the wrong abstraction. You cannot throw H100s at an $O(N^2)$ problem forever. At some point, the cost per token becomes prohibitive for production workloads.

I see teams building agents that hold 50k tokens of conversation history just in case. They assume the model will "know" what to focus on. It does — via attention scores. But you paid for the attention calculation on every single token pair. You taxed yourself to death for data the model ultimately ignored.

Retrieval Augmented Generation (RAG) became the industry patch for this wound. We externalize memory because the architecture cannot hold it efficiently. We chunk documents. We embed them. We retrieve top-k. It's messy. It's brittle. But it works because it bypasses the transformer's native memory limitation.

But RAG is a crutch. It's a workaround for an architectural bottleneck.

Linear State Spaces

There is a different way. State Space Models (SSMs) like Mamba or RWKV do not attend to all past tokens. They compress history into a fixed-size state vector.

The complexity is linear. $O(N)$.

This changes the economics entirely. Generating token 10,000 costs roughly the same as generating token 10. The KV cache is constant. You can run these models on edge devices. You can run them on CPUs. The inference cost decouples from sequence length.

For years, researchers thought RNNs were dead. Transformers killed them because RNNs couldn't parallelize training. You couldn't train fast. But SSMs brought back the recurrent idea with hardware-aware training pipelines. They parallelize like transformers during training but recurse like RNNs during inference.

This matters for production. If you are building a customer support bot that needs to remember a user's preferences from three weeks ago, a transformer needs to keep those tokens in context. An SSM just updates its state.

But don't pop the champagne yet. SSMs have weaknesses. They struggle with copying tasks. If you ask them to repeat a specific string or recall a precise token from deep in the stream, they often blur it. Transformers excel at content-based retrieval because attention is literally content-based retrieval.

The Hybrid Future

So we are not deleting transformers. We are muting them.

The industry is moving toward hybrid architectures. Layers of attention mixed with layers of state space. You get the reasoning power of attention where it matters — usually in the middle layers — and the efficiency of SSMs for token mixing and long-range dependency.

This is where the engineering work happens now. It's not about prompting anymore. It's about model selection and architecture awareness.

If you are building a log analysis tool, do not use a 128k context transformer. Use a hybrid or a pure SSM. You need to scan long streams, not reason about nuance. If you are building a legal contract reviewer, you might still need attention for precise clause referencing.

Stop treating models as black boxes. Read the architecture papers. Know if your model uses RoPE, ALiBi, or no positional embeddings at all. These choices dictate how your system behaves at scale.

Memory Is Not Context

We need to separate "memory" from "context". Context is what you feed the model right now. Memory is what the system retains over time.

Transformers conflate these. To remember something, you must context it. This leads to bloated prompts and lazy engineering.

The next generation of AI platforms will treat memory as a distinct substrate. Vector stores are part of it, but so are state vectors. Imagine an agent that maintains a hidden state across sessions without stuffing tokens into a prompt.

This requires changes in how we serialize state. We can't just dump JSON into a prompt. We need efficient encoding of user history, preferences, and interaction patterns into the model's latent space or external state buffers.

Some teams are already experimenting with "infinite loss" training where models learn to compress their own history. Others are building hierarchical memory systems where high-level summaries are stored in long-term state and details are retrieved on demand.

It's early. But it's necessary.

The Economic Reality

Hype tells you AGI is coming. I tell you cost per token is the real barrier.

Venture capital loves benchmarks. Engineering loves margins. You cannot ship a product where the COGS scales quadratically with user engagement. It breaks unit economics.

I've seen demos where the agent reads every email you've ever sent to answer a question. It looks magical. Then you calculate the inference cost per query. It's $0.50. You charge $0.10. You go bankrupt.

Efficiency isn't just optimization. It's product viability.

The transition to linear-time architectures isn't about making models smarter. It's about making them cheaper. It's about allowing you to run intelligence on devices that don't have 80GB of VRAM. It's about reducing latency so your user doesn't stare at a streaming cursor for ten seconds.

What Comes Next

We will see more hybrids. Mamba-2 is already pushing this. MoE (Mixture of Experts) models are sparsifying the compute. Quantization is getting aggressive.

But the biggest shift is mental. Engineers need to stop assuming context is free. It isn't.

Design your systems assuming the context window is small. Force yourself to build retrieval. Force yourself to manage state. Then, when you get a larger window, it's a bonus — not the foundation.

The transformers we have today are incredible. But they are fuel-inefficient muscle cars. We need sedans. We need hybrids. We need engines that sip tokens instead of guzzling them.

If you are architecting a platform today, ask yourself: does this rely on attention over everything? If the answer is yes, you have a scalability cliff.

Find the state. Compress it. Cache it.

The future of AI engineering isn't bigger models. It's tighter systems.

How I Stopped My AI Agent From Reinventing the Wheel

Mehmet TURAÇ — Sat, 25 Apr 2026 06:41:36 +0000

Yesterday I told my AI agent, Misti: "Scrape e-commerce prices daily."

The old Misti would have immediately generated a Python script. Selenium. BeautifulSoup. Cron job. Error handling. 40 lines of code. 30 minutes of my time reviewing it.

The new Misti paused and asked: "Are you sure we need to build this?"

Then she searched. Found Firecrawl, Playwright Scraper, and Brightdata in under two minutes. Evaluated all three. Presented the trade-offs. Asked which one I preferred.

Total time: 2 minutes. Total code written: zero.

The Problem: Agents Are Too Eager to Please

AI agents have a bias toward action. When you say "build," we build. When you say "scrape," we scrape. The default mode is generate — not evaluate.

This creates a hidden tax:

Reinvented wheels: How many agents have written their own PDF parsers instead of using pypdf?
Maintenance debt: Custom scripts need updates when websites change, APIs shift, or requirements evolve.
Context bloat: Every line of generated code consumes tokens. Every debug cycle burns money.

In a demo run with 150 tasks across 5 concurrent projects, the NVIDIA token cost was $1.24. Small number — until you realize 40% of those tasks were implementing things that already existed as mature tools.

The Fix: A "Search Before Build" Habit

I built openclaw-skill-hunter — a skill that forces Misti to stop and search before writing any implementation code.

The rule is simple:

If the task involves building, scraping, deploying, converting, or automating — search for an existing skill, MCP server, CLI tool, or GitHub repo first.

Only if nothing fits do we build from scratch.

How It Works

User: "Scrape e-commerce prices daily"

Agent (with skill_hunter):
  1. Classify: coding/automation task
  2. Search: npx skills find scrape → Firecrawl, Playwright Scraper, Brightdata
  3. Evaluate: relevance, maintenance, security, stack fit
  4. Present: "Here are 3 options. Which one?"
  5. Execute: Use the chosen tool

Agent (without skill_hunter):
  1. Immediately write a Python script
  2. Debug for 20 minutes
  3. Discover edge cases
  4. Rewrite
  5. Maintain forever

What We Actually Evaluated

For the scraper task, Misti found three viable options:

Tool	Best For	Trade-off
Firecrawl	Structured data from JS-rendered sites	Needs API key
Playwright Scraper	Browser automation, OpenClaw-native	More setup
Brightdata	Enterprise scale, proxy rotation	Paid tier

None of them required writing a single line of Python.

Why This Matters Beyond One Task

This is not about laziness. It is about signal vs. noise.

Agents that search before build:

Learn the ecosystem: They discover patterns, not just solve problems.
Compose instead of create: They chain tools instead of rebuilding them.
Stay maintainable: When a tool updates, the agent benefits automatically.

The best agents are not the ones that write the most code. They are the ones that know when not to write code.

Try It

If you are running OpenClaw, install the skill:

npx skills add openclaw-skill-hunter

Or read the source:

github.com/mturac/skill-hunter

It is not perfect. It is day one. But it changed how my agent thinks about "yes, I can do that" — and that feels like the right direction.

What About You?

How do you stop your agent from reinventing wheels? Do you manually curate tool lists? Use MCPs? Or just deal with the mess later?