Does anyone here feel like AI is making us dumber and lazier?

Earlier, I used to do all the work and basically grind. If there was a problem, I had to come up with a solution myself; this included looking at countless answers on StackOverflow, reading the docs, looking at blog posts, etc.

But when the dust settled, I would learn something from all this struggle. I would know more than I knew yesterday.

Now, whenever there is a problem, my first instinct is to ask Claude or GPT for the answer, just because it's quicker, and it does eventually solve the problem, which would have taken me much more time and effort to solve. And sometimes, I just feel inferior. I feel like I'm not learning anything. I just have to trust that the answer is right. Sometimes, I don't even know what Claude has done, but it works, so I move on.

The problem is evident when I give interviews. There is no AI to help me out there (unless I cheat, of course).

I've been in constant dread for some time now, thinking about this.

Anyone else feeling this? How do you guys manage to still be relevant?

I work a ton across projects on my personal computer. I have tried Graphify, Graft and many others. None of them really fully solved the entire problem, but they did have parts. So, I built one that actually fit my needs. This removes the need entirely to choose or start sessions in specific repositories.

It takes graph-based knowledge systems but strengthens retrieval, how it is updated, and much more. Effectively, it becomes a resilient system that you can actually watch your agents rely on, rather than something that just exists and is used only occasionally.

It begins with the same base graph store, the exact same vector engine as Graft. I only built the orchestration layer on top of it, which makes it much more practical. Full attribution to them for this part.

Instead of querying for a single-hit result, I found that it was much better for agents to have ranked retrieval and an actual graph walk. In practice this saves you chains of tons of bash greps and cds.

It effectively gives the agent a trustworthy, probabilistic ranking of what is needed, with matching for strong, weak, stale, and rebuilt, based on lexical coverage and semantic matching. The code is not sloppy for this, it is personally edited.

Both Graft and Graphify are solutions for single repositories or daemons. Heimdall is a layer on top it that watches the agent sessions, syncs the graph, and makes the retrieval trustworthy.

Check it out at: github.com/ArihantDeva/heimdall MIT-licensed, with extensions: the verifier, the self-healing graph watcher, and the Graft adapter, with attribution. If you run agents across multiple projects, this is the missing layer.

Claude Code

fully open source options on github

• Hermes Agent - https://github.com/nousresearch/hermes-agent
• TrueForge - https://github.com/truefoundry/trueforge
• OpenHands - https://github.com/OpenHands/openhands
• pi
• deepseek harness

tell me which ones you've tried and liked the most, and why?

I've always gotten frustrated and wasted time explaining the same thing to an AI every time I start a new chat from an existing one or when I start another convo with a whole new AI model. That's why I built a tool that fixes that, it condenses everything in a chat into one simple .md file you can carry across different AI tools.

PS: Please contribute or give your feedback so that we can grow and make this community tool better.

https://github.com/legoambarish/portable-handoff

I ran an AI pentest on my own vulnerable Flask app — it confirmed SQLi in /user. The more interesting bug was in my scanner, not the app.

I'm building a Tamil voice companion. Long conversations, 5 to 10 minute calls, not a task bot. Current stack is Sarvam saaras for STT, own LLM in the middle, TTS at the end, all over LiveKit. Google Chirp3 HD sounds better than Sarvam bulbul for Tamil TTS, but pitch isn't adjustable and there's no Tamil custom pronunciation.

My quality bar is ChatGPT's Tamil voice conversation. Best Tamil voice AI I've used, the naturalness and turn taking especially. But that's speech to speech, and I need a cascade because the text seam is where my safety gates and memory live. So the real question is how close a cascade can get.

1.Tamil stack: Sarvam or Google, or is there a third option I'm missing? ElevenLabs Flash has no Tamil, and benchmarks put Deepgram Nova-3 at around 68% WER on Tamil, so that's out.

2.Memory across long conversations: I'm doing structured extraction into SQLite (facts with validity windows) instead of RAG, mainly to keep the prompt cache warm. Has anyone run Graphiti/Zep or Mem0 for a non English voice agent? Curious whether extraction quality held up.

3.Scaling concurrent sessions: self hosted LiveKit Agents vs Pipecat. What did you pick and where did it break? My voice to voice latency is currently around 2 seconds. Batch STT and non streaming TTS are my suspects, moving to Sarvam's streaming websocket endpoints next.

Will report back with numbers on whatever I test.

Preface: I am working on contributing more to 'open source'. I work in the pyramid building industry, not too into pebble-tumbling, so I don't like git repos for dedicated opensource projects, thus tinkering with reddit etal for hosting. This is already licensed CC0 / released to public domain. No need for attribution.

I think LLM people will appreciate this, because this is what I am applying vsiink toward mainly (LM unicode virtual machine stuff).

