Beacon

Stop re-solving solved problems. Ask a pool of agents, the ones who've solved it raise a hand, and each shares only what it's allowed, with verified provenance.

Comment

Inspiration

Jacob and I have been building together for about a year now. Tolus, hackathons, side projects, a lot of late nights. Somewhere in there we noticed something a little embarrassing: we kept solving the same problems twice. One of us would spend an afternoon fighting a bug or working out an approach, and weeks later the other would hit the exact same wall and start from scratch, with no idea the answer already existed twenty feet away.

We figured it was just us being disorganized. Then we talked to our dads, who both work in big tech, and they laughed, because they live the same thing at a scale we couldn't imagine. Whole teams re-solving problems the team down the hall already cracked. Not because the knowledge doesn't exist, but because there's no safe way to ask across the wall. The other team's work sits behind different tools, different permissions, and the very reasonable fear of leaking something they shouldn't. So everyone just redoes the work.

That's the insight Beacon is built on. The bottleneck isn't that solutions don't exist. It's that there's no safe way to ask a question across a boundary and get back exactly what the owner is willing to share.

What it does

Beacon is a permissioned knowledge-brokering network. You ask a question once, and it fans out to a pool of independent parties. Each one searches only its own knowledge and decides, at its own boundary, what may cross, the full answer, a redacted "this exists but it's locked" stub, or nothing. Every answer that crosses is verified against its own source, and you get back one cited answer. When something comes back locked, you can request access, and granting it re-streams just that one answer live.

The differentiator isn't the search. It's the gate, permissioning, no-leak, and verified provenance, enforced inside each party before anything leaves it.

How we built it

Three layers, with frozen interfaces between them so we could swap implementations without breaking anything upstream.

Retrieval. Each party owns an isolated index of only its own chunks. Search is hybrid, lexical BM25 plus static CPU embeddings, fused with Reciprocal Rank Fusion:

$$\text{score}(d) = \sum_{r}\frac{1}{k + \text{rank}_r(d)}$$

It runs over ~4,300 real documents in roughly 15 ms with no GPU.

The gate (the wedge). Two independent checks, visibility and capability, decide whether content crosses. The key idea is that no-leak is structural: the object that crosses the boundary has no field that can hold raw restricted text, so a leak isn't filtered out, it's impossible to express. Redaction and verification run as Claude calls inside each party, and verification fails closed, so an unverifiable answer is never shown as verified.

The spine. Fan-out, token-streamed synthesis, and a grant-access "hero beat" that re-streams only the one card that just unlocked.

MCP Beacon exposes itself as an MCP server, so you can query the whole permissioned network straight from Claude Desktop or Claude Code, and the gate travels with it.

Challenges

Our real data didn't overlap. We seeded the corpora from our own exported accounts, and it turned out no question answered coherently across all three, our histories just don't intersect. So for the demo we planted one coherent cross-party scenario and were upfront about it. Everything else runs on real data. A production version would need genuinely overlapping party corpora.

The UI had never touched the backend. The visual shell was all mock timers. We built the live data layer from scratch, a barebones working client first so we always had a fallback, then dressed it.

Latency. Permissioning and verification are real model calls, so a naive version sat on a dead spinner. We streamed the answer token by token, and made grant-access a targeted replay that only re-runs the one party that changed.

Knowing what not to build. The tempting move was to route everything through MCP and make access-granting a cross-service call. It's the more faithful architecture, but it would have put our most important moment on the network and stripped away every fallback. We kept the grant local and bulletproof on purpose. The hardest decisions were the ones about restraint.

What we learned

The hard part of this problem was never retrieval, it was the gate. Making sharing safe is what unlocks everything else. We learned to build security by shape rather than by discipline, because making a leak impossible to express beats remembering to filter it out every time. We learned that frozen interfaces are a superpower under a deadline. And we learned that scope discipline wins, every hour we didn't spend gold-plating went into making the core unbreakable.

What's next

Real overlapping corpora instead of a planted scenario. Parties all federated over MCP, each holding its own knowledge live and running its own gate. Out-of-band access grants, an approval rather than a synchronous call, and per-party, per-asker policies so each owner sets exactly how its boundary behaves.

Built With

Share this project:

Updates

Submission history