Skip to main content
This guide walks you through building a company-wide internal search engine powered by HydraDB. Unlike per-tool search (Slack search for messages, Confluence search for docs), this agent queries everything simultaneously - Slack threads, email, wikis, code issues, and project management - and synthesizes a single cited answer from across all sources.
Note: All code in this guide is production-ready and uses real HydraDB endpoints. Base URL: https://api.hydradb.com. Get your API key at app.hydradb.com.
Goal: Ingest six source types into one HydraDB database, store per-user memory profiles for personalized answers, and answer three query patterns - simple factual lookup, decision provenance, and cross-source synthesis - all through POST /query.

Prerequisites

Required knowledge: Python basics, REST APIs, environment variables
Required tools:
  • HydraDB API key
  • Python 3.11 or 3.12 (python --version)
  • pip install hydradb-sdk

What You’ll Build

By the end of this cookbook, you’ll be able to:
  • Ingest Slack threads, Gmail, Confluence pages, GitHub issues, and Linear tickets into a single HydraDB database
  • Answer cross-source questions like “Why did we move to a monorepo?” that span multiple tools and time periods
  • Use recency_bias and graph_context: true to surface the most relevant, connected context across all sources
  • Store per-user memory so answers are personalized to each employee’s role and project context

Every company has knowledge scattered across a dozen tools. The answer to “why did we move from microservices to a monorepo?” is split between a Confluence RFC, a Slack thread in #architecture, a GitHub PR discussion, and an email thread between two VPs. No single tool contains the full answer. Keyword search returns one fragment. The person who knows is usually in a meeting. This cookbook builds a company-wide search engine that works like Perplexity - but over your internal knowledge. Ask any question, get a cited answer that synthesizes across Slack, email, docs, code, and project management. The answer includes provenance: where each piece came from and when it was recorded. The critical capability that makes this possible is HydraDB’s context graph. It automatically links entities across tools - “Project X” in a Slack message is connected to “Project X” in a Confluence page, the GitHub repo named project-x, and the Linear project tracking it. A query about Project X surfaces all of these together, ranked by relevance and recency, in a single call.

Architecture Overview

  • Ingestion Layer: Six connector scripts that format source content and upload to HydraDB via POST /context/ingest using multipart form-data.
  • HydraDB: Stores all sources, automatically builds a context graph linking entities across tools, and ranks results by relevance and recency at query time.
  • User Memory: Per-user profiles stored via POST /context/ingest and retrieved via POST /query to personalize answer depth and format.

Step 1 - Create Database

One database for all company knowledge. Use collection to isolate by source type - "slack", "email", "docs", "github". All created automatically on first write, no setup required.

Step 2 - Ingest Company Knowledge

All connectors use the same endpoint: POST /context/ingest. This endpoint uses multipart form-data - not JSON. database and collection are form fields alongside the file.
Important: Do not set Content-Type: application/json. Pass only Authorization in headers and let your HTTP client set the multipart boundary automatically.
Batch limit: Max 20 sources per request. Wait 1 second between batches. Always call GET /context/status before querying newly ingested content.
The upload response for all connectors looks like this:
Save results[0].id - you need it to verify indexing.

2.1 Slack Channels

Combine each thread (parent message + all replies) into one document. HydraDB’s context graph automatically links Slack threads that mention the same project or person to the Confluence pages and GitHub issues that discuss the same entities.

2.2 Gmail / Email Threads

Email threads contain decisions that never make it to Confluence. Filter to RFC, decision, and proposal threads - these carry the highest signal density.

2.3 Confluence & Notion

Confluence pages are the most structured knowledge context. Upload each page as a separate document so HydraDB can link entities in those pages to Slack threads and GitHub issues that reference the same topics.

2.4 GitHub Issues & PRs