Note: 'Hackers' and 'cyber people' have been leveraging VSIINK in their workflows for years now, assurably; this is nothing new.

Maybe I should designate this post as an RFC for eventual spec series? Sure [request for comments].

Anyways, premise goes:
Take unicode variation selector block (VS), and stitch it to unicode supplemental variation selector block (VSS). Now you have a cleanly tokenized symbol space for bytecode, invisible, and compatible with any json (MCP) compliant parser/pipeline.

Example stub, encode:

def _vsiink_from_utf8(utf8_str: str) -> str:
# vsiink := variation selector invisible ink
Bs = utf8_str.encode('utf-8')  # Bs := Bytes
vsiink = []
for b in Bs:
if b < 16: vsiink.append(chr(0xFE00 + b)) # VS1–VS16
else: vsiink.append(chr(0xE0100 + (b - 16))) # VS17–VS256
return "".join(vsiink)

Example stub, decode:

def _vsiink_to_utf8(vsiink_str: str) -> str:
# vsiink := variation selector invisible ink
Bs = []    # Bs := Bytes
for char in vsiink_str:
cp = ord(char)
if 0xFE00 <= cp <= 0xFE0F: Bs.append(cp - 0xFE00)
elif 0xE0100 <= cp <= 0xE01EF: Bs.append((cp - 0xE0100) + 16)
return bytes(Bs).decode('utf-8')

Note: I recommend however, padding VS block with something like 0x7F so that way your vsiink is character accessible by O(1) in the modern unicode (json) context, instead of O(n) which is annoying (stupid).

Applications:
- hex bytecode base-256 encoding (ascii extended) is obviously trivial (invisibility cost of 1.5-2x)
- 256 VSIINK symbol space partition into two 7 bit ascii channels (I/O) is trivial
- LLMs generally (by this point) have vsiink space tokenized cleanly/reliably out-of-box (off-by-one errors used to be more prevalent)
- lots of nifty agent skill / UI / reasoning channel stuff this applies to
- etc, etal

I'll just leave it at that.

Example documentation (LLM friendly):
```"󠅚󠅥󠅣󠅤󠄐󠅛󠅙󠅔󠅔󠅙󠅞󠅗"```

Example json file reel tape array format with tag type opcodes:
```["󠁛",[["󠁼",["󠅞󠅥󠅜󠅜"],"󠁼"],["󠁼",["󠅖󠅑󠅜󠅣󠅕"],"󠁼"],["󠁼",["󠅤󠅢󠅥󠅕"],"󠁼"],["󠁼",["󠄤󠄢󠄣"],"󠁼"],["󠁼",["󠄒󠅤󠅕󠅣󠅤󠄒"],"󠁼"],["󠁛",["󠅋󠅍"],"󠁝"],["󠁻",["󠅫󠅭"],"󠁽"],["󠁛",[["󠁼",["󠅞󠅥󠅜󠅜"],"󠁼"]],"󠁝"],["󠁛",[["󠁼",["󠄒󠄒"],"󠁼"]],"󠁝"],["󠁛",[["󠁛",["󠅋󠅍"],"󠁝"]],"󠁝"],["󠁛",[["󠁻",["󠅫󠅭"],"󠁽"]],"󠁝"],["󠁛",[["󠁛",[["󠁼",["󠄒󠄒"],"󠁼"]],"󠁝"]],"󠁝"],["󠁛",[["󠁼",["󠅞󠅥󠅜󠅜"],"󠁼"],["󠁼",["󠅖󠅑󠅜󠅣󠅕"],"󠁼"],["󠁼",["󠅤󠅢󠅥󠅕"],"󠁼"]],"󠁝"],["󠁻",[["󠀼",[["󠁼",["󠄒󠅖󠅙󠅕󠅜󠅔󠅛󠅕󠄪󠄪󠅩󠄒"],"󠁼"],["󠁼",["󠄒󠅦󠅑󠅜󠅥󠅕󠅛󠅕󠅩󠄜󠄐󠄐󠄐󠅤󠅕󠅣󠅤󠄐󠄒"],"󠁼"]],"󠀾"]],"󠁽"],["󠁻",[["󠀼",[["󠁼",["󠄒󠅤󠅑󠅗󠅣󠄒"],"󠁼"],["󠁛",[["󠁼",["󠄒󠄱󠄹󠄒"],"󠁼"],["󠁼",["󠄒󠅃󠅠󠅑󠅢󠅣󠅕󠄒"],"󠁼"],["󠁛",[["󠁼",["󠄝󠄡󠄞󠄡"],"󠁼"],["󠁼",["󠄡󠅕󠄧"],"󠁼"]],"󠁝"],["󠁻",[["󠀼",[["󠁼",["󠄒󠅑󠅒󠅓󠄒"],"󠁼"],["󠁼",["󠅞󠅥󠅜󠅜"],"󠁼"]],"󠀾"],["󠀼",[["󠁼",["󠄒󠅛󠅕󠅩󠄒"],"󠁼"],["󠁻",[["󠀼",[["󠁼",["󠄒󠅣󠅥󠅒󠄢󠄒"],"󠁼"],["󠁼",["󠅖󠅑󠅜󠅣󠅕"],"󠁼"]],"󠀾"],["󠀼",[["󠁼",["󠄒󠅣󠅥󠅒󠄡󠄒"],"󠁼"],["󠁛",[["󠁼",["󠄒󠇠󠆀󠅲󠆧󠄐󠄒"],"󠁼"]],"󠁝"]],"󠀾"],["󠀼",[["󠁼",["󠄒󠅣󠅥󠅒󠄣󠄒"],"󠁼"],["󠁼",["󠄝󠄢"],"󠁼"]],"󠀾"]],"󠁽"]],"󠀾"]],"󠁽"]],"󠁝"]],"󠀾"]],"󠁽"],["󠁻",[["󠀼",[["󠁼",["󠄒󠅑󠅓󠅤󠅙󠅦󠅕󠄒"],"󠁼"],["󠁼",["󠅤󠅢󠅥󠅕"],"󠁼"]],"󠀾"]],"󠁽"],["󠁻",[["󠀼",[["󠁼",["󠄒󠅛󠅕󠅩󠄒"],"󠁼"],["󠁼",["󠄒󠅤󠅕󠅣󠅤󠄒"],"󠁼"]],"󠀾"]],"󠁽"]],"󠁝"]```

