Fluree
Data + Context for AI and Apps
388 followers
Data + Context for AI and Apps
388 followers
Fluree is an enterprise AI data platform and verifiable knowledge graph database that combines immutability, security, and semantic graph capabilities. It operates as a unified intelligence layer, helping organizations connect fragmented information into a single "source of truth" to power zero-hallucination AI agents, analytics, and decentralized data sharing
This is the 3rd launch from Fluree. View more
Fluree AI
Launching today
Fluree AI gives every app and AI agent the same trusted context from your company data. Ask questions and get cited, verifiable answers from one live data layer, with permissions checked on every request. Instead of rebuilding prompts or relying on RAG guesses, Fluree queries structured data directly and connects to MCP-ready agents, dashboards, and apps in minutes.
Free Options
Launch Team / Built With
Fluree
Hey Product Hunt — Brian here, CEO of Fluree.
The backstory:we spent years building governed, verifiable graph data infrastructure for enterprises — provenance, permissions, cryptographic audit trails, the unglamorous stuff.
Then LLMs arrived, and suddenly the entire world had our problem: AI that's brilliant at language and terrible with data. Hallucinated numbers. Context that resets every conversation. Five tools, five silos, five versions of the truth.
Fluree AI is our answer: an intelligence layer that sits under everything you build.
Here's the flow:
Throw everything at it. CSVs, databases, docs, SaaS exports. Fluree classifies your data and connects the dots automatically — the graph builds itself.
Plug in any AI. Claude, OpenAI, Gemini, Ollama — any MCP-speaking agent reasons over the same graph. No tools yet? Ours is built in.
Get answers you can prove.Responses are structured queries against the graph, not generated guesses — so every answer is cited, permissioned, and reproducible. If the data is correct, the output is correct.
Build unlimited interfaces on one foundation. This is the part that changes how you work: ask a question, then say "make that a dashboard," then "turn it into an app my team can use," then "deploy an agent that watches this." Chats, dashboards, apps, and agents all read from — and write back to — the same governed graph. You stop rebuilding context in every tool. It compounds instead.
Most software starts from the UI and traps your data underneath it. We think the future starts with the right data + context — and then any interface you want becomes cheap to build and safe to trust.
Getting started takes ~2 minutes: sign up free, drop in a dataset (messy is fine — that's the point), and ask your first question. No demo call, no sales gate.
I'll be in the comments all day with our engineering team. Ask us anything — and if you think "cited, verifiable answers" sounds too good, please come try to break it. Genuinely. That's the fun part.
I'm curious how Fluree handles data that changes rapidly, like real-time sensor feeds or transaction streams. Immutability sounds great for auditability, but I wonder if it creates friction when you need fast updates. Would love to see a breakdown of how they balance permanence with agility in practice.
Fluree
@nancy_philip Thanks for the question! Fluree's open source Knowledge Graph DB which Fluree AI sits on is genuinely the fastest knowledge graph database: https://github.com/fluree/benchmark-db out there, however it is not a streaming records tool like e.g. a Kafka, which makes different tradeoffs. So depends what volume/size you mean by real-time sensor feeds or transaction streams but it will easily handle more than any other knowledge graph, but well less than a Kafka.
This is the first data platform I've seen that treats security and semantics as equally important. Usually one gets sacrificed for the other. I'd like to know more about the tradeoffs.
Fluree
@sulemna_ola We focused on making the fastest core knowledge graph, but yes fine grained security and reasoning over semantics takes genuine work and CPU cycles. Our foundational performance allows us to do reasoning, fine grained security, and even fully serverless knowledge graph databases where others could not, but it is not limitless.
Brian, the permissions-checked-on-every-request piece is the part that lands for my world. I run HIPAA-compliant AI, and access control enforced at the data layer is the only version that survives an audit.
The question your own pitch raises: you let someone ask a question, then say "make that a dashboard," then "turn it into an app." When a query becomes a derived surface, does the permission re-check per viewer of that dashboard, or snapshot the access of whoever built it? In healthcare, minimum-necessary means a report built by an admin with broad access, then opened by a front-desk user, has to narrow to the viewer, not inherit the builder's grants.
If the per-request check follows the data into the derived interfaces, that is a compliance story, not a feature. If it stops at the first query, the leakage just moves downstream. Which is it today?
Fluree
@clemente_lopez1 Great question and YES permissions apply to every read/query based on user + agent context. So this it is not permissions at first query to create the dashboard then its static, it is permissions for every viewer of that dashboard, every view. Even for the same viewer, if they could see facts yesterday where their permissions don't allow it today, then they will see something different today.
Trusted context is the right problem, but I'd split it in two. One half is "can I trust this source", provenance, and it sounds like that's your core. The other half is "do I even have enough to answer", and that one bites me most.
An agent with perfectly trusted but incomplete context still answers, confidently, from the gap. The provenance is clean, the answer is wrong, because nothing told it the context was thin.
Does Fluree surface coverage to the agent, some signal of "you have enough" vs "you're extrapolating", or is it focused on verifying whatever did get retrieved?
Fluree
@jernej_jan_kocica We test this! We test adversarial and 'injected' question answers with forcing the AI to be grounded only in the specific knowledge we want it to be. We have 100% success with this with some AI models (like all Anthropic models except Haiku), but it requires both Fluree and a well trained model for this to work all the time.
the "throw everything at it and the graph builds itself" part is what I keep coming back to. auto-classifying data and mapping it to an ontology is exactly the kind of thing that works great 95% of the time and quietly gets one relationship wrong the other 5%. when the automatic mapping misclassifies a field or links two different concepts together, is there a review step before that goes live, or does it just start feeding agents until someone notices an answer looks off?
Fluree
@galdayan We try to balance determinism vs probabilistic and with Fluree AI, doing so in a fully serverless environment. Fluree has better than human accuracy for most of our customers, but some very hard problems we have in the past turned to using custom trained ML models -- so there are options.
Fluree will leverage a taxonomy / gazateer that it will ground the fact extraction from. We build identity graphs across sources and for those will require human confirmation for matches that don't cross a certain threshold.
What I find genuinely useful here is the permissions-per-request model. I've seen access control get bolted on as an afterthought in other AI setups, and it always shows. Building it into the query layer itself feels like the right instinct, not a patch.
Fluree
@ramish_saje Thanks Ramish!
That was a deliberate call. If we handle security and permissions at the data layer, we never risk leakage at all. Handing that responsibility over to an LLM is certainly asking for disaster.
More on Fluree's query policies for those who want to go deeper :) https://labs.flur.ee/docs/db/security/policy-in-queries