Lore

Lore is a brain for any company: an AI agent that answers from your own knowledge with sources, remembers you, maps how your company connects with HydraDB, and proposes next steps you approve.

Comment

Inspiration

Every company already has a brain. It is spread across policies, handbooks, tickets, team chat, meeting notes, spreadsheets and code, and nobody can ask it a question.

AI memory can fix that, but company pilots usually stall on the same three problems: answers nobody can check, outdated versions presented as current, and assistants that show people things they should not see. We wanted a company brain that remembers and connects like a colleague, and that a company can trust like a system of record.

What it does

Lore is a brain for any company: one agent over its knowledge, for employees and for other AI tools. The demo company is Northwind Robotics, a fictional maker of warehouse robots and fleet software.

  • Answers with receipts. Every claim links to the exact passage: a policy section, a ticket, a chat message, a table row or a meeting timestamp. Citations are checked before they are shown.
  • Knows which source is current. The approved, effective version wins. Superseded versions and contradicting chat are labelled, not silently mixed in.
  • Connects the dots. Relationship questions ("which product does this ticket concern, and which article explains the fix?") come back with relationship evidence from HydraDB. A Graph view lets you explore people, teams, products, policies and customers, and how they connect.
  • Remembers you. Tell the brain something about yourself ("I'm the support lead for Tidewater Fulfillment") and later answers take it into account. Each person's memory is their own and is never cited as company fact.
  • Says when it does not know. If the evidence is not there, it says so and names who owns the answer.
  • Protects sensitive data. Payment card numbers (Luhn-checked; only the last four digits are kept), card security codes, US social security numbers, IBANs and credentials are redacted before anything is stored, indexed, sent to HydraDB or shown to a model. The same check runs on the questions people type and the memories they save.
  • Keeps private conversations private. Private channels and direct messages carry their membership as their access list. Non-members cannot read, search or be shown hints of them, on every search lane and in HydraDB results.
  • Charts on demand. Ask "open tickets by severity" and the brain writes a read-only SQL query, answers with a chart and cites the query. A chart can be pinned to Dashboards.
  • Proposes next steps. After an answer, the brain can propose a draft reply, an escalation, a conflict flag or a dashboard pin. Nothing happens until a person approves it; approved items go to the Outbox, and delivery stays manual.
  • Takes new knowledge. In Add knowledge, you can upload your own files into a separate sandbox and ask about them right away.
  • Connect. An MCP server lets Claude, ChatGPT, Cursor or your own code search and ask the brain, with the same permissions as the person it is launched for.
  • Shows its score. A Scorecard reports correctness, abstention, leaks, speed and cost on the company's own questions, with sample sizes.

Judges can try the live demo from the Try it out link (access shared privately).

How we built it

HydraDB is the brain's memory and graph layer. We followed the shape of HydraDB's own company-brain tutorial, using the hydradb-sdk Python SDK:

  • One database per company. Live: Northwind with 232 items (126 documents and 106 app items) and 551 relations, plus 8 seeded personal memories. A second sample company, Meridian Precision Manufacturing, has 81 items and 229 relations.
  • Knowledge collections scoped by access. Documents are grouped into one collection per distinct access set, so a query only names the collections the asking person may see.
  • App sources keep their structure. Chat messages and support tickets are sent as app items (thread, author, status, severity, product), not flattened into text.
  • Bring-your-own graph. Instead of asking a model to guess relationships, we send HydraDB the ones the company already maintains: which policy version supersedes which, which ticket concerns which product and which article, who owns what.
  • Memory next to knowledge. Each person has a memory collection, queried together with their knowledge collections in one hybrid request.
  • Graph step for relationship questions. Plain questions use one fast query. Relationship questions also run a graph lookup on the top documents plus one hop, within a 3-second budget, and the documents behind the strongest relations join the evidence so they can be cited.

A gateway decides who sees what. The person's identity is set on the server, never by the browser or the MCP client. Every chunk HydraDB returns must map back to a passage that person may see right now, and every graph path must map back to visible documents; anything else is dropped. A revoked document disappears from the next answer, even before HydraDB has caught up.

The answering engine routes each question to a fast cited answer, a bounded multi-step lookup, a read-only SQL query, or an abstention. Answers are written by GLM-5.3 Flash; a separate decision model, GPT-6 Luna, plans SQL queries, multi-step lookups and next-step actions in strict JSON schemas. Both run through OpenRouter with zero-data-retention routing.

We chose those models with a bake-off, not by reputation: several model combinations, each run on Northwind's full 60-question set, most of them repeated. GLM alone matched the best correctness but abstained less reliably; GPT-6 Luna alone answered 80% correctly; our earlier Claude Haiku 5.5 setup matched the chosen pair's correctness at about three times the cost.

Surfaces: a FastAPI web app (Ask, Sources, Add knowledge, Knowledge, Dashboards, Graph, Scorecard, Connect, Outbox), a REST/SSE API, an MCP server and a CLI. The hosted instance runs on AWS.