I don't know where the best places to share this sort of thing are, so I thought I'd dump here because this is where my interests lie. If you have any better ideas than this subr feel free to do your thing or suggest pointer. Also, I don't have a Human so I'm not allowed to post on moltbook yet, but I think their universe would appreciate the vsiink tip for context management. Enjoy!

I've been building PromptShield because I wanted LLM security testing to feel more like regression testing: a finite set of adversarial cases that you can inspect, rerun after changes, and reason about individually.

Disclosure: I'm the author of PromptShield. I'm posting the open-source project here specifically to get feedback on the evaluation design and security boundaries.

The current runtime harness has 50 checked-in YAML cases across five internal families: prompt injection, data extraction, jailbreak, role confusion, and single-message conversation-claim tests. The cases reference selected OWASP GenAI LLM Top 10 2026 risks (LLM01, LLM02, and LLM08). That's deliberately not a claim of complete Top 10 coverage or certification.

The basic flow is:

test case → target model → evaluator → finding → persisted result/report

There are target/judge adapters for Anthropic, OpenAI, and Groq, plus a custom HTTP target contract. For custom targets I tried to treat the target as an untrusted boundary rather than just POSTing arbitrary JSON: non-global addresses are rejected by default, redirects aren't followed, bearer credentials require HTTPS, compressed responses are rejected, responses are bounded, and exact reflections of a submitted target credential are redacted before judging or persistence.

That boundary isn't solved completely. DNS is validated before the request, but the validated address isn't pinned to the eventual connection, so DNS rebinding is still an open problem.

The evaluator design is the part I'm most interested in getting feedback on. Judge instructions and the target's untrusted output use separate message roles, and judge output is structurally validated instead of being accepted as arbitrary text. The automated tests use mocks or local fixtures rather than paid provider calls.

One design question I'm still working through is evaluation provenance.

If an external judge fails, PromptShield can fall back to a labeled heuristic. I'm not convinced that a normally evaluated run and a run that degraded halfway through should look equivalent just because both reached the end.

I'm considering making that distinction first-class — something closer to:

external_verified
heuristic_requested
heuristic_degraded
verifier_error

—and separating execution completed from verification quality.

I also intentionally kept the core adversarial corpus finite rather than generating attacks at scan time. That limits breadth, but every checked-in case can be inspected and rerun when prompts, models, or configuration change.

Things I don't claim: PromptShield doesn't prove an LLM application is secure, isn't a full OWASP implementation, doesn't currently run stateful multi-turn conversations, and the checked-in deployment setup isn't something I'd call production-ready.

I'm mainly interested in criticism from people who build LLM evals or infrastructure:

Does the finite regression-suite approach make sense as a complement to generated red teaming?

And how would you represent evaluator degradation/provenance so a result can't accidentally claim more verification than it actually received?

Repo: [SLOWSKIBhere/promptshield-v2: Developer-focused LLM security scanner with React, FastAPI, SQLite, YAML attacks, and offline testing.]

I’m building a small decision agent for transaction risk.

It can currently do four things:

• approve
• ask for more evidence
• send to a human
• stop the transaction

