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.

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

I believe Pages uses Actions under the hood for publishing, so in my head it sort of makes sense for these things to be affected in the same outage

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

they did.

> Customers using self-hosted runners may see errors or rate limiting when runners register.

Well hopefully reads aren't affected then...

Already built pages are still being served, but I've been waiting for 3 hours for an action to rebuild a single fix to a broken link.

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

From quick glance I don’t think so that’s the case. copliotkit promises ag-ui compatiblity., which means it can work with codex cli, mastra, pi, claude agents sdk and other harnesses as well (there are ag ui adapters as well). I’m actually integrating this with claude agent sdk with ag ui adapter., which i don’t think is possible with vercel chat sdk.

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.

Hey, I'm Nathan, DevRel at CopilotKit. That is a really interesting point you are making, and we've heard it a lot. One of the reasons this is so powerful is that it uses AG-UI as the transport, which enables a lot of flexibility depending on your use case. I would love to get your feedback if you decide to give it a spin.

Not proprietary and not a wrapper. Chat SDK served as inspiration, of course, but I think it misses a few hard parts of bringing agents to chat interfaces:

- Generative UI in these surfaces needs to be durable. If your agent composes a Block Kit or Adaptive Cards interface with interactivity, you have to be ready to handle that interactivity weeks later. We handle this with our JSX renderer.

- Chat interfaces are inherently multiplayer. The worst thing you can do is have your agent act like a bot: posting all of the time, creating noise, and offering no customization. I think Claude Tag nailed the user experience here, and now we want to empower developers to create agents with a similar UX via open source.

- Truly agent-and-surface agnostic. We're fully powered by AG-UI (ag-ui.com), so you can bring any agent into Slack and then take that same agent to web or mobile all over the same protocol.

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.

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?