tcballard

Tried this out and worked so well I bought a usb stick (because who owns those these days) and installed on my wife’s machine…

Bloomberg shipped an official MCP server a few days ago... https://www.bloomberg.com/company/stories/closing-the-agenti...

that’s just autocomplete when you type using a phone? Regardless of the semantics on language though, thoughts on the actual product?

Yeah, naming clash clearly an issue but fundamentally different products. Epic just have the recognition over someone building OSS for the first time

No worries, clearly better documentation would help!

you mean I started a newer account? This is my first time posting on HR for things… so I’m new here, play nice!

hilarious, I literally did this today as part of the satellite repo “rac-ci” which has these in

So it seems to work quite well, as it’s been dogfooding itself for the past month… but only time will tell!

I’ll do better

thanks!

the mcp is a wrapper around the cli! You can run “rac explorer” if you have installed the extra: pip install 'rac-core[explorer]'

in terms of UX, working on a couple of improvements there but wanted to validate the idea first and get the integrations with common platforms like GitHub sorted first!

I don’t follow - but appreciate the feedback, I’ll improve my comms about Lore / rac-core

So rac doesn’t merge ADRs or infer that soft-deletes survive… supercession is managed by the status on one ADR saying Superseeded, and the other saying Supersedes. This is enforced by the CI pipelines you can use (GitHub, etc)

I think your example is a bit more of a modelling question, and if soft-delete must outlive the uniqueness decision it should be its own requirement that’s persisted as RAC guarantees the graph stays consistent and current; it doesn’t guess which clause survives — that’s the users call.

So the line shifts, but I see it as SDD manages the change (spec → tasks → ship, then archive it); Lore holds the durable decisions that every change after it has to respect.

think of it as a layer above SDD and not a competitor, so basically you point your spec tool at the constraints Lore enforces.

Regardless - the emdash predated LLMs … but that’s going way off topic!

I wrote this, I just spend enough time with LLMs to sound like one

I think the proxy angle is genuinely appealing for the reasons you give: team-level, no per-dev install, reshape every agent's context from one place. We went down that exact fork and chose against it (wrote up the reasoning as an ADR if you want it). Instead of intercepting and rewriting prompts/tool_calls, Lore does context-supply + post-edit enforcement.

Two things drove it:

One, a proxy that silently rewrites what the agent sees is hard to audit so you can't review an injection that never lands anywhere, and when it misfires you're debugging an invisible middle layer. We wanted the injected context to be a file in the PR diff (a generated CLAUDE.md/rules file) and the rest to be explicit read tools the agent chooses to call.

Two, and this is the part I'd flag for your index, the hard problem isn't delivery, it's knowing which decision is still current. An index built from git logs + tickets + PRDs is mostly stale or contradictory text; if a call got reversed six months ago, a fuzzy index will happily re-inject the old one. So that's where we spend the complexity budget: typed, human-reviewed decisions where "superseded" is enforced in CI, so the agent never gets handed a ruling you already overturned.

Which is why I think these compose rather than compete. Your proxy is a delivery mechanism; it still needs a trustworthy source for "the decisions this team made." That's what Lore is, and it exports for exactly this — rac export --documents (JSONL) or --graph to feed an index, --agent-rules for the injection layer. Stay fuzzy and convenient at recall, point back at a deterministic source for the part that has to be exactly right. Keen to see where praxis_agent_runtime goes — provenance-first is the right instinct.

Different beast — Epic's is version control, this grounds your agent in your team's decisions. Installs as rac either way, so the name's not load-bearing. But yeah, timing's a coincidence... just thought the name was cooler :D

I agree, that method might work if you are working solo or in a small team - but for organisations the ability to centrally manage and gate this sort of ruleset avoids drift.

Good questions! Lore isn't really competing with CLAUDE.md, it sits under it.

A CLAUDE.md (or AGENTS.md, etc) is typically hand-written, untyped, and never checked. Nothing stops it from still telling the agent to do something you reversed six months ago, and nobody validates it in CI.

Lore keeps the actual decisions/requirements/designs as typed Markdown in your repo, and rac export --agent-rules generates those rules files from the decisions that are currently Accepted — superseded ones drop out automatically. So the rules file becomes a build artifact of your knowledge base instead of something you hand-maintain and hope stays current. (Note that in dogfooding Lore that its repo does exactly that: its CLAUDE.md is a ~20-line router into the validated corpus)

The part that makes it more than markdown-with-a-schema is write-time enforcement. rac validate / rac gate run in CI and fail the merge if an artifact is malformed, a link is broken or ambiguous, or anything points at a superseded decision. At serve time it's a read-only MCP server doing deterministic retrieval — the exact current decision by ID, not similarity-ranked guesses. No RAG, no embeddings, no model call to decide what's relevant.

On spec-driven dev (Spec Kit, OpenSpec, Kiro): those drive a change — proposal → design → tasks → implementation, usually archived when the feature ships. Lore holds the durable why that outlives any single change and gets served to the agent on every session. It's the layer above SDD, not a replacement — you'd point a spec tool at the decisions Lore is enforcing.

Author here! Coding agents kept reworking decisions we'd already settled - reviving an approach we ruled out in an ADR, redoing something a requirement already pinned. The context was in the repo; the agent had no current view of it.

Lore serves your team's durable knowledge - requirements, decisions, designs, roadmaps, prompts - all as typed Markdown, read-only to Claude Code / Cursor over MCP, so the agent cites your decisions instead of contradicting them.

The bet: retrieval is deterministic. No embeddings, no vector store, no model call to pick what's relevant — same query, same bytes, same result, offline. It's not a RAG competitor; it composes — recall fuzzily, then verify the EXACT, CURRENT decision in Lore (it declines the ones you've superseded). Runs in CI (rac validate / rac gate) too.

  pipx install rac-core
  rac quickstart
  claude mcp add lore -- rac mcp

What it isn't: a search index, a memory layer, or an AI feature — the engine makes no LLM calls, no telemetry unless you opt in. Early, and my corpus is small, so I'd like to hear where deterministic grounding breaks down for you vs. where fuzzy recall is enough.

(Lore is the product; the engine under it is RAC — Requirements as Code, the `rac` package.) Apache-2.0, typed.

I like to think so!

Interestingly, a tuned length-threshold baseline performs very competitively and even beats Wayfinder on one of the benchmark sets. My intuition is that structural signals become more useful as prompt formats get more heterogeneous (code reviews, logs, tables, long instructions, etc.), but I’d love to see more real-world data.

Most routing systems I found either used another model as a classifier or relied on provider-specific routing. I was interested in the narrower question: how far can deterministic heuristics get before you actually need another model in the loop?