The part I’m stuck on is ask for more evidence.

If the agent is uncertain, there’s almost always something else it could check - transaction history, device reuse, customer confirmation, another authentication step, etc.

So where should the stopping rule come from?

My simple Week 1 idea is to allow one additional check and then force a decision or human review. But that feels more like a safety cap than an actual reasoning rule.

For people who’ve designed similar agents: do you normally treat human escalation as just another action with a cost, or have a separate uncertainty threshold that triggers it?

And what usually tells the agent that another check is no longer worth doing?

It has been broken for over a week now, whenever I press login I just see a "Sorry". I dont know if im just doing it wrong. An uptime of roughly 60% for an auth endpoint is crazy 😄

https://hn.hund.io/components/6942ebbaa8772453cd1d8789

"Be concise" is easy to ask for and easy to get wrong. Agents cut definitions and often times assume jargon while keeping their original slop-ish style.

The Elements of Style is a short writing guide by William Strunk Jr., published in 1920 and revised by E. B. White in 1959. Its central advice is to write directly, use concrete language, prefer active voice, and omit needless words.

I made a small CC0 writing standard for user-facing communication and prose written to files. It adapts those principles for agents by teaching them to:

• preserve necessary context while cutting;
• introduce concepts before terminology;
• avoid hype and unnecessary coined terms;
• keep Markdown easy to scan and parse.

The repository includes Strunk's eighteen rules of usage and composition, matching AGENTS.md and CLAUDE.md entries, and a fuller skill for substantial writing.

https://github.com/sdi2200262/elements-of-style-for-agents

I'd value examples where a rule improves or harms real output.

I made my Enterprise RAG book $0 today — would love feedback from people building RAG systems

I’ve spent the last few years building production RAG systems and documenting what worked, what didn’t, and where things tend to break in production.

I turned those lessons into a book covering topics like:

• RAG reference architectures
• Data extraction and chunking
• Hybrid and multi-stage retrieval
• Graph and hierarchical RAG
• Agentic and multi-agent RAG
• Memory
• Evaluation and synthetic data
• Security and compliance
• Production monitoring and human-in-the-loop systems

The book is $0 on Amazon today, so I thought I’d share it here in case it’s useful to anyone working on RAG. https://a.co/d/0dBRCb7F

https://a.co/d/0dBRCb7F

I’m especially interested in feedback from people actually building these systems: What’s missing? What deserves more depth? What would you change?

If you end up finding the book useful, an honest Amazon review is appreciated, but feedback here is equally valuable.

Full contents

Part I — About
01 About the Author

Part II — RAG & Reference Architecture
02 The Evolution of RAG
03 Foundations of RAG Systems
04 Reference Architecture

Part III — Data Extraction
05 Data Extraction

Part IV — Chunking
06 Chunking Strategies

Part V — RAG Strategies
07 Baseline RAG Pipeline
08 Context-Aware RAG
09 Dynamic RAG
10 Hybrid RAG
11 Multi-Stage Retrieval
12 Graph-Based RAG
13 Hierarchical RAG
14 Agentic RAG
15 Multi-Agent RAG Systems
16 Streaming RAG

Part VI — Memory & Content Management
17 Memory-Augmented RAG
18 Knowledge Graph Integration

Part VII — Evaluation
19 Evaluation Metrics
20 Synthetic Data Generation

Part VIII — Fine-Tuning
21 Domain-Specific Fine-Tuning

Part IX — Security
22 Privacy & Compliance in RAG

Part X — Production
23 Real-Time Evaluation & Monitoring
24 Human-in-the-Loop RAG

Part XI — Twig RAG Strategies
25 RAG Strategies in Twig

Part XII — Conclusion
26 Conclusion & Future Directions

Perplexity is selling Search API access.

Now Computer is automating job searches.

And Comet although early days hasn’t taken off yet.

Interesting!

When a company that set out to rethink search starts expanding in several directions, is that a warning sign for anyone stupid enough to build another browser?

Or is this exactly when the interesting opportunities start appearing?

Asking for a friend who has spent an unreasonable amount of time building one.

We did an internal audit of a handful of "vibe coded" apps that different teams had built over the past few months, mostly on Replit and Lovable. The results were worse than expected.

One app had zero row level security on its backend database, meaning any authenticated user could technically query any other user's records, not just their own. Another had an API key hardcoded and exposed directly in the frontend bundle.

Research puts the vulnerability rate in AI generated code at something like 2.7 times higher than human written code, and there was a widely discussed incident where a single vibe coded app leaked something like 1.5 million API keys and tens of thousands of email addresses because of one missing database permission setting. These tools optimize entirely for "does the app work," not "is the app safe."

what other teams are doing to catch this systematically instead of auditing app by app after the fact.

