Helix Foundry is a new open-source repo from the HelixDB team that tries to automate one of the most tedious jobs in enterprise AI: turning scattered company data into a structured graph an agent can reason over. You connect sources such as Postgres, Stripe or GitHub, an agent proposes an ontology (the types, links and rules that describe your business), you review it, and the result is loaded into HelixDB as a single graph. The GitHub repo is gaining stars quickly and sits on this week's trending list.
There is a catch worth knowing before you clone it: the README says the ontology-agent image is not yet public, and the stack will not start without it until the 0.1.0 release. This post explains what the tool does, how it works, how to try it, and where the gaps are.
TL;DR: the questions readers ask first #
| Question | Answer |
|---|---|
| What does it do? | Connects data sources, drafts an ontology with an agent, loads a graph into HelixDB, lets you explore and ask questions with citations |
| License? | Repo, site, backend and all three images (including ontology-agent) Apache 2.0; HelixDB Apache 2.0 |
| Which models? | Ollama, Claude, OpenAI, Azure OpenAI, Amazon Bedrock, or any OpenAI-compatible server |
| Can I self-host? | Docker Compose setup documented, but blocked until the agent image ships with 0.1.0 |
| Hosted option? | Yes, at foundry.helix-db.com |
| Stack? | Next.js frontend, Go backend, MySQL store, HelixDB graph |
| Release status? | No 0.1.0 release published yet |
What does Helix Foundry actually do? #
According to the README, the project's pitch is to "connect your company's data, let an agent draft an ontology over it, and load it into HelixDB." Three stages follow from that sentence.
First, connect. The listed connectors are PostgreSQL, MySQL, Amazon S3, Stripe, PostHog, WorkOS, GitHub, Linear, Granola and Cal.com. You can also upload Markdown, text and PDF documents, and table files in CSV, TSV, JSON, JSON Lines and Parquet.
Second, draft an ontology. The agent proposes entity types, the links between them, the source tables and documents each comes from, and rules. A human then reviews it, edits it, and marks a version as current. That review step is the important design choice: the model suggests the schema, but a person owns it.
Third, load and query. The data lands in HelixDB as one graph. You can browse it as a graph or as records, trace any value back to its source row or quote, and ask questions that come back with citations.
Nodes and edges in a graph database with one highlighted path, illustrating how Helix Foundry loads company data as a single graph
Why an ontology instead of just embeddings? #
Most retrieval setups chunk documents, embed them, and fetch the nearest chunks. That works for "find the passage about refunds," but it struggles with questions that cross systems: which customers in Stripe opened a Linear ticket and then churned? The answer lives in relationships, not in any one passage.
An ontology names the things your company cares about (customer, subscription, ticket, repository) and how they connect. Once the graph exists, an agent can traverse relationships rather than guess from similar text. The same idea drives Sakana Aquarium, which Sakana AI announced on October 23 as an ontology-based platform for enterprise agents, and it is the reason tools like Graphify build a knowledge graph of a codebase instead of dumping files into a prompt. Foundry applies the pattern to business data, and the open license makes it the easiest of the three to inspect.
Provenance is the other half. The README says users can trace values back to the source row or quote. For anyone who has watched an agent confidently invent a number, that traceability is the feature that decides whether a graph can be trusted. Compare it with the provenance problems measured in Agent Zero's memory provenance benchmark.
What is HelixDB underneath? #
HelixDB's documentation describes it as a graph database with native vector and full-text search, built on object storage. The documented features include:
- ACID transactions across graph, vector and text data.
- Vector search with prefiltering and over 90% recall.
- Full-text search for exact terms and keyword relevance.
- Equality and range filtering on node and edge properties.
- Object storage as the source of truth, with NVMe and memory as caches, so storage scales separately from compute.
- Multi-tenant and single-tenant horizontal scaling, with bring-your-own-cloud listed as coming soon.
Everything is one labeled property graph: nodes are entities, directed edges are relationships, and both carry typed properties. Vector, text and secondary indexes are access paths over those properties, so there is no second system to keep in sync. The docs frame the use cases as shared memory and context for agent swarms, enterprise search and "company brains." The documentation page we read does not state a license or describe the query language in detail, so check the repo before assuming either.
Foundry is the application layer on top: a Next.js app at the repo root plus a Go backend with the API, sync workers, ontology drafting, HelixDB , question answering and a MySQL store. The hosted service runs the same backend code as a library.
How to try it #
The README documents a local path that needs Docker with Compose v2:
git clone https://github.com/HelixDB/helix-foundry
cd helix-foundry/local
./setup.sh
docker compose build
docker compose up -d --wait
The local version has no sign-in: there is one owner and every connector is enabled. In Settings, under AI models, you pick a provider. Ollama lets you keep inference on your own machine, which matters if the data is sensitive; see our guide to running open models locally for a setup that pairs well with it.
Two caveats from the README matter here:
- The ontology-agent image is not public yet. Until 0.1.0 ships, the stack will not start without it. Treat the local instructions as a preview of the release, not something that works today.
- No 0.1.0 release exists. Pin to a tagged version once one appears.
If you only want to look around the UI, the front-end documentation says pnpm dev:mock (Node 24 and pnpm required) runs the site against a mock API, so no account or secret is needed. A hosted instance is available at foundry.helix-db.com.
The licensing detail you should not skip #
The README's License section says everything in the repository, the site and the backend is Apache 2.0, and so are Foundry's three images: foundry-site, foundry, and ontology-agent. HelixDB, which the local Compose file runs beside them, is Apache 2.0 too. Earlier versions of the README may have described the agent image differently, so re-read the License section and the LICENSE file before building anything commercial on it.
The practical gap is availability, not licensing. The ontology-agent, the component that actually drafts the ontology, is not published until the 0.1.0 release, so the agent that decides what your schema looks like is something you cannot run yet.
How it compares with what you may already use #
| Approach | Strength | Weakness |
|---|---|---|
| Embeddings plus a vector store | Quick to set up, good for passage lookup | Weak on multi-hop questions across systems; provenance is only a chunk |
| Hand-built knowledge graph | Full control over schema | Slow and expensive to design and keep current |
| Agent-drafted ontology (Foundry) | Fast first draft, human review, traceable values | Draft quality depends on the model; agent image not yet published; pre-release |
| Agent memory in markdown files | Simple, portable | Does not model relationships; see shared memory handoff guide |
We have not run Foundry ourselves, because the agent image is unavailable, so none of the quality claims above are measured. What we can say is what the documentation promises.
What to ask before adopting it #
- Who reviews the ontology? The workflow includes human review. Decide who owns that, because a wrong relationship in the schema quietly corrupts every answer built on it.
- What leaves your network? If you choose Claude, OpenAI or Bedrock as the model, parts of your data go to that provider. Ollama keeps it local, with the usual quality trade-offs of smaller models.
- How are connector credentials stored? Stripe, GitHub and database credentials are high-value. Read
backend/README.mdand the security notes in the repo before pointing it at production. - How do agents get access afterwards? A graph is only useful if agents can query it. OurMCP primer explains the standard way to expose tools and data to agents, and ouragent skills guide covers packaging that access. Neither the README nor the docs page we read says Foundry ships an MCP server, so confirm before planning around it.
- What happens at scale? The README reports about 1.7k stars, 257 forks and 8 open issues at the time of writing. That is early-project territory: expect rough edges.
Why the repo is trending #
HelixDB-related traction is part of a broader move: after two years of "just add a vector database," teams building agents are rediscovering structure. Enterprise vendors are pitching ontologies, open-source projects are shipping knowledge-graph skills for coding agents, and database makers are positioning themselves as the memory layer for agent swarms. Foundry is notable because it combines a database vendor's own storage engine with an application that automates the hardest manual step, schema design, and does it under a permissive Apache 2.0 license.
The honest limit is maturity. A pre-0.1.0 project whose agent image is unpublished is a project to watch and prototype against, not to depend on. Star the repo, try the mock UI, and revisit when a release and the public image land.
Bottom line #
Helix Foundry is a promising, openly licensed way to go from raw company data to a reviewed, queryable graph with citations. Its value will depend on how good the agent-drafted ontologies are in practice, which nobody outside the team can measure until the agent image is released. We will add an update here when 0.1.0 ships.
Related reading #
Details reflect the repository README and HelixDB documentation as read on October 27, 2026; the project is pre-release and may change.