opwizardx

I did similar tests on my own corpus when was considering whether to keep semantic search in default path for pond.

On 3 months of my own sessions I’ve seen that BM25 search was finding the correct answer in ~61%, where semantic had shown only ~37% of success.

After that it was easy for me to make the decision.

Got all info on how I did evals in here, if interested: https://github.com/tenequm/pond/tree/main/docs/researches/26...

Why do you need an MCP server at all when the spec itself is so simple?

plain text + fts covers all the basic needs, adding vector search, in my experience, adds more hassle and failures then helps

I had been building https://github.com/tenequm/pond for this exact purpose for a while, and it works like a charm in my case.

Give it a try, hope it will help you to solve your need without injecting anything in your context all the time.

That is exactly what I'm building pond for myself: one store for all my sessions, Codex and Claude Code both and a bunch of others including OpenClaw, and my agents can access it over MCP. It also happens really often that when my agents cannot find something, they just call pond search themselves. Faster that way. Whenever I need a session from a while ago now, I just know it's in pond. Repo, if you'd be willing to give it a try: github.com/tenequm/pond

Same worry got me to build pond for myself: it imports all of my sessions on a cron schedule every 5 mins into one store, and my agents can access it over MCP. Whenever I need a session from a while ago now, I just know it's in pond, because all of my sessions for about the last 1.5 years are collected in there. It also happens really often that when my agents cannot find something, they just call pond search themselves. Faster that way.

Codex, Pi, Hermes, Openclaw and bunch of others a getting pulled in automatically too. Repo: https://github.com/tenequm/pond

Like we used to have all of that time before with docker-compose.yaml.

It would have been so neat to have agents.yaml in your repo and know it will be sourced by a harness you use.

You are right, didn’t know that.

Seems like the only reliable way to run GHA jobs is to not use their runners. Hope they at least didn’t break self-hosted runners operations

I first found out about chat-sdk existence when I was upgrading my nanoclaw (its core feature is that it uses claude agent sdk under the hood as the harness) to v2 and they were migrating to chat-sdk as their base layer for supporting different channels.

It was pretty limited thought in terms of what I needed, so I had to through it away and build my own telegraf sdk based channel implementation for telegram, but that was a while ago, I assume they should have evolved a lot from the time I last touched it about 3 months ago.

Fair on AG-UI, that part is a real difference. But the Chat SDK point is a bit overstated: vercel/chat also has a JSX card system that renders to Block Kit and Adaptive Cards, with button and action handlers and pluggable state backends.

> Chat interfaces are inherently multiplayer.

Both chat and channel sdks support subscribing to threads and can control messages that arrive concurrently. In that regard it feels like this depends more on the logic of the app itself rather than gets defined by the framework/dependency it uses.

How did they get Github Pages into “degraded performance”? Aren’t those just CDN stored static pages?

Is it like a proprietary wrapper for Vercel’s Chat SDK (https://github.com/vercel/chat)?

So… those are basically skills with mcp.json?

Are we sure we need a competing spec when we could have just extended agent skills spec to allow for mcp.json definition within skill?

I archive my own agent sessions, and even before provider-sealed state the local half of the promise is already broken: Claude Code deletes local transcripts after ~30 days by default, and the JSONL it does keep has edge cases like the same message id appearing twice with different usage tuples. "The local event log is canonical" is the right rule, but today you have to actively rescue that log from your own client before you ever get to fight the API.

The encrypted thinking signature blocks are the part I still have no good answer for: you can store them losslessly, but on restore into a different client they are just dead weight.

It at least tries to attack the convergence directly by keeping a log of past builds in .hallmark/log.json and hard-fails a run that repeats the last few page structures or themes. While it still admits its nav-rotation rule is "the single most-violated rule in practice"...