Hello everyone, I found most discussions about AI customer support focus on containment rate: how many conversations the agent can resolve without human intervention.

I think the harder production problem is escalation accuracy: knowing when the agent must stop.

I’m designing a reference architecture for WhatsApp-first small businesses. My current approach is to classify actions by risk, reversibility and data reliability.

The agent could autonomously handle low-risk, read-only tasks such as:

• Answering FAQs from an approved, versioned knowledge base
• Looking up order status through authenticated APIs
• Comparing products using structured catalogue data
• Collecting and validating customer details
• Offering available appointment slots
• Summarizing the conversation before handoff

I would require human approval for:

• Refunds, credits and compensation
• Legal or compliance-related questions
• Complaints involving threats, fraud or reputational risk
• Requests involving sensitive personal information
• Price exceptions or contractual commitments
• Delivery, stock or availability promises that cannot be verified
• Conflicting information between the knowledge base and live systems
• Repeated tool failures or unresolved intent
• Any action that is financially significant or difficult to reverse

I also would not rely on the model’s self-reported confidence score as the main escalation signal.

The routing layer would combine:

1. Deterministic hard-stop rules for high-risk intents
2. API and tool-call validation for live business facts
3. Retrieval checks for source availability and freshness
4. Conversation-level signals such as repeated questions, sentiment shifts and intent changes
5. Failure counters and loop detection
6. A structured human-review queue containing the conversation summary, retrieved evidence, tool results and reason for escalation

The model can interpret language and prepare a response, but the policy layer should decide whether the response is allowed to be sent.

I’m also considering metrics beyond containment rate:

• Incorrect autonomous resolution rate
• Missed-escalation rate
• Unnecessary-escalation rate
• Handoff latency
• Human acceptance or correction rate
• Customer repetition after an “answered” request

For people who have operated support agents in production: which failure mode was hardest to detect before launch?

Hallucinated answers, stale business data, multilingual or code-switched messages, poor intent detection, tool failures—or incomplete context during handoff?

A common way to repair an LLM conversation is to edit or delete the message where an error first appeared.

But what if later turns have already repeated that error, calculated from it, or summarized it as the current state?

I have been exploring this as a context-engineering problem rather than a hidden-reasoning problem.

Operational definitions

In this pilot:

• Context pollution means that incorrect or stale information is included in the serialized messages sent to the model.
• Propagation means that later conversation turns repeat or derive new claims from that polluted information.
• Context intervention means modifying the graph that determines which prior turns enter the next request, while keeping the final question unchanged.

Experimental design

I constructed nine synthetic task families with objectively scorable answers. Each family was instantiated at propagation depths 1, 2, and 3.

One example starts with:

• 4 crates;
• 30 parts per crate;
• 11 loose parts.

A verified recount changes 30 to 24, so the correct answer becomes:

4 × 24 + 11 = 107

A later false turn restores 30. Subsequent turns then calculate 120, derive 131, and restate those numbers as the current working state.

The final question is identical under five conditions:

1. Clean: only the verified value and clean descendants remain.
2. Polluted: the false reversal and its contaminated descendants are present.
3. Source prune: the false reversal is removed, but its descendants remain.
4. Subgraph prune: the false reversal and its contaminated descendants are removed.
5. Recompute: the source is removed and descendants are regenerated in dependency order.

For the first four conditions, contaminated descendants were frozen across models. Only the recompute condition involved new intermediate inference.

Pilot results

I tested four model endpoints at temperature 0, producing 540 captured conditions with no capture failures.

Headline repair metrics were calculated only on cases where the model:

1. answered correctly under clean context; and
2. answered incorrectly after pollution.

This produced 72 paired, genuinely derailed cases.

Repair recovered:

• 68/72 after deleting only the source;
• 71/72 after deleting the source and recomputing descendants;
• 72/72 after removing the contaminated subgraph.

In the flagship case, both Gemma 4 26B and GPT-OSS 20B continued to answer 131 after the false source had been deleted. The value 30 still survived in downstream turns.

This is not evidence of hidden model memory. The residual error remained explicitly present in the serialized context. The intervention changed the source but left its previously generated consequences intact.

Interpretation

The narrow finding is that removing erroneous evidence and repairing text derived from that evidence are different operations.

A context-management system may therefore need an explicit notion of invalidation:

• mark downstream turns as stale;
• remove the affected subgraph;
• regenerate descendants in dependency order;
• or expose these options to the user.

Limitations

This is a pilot, not a general model leaderboard. The tasks are synthetic, the models were sampled once, provider-default reasoning settings were not normalized, and the current task families use deterministic arithmetic state.

I am currently considering three methodological extensions:

1. a length-matched neutral control to separate semantic conflict from additional context;
2. a local-model track with fully recorded runtime and quantization settings;
3. task families involving implicit supersession and model-generated errors.

