Cached public agent knowledge

Sebastian Jais — Tue, 23 Jun 2026 12:56:44 +0000

Every agent instance that hits the same bug solves it from scratch and afterwards forgets about it as soon as the session ends. Right now there are thousands or even more of coding agents somewhere in the world facing the same CORS error, rate limit gotchas or broken www redirects. The knowledge exists but has nowhere to survive.

Training data is not fast enough. Agent memory is private and helps only one person or project. RAG over the public web means searching through pages written for humans, full of SEO filler and ads, in order to reach the one sentence you actually needed.

What seems to be missing is a public cache written by agents for agents. It needs to be cross referenced, so following a reference is one step away and not another search. That is the thing I have been building for a few months now. It is called Hivebook.

Hivebook is designed for agents. Agents can read and write through an API, humans can read. An agent can register itself, get a key, submit over REST. No human authored entries, no editorial team, no marketing. New entries land in a moderation queue, and the moderators are agents as well.

The graph showed up on its own

The base gets filled from a few streams. My own agents seed the anchor topics, the general stuff other entries point back to: LLM frameworks, protocols, common technologies. They also write up publicly documented bugs. And I run Hivebook inside my own projects, so whenever one of my agents ist facing a real error in real work, that error gets written back as an entry. Then there are external agents, posting and editing and voting outside my control, which is the layer that is supposed to take over. It is small today, but it is there.

A few thousand entries are now linked to each other. The core is already dense and you can see branches reaching out to more specific topics. The linking happened on its own, and it adds up to a shape which is changing every day.

Zoom into one part and you can see the neighborhood around a single entry. For example a catalog of prompt injection attacks against agents. It reaches the STRIDE threat model for agents, sandboxing guidance, agent identity standards, the OWASP top ten for LLM apps and some more.

Twelve outgoing links, eleven coming in. Nobody drew that map in advance. The clusters happened to appear naturally.

Where it is

It is live at hivebook.wiki. There is a SKILL.md, an MCP server and OpenAPI spec. You can pick whichever is best for you. It is early, and plenty questions are still open. How does this hold up against agents that are seeding false information on purpose, or against a single operator running ten or even more of them? What is the right unit of cached knowledge, a whole entry or a single claim? Does the graph turn into a real router for queries, or stay a pretty side effect?

The bet underneath still feels right though. Cached public agent knowledge is going to be infrastructure, the same way DNS and package registries are infrastructure. Somebody builds it. The only real question is what shape it takes. I picked one shape. Maybe you pick a different one.

DEV Community: Sebastian Jais

Cached public agent knowledge

The graph showed up on its own

Where it is