EKOS is a compiler for enterprise knowledge ā not another code index. It turns your codebase into structured, evidence-linked facts AI agents can actually trust, each one traceable back to the exact commit it came from. Served to Claude and other AI assistants through a read-only MCP server. The first step toward one auditable knowledge layer spanning an entire enterprise's systems.
š Hi Product Hunt!
I'm Alexey, the creator of EKOS.
I built EKOS after realizing that AI coding assistants still struggle to understand large codebases. Instead of relying only on embeddings and raw source files, EKOS compiles repositories into structured knowledge that can be exposed through an MCP server.
Today EKOS can:
⢠Generate an MCP server from a GitHub repository
⢠Generate technical documentation from source code
⢠Produce architecture-aware knowledge for AI assistants
This is an early open-source project, and I'm actively building it in public. I'd love your feedback:
⢠What would you use it for?
⢠Which integrations should I build next?
⢠What is missing?
Thanks for checking it out! š
Report
Maker
Maker update ā distributed storage + a real query engine landed this week š
Two big pieces shipped since launch, both proven against real workloads, not just unit tests:
1. Distributed storage & query is feature-complete (v1). EKOS can now split a knowledge base across partitions and serve reads/writes from independent worker nodes backed by S3/Azure/local object storage ā a coordinator hands out write leases, query workers cache and serve partitions, and cross-shard search does a real BM25 top-k merge instead of a naive concat.
We didn't just call it done and move on ā we ran two full autonomous end-to-end tests against real 90+ partition workloads (MinIO, live LLM provider, the works). They found 8 real defects unit tests never caught: a runtime panic on the object-store path, a query worker that took down the whole cluster when killed, a heartbeat interval that silently expired write leases mid-pipeline. All 8 are fixed with regression tests, and the reports are public in the repo. If a demo only shows the happy path, it's marketing, not evidence ā so we publish the failures too.
2. A real compiled-knowledge query engine, not just "dump some JSON at the LLM." Natural-language questions now compile into a typed query plan, execute against structured facts + graph + search, and hand the model a flat set of atomic, source-cited claims ā file, line, extractor, confidence ā instead of whole objects for it to re-derive structure from. This is the same "compile once, trust the artifact" philosophy applied to retrieval itself.
Both are on main today. As always ā open source, evidence-backed, gaps documented rather than hidden. Happy to answer questions about either piece below š
Report
No reviews yetBe the first to leave a review for EKOS
Maker update ā distributed storage + a real query engine landed this week š
Two big pieces shipped since launch, both proven against real workloads, not just unit tests:
1. Distributed storage & query is feature-complete (v1). EKOS can now split a knowledge base across partitions and serve reads/writes from independent worker nodes backed by S3/Azure/local object storage ā a coordinator hands out write leases, query workers cache and serve partitions, and cross-shard search does a real BM25 top-k merge instead of a naive concat.
We didn't just call it done and move on ā we ran two full autonomous end-to-end tests against real 90+ partition workloads (MinIO, live LLM provider, the works). They found 8 real defects unit tests never caught: a runtime panic on the object-store path, a query worker that took down the whole cluster when killed, a heartbeat interval that silently expired write leases mid-pipeline. All 8 are fixed with regression tests, and the reports are public in the repo. If a demo only shows the happy path, it's marketing, not evidence ā so we publish the failures too.
2. A real compiled-knowledge query engine, not just "dump some JSON at the LLM." Natural-language questions now compile into a typed query plan, execute against structured facts + graph + search, and hand the model a flat set of atomic, source-cited claims ā file, line, extractor, confidence ā instead of whole objects for it to re-derive structure from. This is the same "compile once, trust the artifact" philosophy applied to retrieval itself.
Both are on main today. As always ā open source, evidence-backed, gaps documented rather than hidden. Happy to answer questions about either piece below š