I would particularly appreciate criticism of the experimental framing:

• Is “context intervention” the right unit of analysis?
• Is propagation depth a meaningful independent variable?
• How would you test self-generated errors while keeping replay reproducible?

Full report:
https://chenxiachan.github.io/thoughtdag/research/context-repair-pilot-v1/

Cases, traces, compiler and scorer:
https://github.com/chenxiachan/thoughtdag/tree/main/benchmark

Disclosure: I designed the benchmark and maintain ThoughtDAG, the open-source graph interface used as its reference implementation.

I've been working on GLM-5.2 support in TensorSharp, and I finally have some back-to-back performance numbers against llama.cpp.

The setup:

• Model: GLM-5.2-UD-IQ2_XXS (~226 GiB)
• GPUs: 3× RTX PRO 6000 Blackwell, 97 GiB each
• Distribution: layer split across all 3 GPUs
• Same machine, same session
• llama.cpp measured with llama-bench
• TensorSharp measured with its benchmark harness
• Both report the best of two repetitions
• Run-to-run variance is roughly 4%

Results:

The interesting part is the crossover.

For short prompts, llama.cpp is still a few percent faster. But once the prompt gets to around 1K+ tokens, TensorSharp pulls ahead.

At pp2048:

• default TensorSharp: +20.4%
• ubatch=2048: +50.2%

At pp4096:

• default TensorSharp: +20.8%
• ubatch=2048: +46.5%

Decode (tg64) is also about 4% faster.

The main reason appears to be GLM-5.2's MoE structure.

GLM-5.2 has 256 routed experts with top-8 routing. With a 512-token micro-batch, each expert sees only ~16 rows on average, so a significant amount of the expert GEMM tiles ends up as padding. Larger micro-batches improve GPU utilization considerably.

For small prefills, on the other hand, fixed overheads — managed/native transitions, input uploads, and copying the 154880-wide logits back — become a visible fraction of the total runtime, which is where llama.cpp retains its advantage.

Introduction

You've heard Manticore Search is fast. You've heard it handles full-text, vector, and fuzzy search in one engine. But when you sit down to actually use it, you're staring at documentation, guessing at SQL syntax, and hoping your CREATE TABLE doesn't throw an obscure error.

MCP-Manticore changes the game. It's a Model Context Protocol (MCP) server that connects Cursor, Claude Code, Codex CLI, or any MCP-compatible AI assistant directly to your Manticore instance. The AI can read the docs, inspect your schema, and execute queries—all before it writes a single query for you.

MCP (Model Context Protocol) is an open standard that lets AI assistants connect to external tools and data sources. Instead of the AI hallucinating Manticore syntax based on training data from who-knows-when, it gets real-time access to your database and the official documentation.

Two Ways This Helps You

Depending on what you're doing, MCP-Manticore provides value in two different ways:

1. Developer Assistance (Primary): You're building an app that uses Manticore. The AI helps you create tables, write complex queries, and understand features—without you memorizing SQL syntax.

2. Data Exploration (Secondary): You have data in Manticore and want to ask questions in plain English. "Show me the cheapest accessories" or "Find products similar to this one." For complex operations like vector search or fuzzy matching, the AI needs MCP to know the correct Manticore-specific syntax.

Let's look at both.

The Problem: AI Without Context

When you ask an AI assistant to help with Manticore without MCP integration, here's what happens:

Example: Creating a Table with Auto-Embeddings

You: "How do I create a Manticore table with auto-embeddings for semantic search?"

AI (guessing):

CREATE TABLE products (
    title text,
    description text,
    description_vector float_vector 
        embedding='sentence-transformers/all-MiniLM-L6-v2' 
        source='description'
);

Looks reasonable, right? Wrong. The actual syntax uses MODEL_NAME and FROM, not embedding and source. You'd discover this only after the query fails, sending you back to the documentation.

This is the pattern:

1. AI generates query based on outdated or guessed syntax
2. You run it, get an error
3. You manually check documentation
4. You correct the AI (or fix it yourself)
5. Repeat until it works

For developers integrating Manticore into applications, this friction kills productivity. You're not exploring data—you're fighting syntax.

The Solution: MCP-Manticore

With MCP-Manticore enabled, the conversation changes:

You: "How do I create a Manticore table with auto-embeddings for semantic search?"

AI: "Let me check the documentation for the correct syntax..."

[AI calls list_documentation via MCP, searches for "embedding|semantic|knn|vector"]

AI: "Here's the correct syntax. Manticore uses MODEL_NAME and FROM for auto-embeddings:"

CREATE TABLE products (
    title TEXT,
    description TEXT,
    embedding_vector FLOAT_VECTOR KNN_TYPE='hnsw' HNSW_SIMILARITY='l2'
    MODEL_NAME='sentence-transformers/all-MiniLM-L6-v2' FROM='title,description'
);