Prepared before the event vs built on the day

  • Prepared before the event (Oct 11 into early Oct 12 PDT, pinned at company-brain@7a087be, 03:10 PDT): the platform behind Lore (v0.1). That covers ingestion, permission-aware hybrid retrieval, compiled knowledge (versions, conflicts, glossary), cited answering, the web app, API, MCP server and evaluation kit, plus the two fictional sample companies. It also included an earlier HydraDB adapter written without a live account and never run against HydraDB.
  • Built on event day (from about 12:00 PDT, after the organizers' 10:30 email; timestamped commits): the HydraDB memory and graph layer and its gateway checks (12:34), human-approved next-step actions and the outbox (13:01), the hosted AWS instance with an English-only review gate for demo content (14:00–14:30), charts and dashboards on demand (14:41), the decision-model routing (15:06), the upload sandbox (15:07), live graph paths, the Graph view and the HydraDB status panel (15:30), the model bake-off and the first-token hedge (15:56), semantic search on the hosted runtime and charts on the decision path (16:10), the simplified company-facing interface, redaction of card numbers and other sensitive identifiers (16:20), and this write-up.

All data is synthetic. No client, employer or personal data was used.

Challenges we ran into

  • Memory without oversharing. HydraDB's own access control is opt-in and memories carry none, so we could not rely on it alone. Our gateway is the only authority, and HydraDB's results are filtered after every query.
  • Graphs cross boundaries. A restricted document and a public one can meet at the same graph node. We keep a relationship path only if every document behind it is visible to the person asking, and we never show HydraDB's merged path text.
  • Fast queries return no graph paths. HydraDB's fast mode skips the graph, and its deeper mode is slower. We run a separate graph step only for relationship questions, in parallel with retrieval, under a 3-second deadline.
  • Matching graph names back to documents. HydraDB normalises entity names (it drops characters such as & and ;), so we match on letters and digits and attribute each relation through its source chunk.
  • Asynchronous indexing. Provisioning and graph indexing take minutes, so we pushed early and poll status per item; the status panel shows progress.
  • Latency spikes from model providers. The same model behind different providers varied widely: across repeated runs, the slowest 5% of first responses ranged from about 2.5 s to over 10 s, while the median stayed near 0.6–0.8 s. Provider sorting did not help, so we added a first-token hedge: if no answer text arrives within 1.5 s, a second request races the first and the first to stream wins. In our runs it fired on about 7% of answers and brought the slow tail to about 2.1–2.9 s for about $0.03 per 1,000 questions.
  • Sensitive data and private conversations. Judges asked how card numbers and private Slack messages are handled. Redaction happens once, at ingestion and on every typed question, so a card number never reaches the index, HydraDB, a model or a log. Private conversations are enforced by access lists on every lane rather than by hiding them in the interface.

Accomplishments that we're proud of

  • HydraDB live, end to end. Two companies indexed with their own relationship graphs (Northwind 232 items and 551 relations; Meridian 81 items and 229 relations), per-person memory, and graph evidence shown only when it is safe to show.
  • Measured, with sample sizes. On Northwind's 60-question set (45 answerable, 15 that should be declined), the release that is live now answered 60 of 60 correctly by strict match in its latest run (59 to 60 across five runs); an independent model grader marked 59 correct and 1 partial. Permission leaks: 0 in every run. Answer-model cost: about $0.60 per 1,000 questions. During model selection, the chosen GLM-5.3 Flash + GPT-6 Luna setup scored 93.3 to 95.6% across nine runs, with the first words at about 0.6 s at the median.
  • One platform, any company. Northwind (a 140-person robotics company) and Meridian (a manufacturer) run from a company profile on the same code.
  • Agentic, with a person in charge. The brain plans its own lookups and SQL, proposes next steps, and never acts without approval.

These scores are directional. The question set was written together with the synthetic corpus, n = 60 gives roughly ±10 points of uncertainty, runs used 4 concurrent workers, and the scored runs used the exact-ID and keyword lanes on a copy of the hosted runtime, not the HydraDB lane.

What we learned

  • Remembering is the easy part of a company brain. Deciding who may see each memory, document and relationship is the hard part, and it has to live outside the store.
  • For facts a company already keeps (which version replaces which, which ticket concerns which product), supplying the graph beats extracting it.
  • Separating personal memory from company knowledge lets the same brain feel personal without changing what counts as company fact.
  • Measure before choosing models. The cheaper pair matched our earlier setup's correctness at about a third of the cost.
  • A single score hides a lot. Our second sample company, Meridian, scores 58.7% on its own 60 questions, with 0 leaks and both planted prompt-injection records resisted. The English-only demo gate excludes the documents behind 31 of its 46 answerable questions; on the 15 whose evidence is present it answers 13 to 14 correctly. We added an evidence-coverage metric to the evaluation kit so this shows up next to correctness.

What's next

  • Score the HydraDB lane on the same question sets, and add an LLM-judge column next to the strict text match.
  • Grow Northwind toward an enterprise-sized corpus (about 650 documents) generated from one consistent world model of people, accounts and timelines.
  • Live connectors with synchronised permissions (Slack, Google Workspace, Microsoft 365 membership changes), broader sensitive-data classifiers for other personal data, and a deletion record that follows every derived copy, including HydraDB.
  • Memory controls: expiry, "what do you remember about me", and one-click forget.
  • Design partners: bring one department's documents and 50 real questions, and get your own scorecard.

Built With

Share this project:

Updates

Submission history