GitHub issues contain the full discussion trail around engineering decisions - requirements, objections, alternative approaches, and the final resolution. Include all comments so HydraDB can build graph links between issue discussions and Slack threads that mention the same features.
Linear connector: Use the Linear GraphQL API (https://api.linear.app/graphql) with your API key. Format each issue + comments as a plain text file with Source: Linear prepended, and upload with collection: "linear". The same multipart upload pattern applies.

Step 3 - Verify Indexing

After uploading, poll GET /context/status until indexing_status is completed before running any queries. HydraDB indexes asynchronously - typically 10–30 seconds per file.
Note: GET /context/status takes ids and database as query parameters. Pass multiple ids to check a batch in one call.
Response when indexed:

Step 4 - Store User Memory Profiles

Each user gets a persistent memory profile. HydraDB uses it to personalize search results - an engineer gets more technical answers with PR citations, a product manager gets decision context and timelines, a new hire gets more background on why things are built the way they are.
Response:

Step 5 - Search Interface

Three query patterns cover every internal search use case. All use POST /query with different parameters. The routing logic is lightweight - keyword detection on the question, not ML classification.
Important: Use POST /query with a query field for all three query patterns below. It returns retrieved chunks and graph context; your app can pass that context to an LLM when it needs a synthesized answer.

5.1 Simple Factual Lookup - “What is X?” / “How does X work?”

Use balanced recency_bias: 0.5 for factual questions where both old and recent context matter equally. Restrict to a collection if the user is clearly asking about a specific tool.

5.2 Decision Provenance - “Why did we decide X?” / “What led to Y?”

For provenance questions, use graph_context: true and read graph_context.chunk_relations from the response - these are the multi-hop entity chains that trace a decision back through Slack, email, Confluence, and GitHub. Pass the chunks and relation chains to an LLM to synthesize a fully cited answer.

5.3 Cross-Source Synthesis - Complex multi-part questions

For questions that span multiple topics or time periods, use mode: "thinking" with a lower recency_bias to surface both old and recent context. HydraDB decomposes the question into sub-queries automatically and ranks results across all collections.

Step 6 - Search User Preferences

To personalize any answer, retrieve the user’s stored memory profile before calling the LLM. This is the same response structure as any /query call - an array of chunks.
Response:
Reading the response: /query returns the same structure regardless of type - read the profile from chunks[0].chunk_content. additional_metadata will be null for memory entries; that’s expected.

Step 7 - Interfaces

Web API (Flask)

Slack Bot


Step 8 - Incremental Sync

Run a nightly sync to keep all sources current. HydraDB’s upload is idempotent - re-uploading unchanged content with the same filename overwrites cleanly.

API Reference

All endpoints used in this cookbook. Base URL: https://api.hydradb.com · Header: Authorization: Bearer YOUR_API_KEY

Create Database

Upload Knowledge (form-data)

Do not use Content-Type: application/json. This is a multipart upload.

Verify Processing (query params)

Store User Memory

Search User Preferences

Full Search - All Sources

Full Search - Scoped to One Source Type


Benchmarks

Tested across a 2-year company knowledge base: 12 Slack channels, 3 Gmail accounts, 4 Confluence spaces, 6 GitHub repos. 400 questions rated by employees across engineering, product, and operations.
The 183% improvement on decision provenance reflects HydraDB’s context graph. Naive RAG treats a Slack thread, a Confluence page, and a GitHub issue as three isolated vectors. HydraDB understands they are three pieces of the same decision trail - entity-linked across sources - and surfaces all three together with the relationship chain that connects them.
Benchmark methodology: Figures are based on internal HydraDB testing. See research.hydradb.com/hydradb.pdf for the full methodology. Results will vary by corpus size, content quality, and query distribution.

File Structure

Requirements


Next Steps

  1. Run setup.py to create your database.
  2. Start with one source - ingest a single Slack channel or Confluence space and verify indexing.
  3. Store profiles for 2–3 users via memory/profiles.py.
  4. Run python search/qa.py with a real question to confirm results.
  5. Wire search/synthesis.py into interfaces/slack_search.py and deploy the Slack bot.
  6. Schedule sync/nightly.py via cron once the initial ingest is complete.
The search quality improves as more sources are indexed - each new Slack channel, Confluence space, or GitHub repo adds more nodes to the context graph that HydraDB builds automatically. There is no retraining step.

Change Log