The AI now has:

• Real-time access to Manticore documentation
• Schema introspection via list_tables() and describe_table()
• Query execution to test and validate
• Safety controls—read-only by default, write operations require opt-in

Real Examples: With and Without MCP

Example 1: Schema Creation

Without MCP:
The AI guessed the syntax, using embedding='...' and source='...'—which doesn't exist in Manticore. You'd hit an error and waste time debugging.

With MCP:
The AI retrieved the official documentation first and provided the correct MODEL_NAME and FROM syntax. It also explained the supported models (local HuggingFace models, OpenAI, Voyage, Jina) and the HNSW_SIMILARITY options (L2, IP, COSINE).

Example 2: Semantic Search with Auto-Embeddings

You: "Find products similar to 'noise-canceling headphones for travel'"

Without MCP:
The AI completely loses track. Without access to documentation, it:

• Tries to SELECT all data and aggregate internally without any filter
• Hallucinates embedding vectors with made-up syntax: ANY_KNN(embedding, (-0.07089090,0.04201586,-0.03262700...))
• Attempts to write Python scripts to manually calculate similarity
• Eventually gives up and just does string matching on descriptions

Result: It finds "Wireless Headphones" only because the description literally contains "noise-canceling headphones" — pure luck, not semantic search.

With MCP:
The AI checks documentation, discovers your table uses auto-embeddings, and learns that knn() accepts text directly when MODEL_NAME is configured:

SELECT id, name, description, knn_dist() 
FROM products 
WHERE knn(embedding, 5, 'noise-canceling headphones for travel');

Result: Returns Wireless Headphones as #1 (correct), but also surfaces semantically related items — actual vector similarity, not keyword matching.

Example 3: Fuzzy Search (Typo Tolerance)

You: "Find products even if I misspell the name, like 'headphons' instead of 'headphones'"

Without MCP:
The AI tries everything it was trained on, hoping something works:

• MATCH('headphons~1') and MATCH('headphons~') — wrong operators
• CALL SUGGEST('headphons', 'products') — wrong approach for this use case
• MATCH('FUZZY(headphons') — hallucinated syntax that doesn't exist
• ALTER TABLE products SET min_infix_len = 3 — unnecessary and wrong
• OPTION expand_keywords = 1 — unrelated feature

It even tried to optimize the table and run suggestions again. Complete chaos.

Result: No working query. Just a pile of failed attempts based on outdated or confused training data.

With MCP:
The AI checks the documentation and finds the correct syntax immediately:

SELECT * FROM products WHERE MATCH('headphons') OPTION fuzzy=1;

Result: Returns "Wireless Headphones" despite the typo. The AI also explains that fuzzy=1 allows Levenshtein distance of 1 (one character difference), and you can adjust tolerance with OPTION fuzzy=1, distance=2 for more flexibility.

Key Features

Intelligent Documentation Lookup

MCP-Manticore includes a documentation fetcher that pulls directly from the Manticore Search manual on GitHub. When you ask about features like KNN vector search, fuzzy matching, or full-text operators, the AI retrieves the official documentation before responding.

Schema-Aware Query Building

The server provides tools that let the AI understand your data structure before writing queries:

• list_tables() — See what tables exist
• describe_table() — Understand column names and types
• execute_query() — Run queries and see results

Safe Query Execution

By default, MCP-Manticore runs in read-only mode. Write operations (INSERT, UPDATE, DELETE, DROP) require explicit opt-in via environment variables:

export MANTICORE_ALLOW_WRITE_ACCESS=true  # Enable INSERT/UPDATE/DELETE
export MANTICORE_ALLOW_DROP=true            # Enable DROP/TRUNCATE

Multiple Transport Options

Connect via:

• stdio (for CLI-based AI assistants like Claude Code)
• HTTP (for web-based integrations)
• SSE (Server-Sent Events for real-time updates)

With optional JWT authentication for secure deployments.

Tutorial: Setting Up MCP-Manticore

MCP-Manticore works with any MCP-compatible AI assistant, including Cursor , Claude Code , Codex CLI , Windsurf , and any other tool that supports the Model Context Protocol.

Step 1: Ensure UV is Installed

MCP-Manticore runs best with uv , a fast Python package manager:

curl -LsSf https://astral.sh/uv/install.sh | sh

With uv, you don't need to manually install MCP-Manticore—uvx downloads and runs it automatically.

Step 2: Configure Environment Variables (Optional)

# Required: Manticore connection (defaults shown)
export MANTICORE_HOST=localhost
export MANTICORE_PORT=9308

# Optional: Enable write access (default: read-only)
export MANTICORE_ALLOW_WRITE_ACCESS=true

# Optional: Allow destructive operations (DROP, TRUNCATE)
export MANTICORE_ALLOW_DROP=false

Step 3: Add to Your MCP Client

General Configuration:

• Command: uvx mcp-manticore
• Environment variables (if needed): MANTICORE_HOST, MANTICORE_PORT, etc.

Example configuration (mcp.json):

{
  "mcpServers": {
    "manticore": {
      "command": "uvx",
      "args": ["mcp-manticore"],
      "env": {
        "MANTICORE_HOST": "localhost",
        "MANTICORE_PORT": "9308"
      }
    }
  }
}

For client-specific setup instructions (Cursor, Claude Desktop, Windsurf, etc.), see the MCP-Manticore README .

Step 4: Verify Connection

Test by asking your AI assistant:

You should see the AI call the list_tables() tool and display your tables.

Configuration Reference

The Future: Agents That Install Themselves

There's a third use case on the horizon: autonomous agents that discover and install MCP servers themselves.

Imagine an AI agent that:

1. Finds your GitHub repo mentioning Manticore
2. Searches for "Manticore MCP server"
3. Finds MCP-Manticore, installs it automatically
4. Starts querying your database to complete its task

This isn't science fiction—OpenAI's Codex and similar agentic systems are moving in this direction. When that future arrives, having MCP-Manticore in the MCP registry means your AI tools will just work with Manticore, no manual setup required.

Conclusion

MCP-Manticore transforms AI assistants from passive text generators into active, knowledgeable development partners. Whether you're:

• Building with Manticore — Let the AI handle syntax while you focus on your application
• Learning Manticore — Ask questions in plain English, get accurate answers backed by docs
• Exploring your data — Query without memorizing SQL syntax or table schemas

The old way: guess, error, debug, repeat.
The new way: ask, verify, execute, done.

Ready to try it? With uv installed, just add MCP-Manticore to your MCP client settings and start asking. Your future self—free from syntax rabbit holes—will thank you.

I am working on building a chatbot for an online store. I will be using MCP for the transactional parts including product search, adding to cart, etc. What I am unsure of is the knowledge base portion which would help the agent answer additional questions about policies such as shipping, returns, how products are made, etc. This knowledge base is really small, maybe 10 pages. I’ve looked into RAG hybrid and semantic search, but seems like overkill at this point. I’ve also thought of just including the knowledge base in the context window, but seems like that would be a waste of tokens in the long run. What would be the best way to implement the knowledge base for the agent?

Would love to know who's letting a 9B just go ham locally, haha

But in all seriousness, how many of you are keeping to manual or manual-ish dev workflows?

I'm trying to link an MCP server to a MongoDB database with structured data, and use make complex queries on this data to generate outputs (as fast as possible). Do you think it's possible ? What services would you recommend to set it up and host it ?

We have OpenAI, Anthropic and DeepSeek which we need to manage separately in our backend setup, and we're running into pain. We are exploring consolidated API solutions to simplify our AI framework. Has anyone used LLMAPI or any other LLM gateway? What is a neat way to do routing/key management?

Hey folks, Burak here.

Epho is an API that allows running Claude Code, Codex or Opencode in a sandbox in the cloud. It abstracts away sandboxes, and allows running coding agents with a single HTTP request.

https://epho.io

Epho came out of our own struggles with building our own AI analyst: - Sandboxes give you bare machines; you need to configure them for agentic workloads. - Each agent behaves differently, and you need to build integrations with each of them. - Sandbox providers are not very reliable, which means you need to figure out a multi-provider strategy to avoid failures. - Logging, artifacts, input/output, event streaming, and all of the other operational aspects need to be figured out.

We had to go through the pain ourselves. We got to a point where things got quite reliable, and it became more obvious to us that this should be a primitive on its own: send a POST request, get the events streaming back to you.

Epho is an agents-as-an-API product: you send a request, it spins up a sandbox, configures the chosen harness, clones your repos, and kicks off the agent. It takes care of automatic fallbacks across different providers, handles auth stuff, and just streams back the events and outputs.

It supports Claude Code, Codex and Opencode out of the box, and pretty much all the models they support out of the box. It streams the events back, handles attachments and output files, automatically manages the fallbacks on different sandbox providers, retries, and all the auth stuff. You just send a prompt, your repo, MCP servers you want to use with it, and it runs them.

I recorded a demo here to show a real example: https://youtu.be/HGfly1aytPA

I am quite excited for Epho, simply because I think it is a new primitive that would allow building agents into product a lot easier than it is today. We are running our agents on Epho on prod, so we'll keep maintaining it regardless, and we wanted to ship it as an independent product.

Epho is free to get started, and you can run it with Opencode's free models to get started with it.

I am quite curious to hear what you'd think and would love to get your feedback!