Fluree
Data + Context for AI and Apps
650 followers
Data + Context for AI and Apps
650 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
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
Congrats on the launch. The detail that stands out is checking permissions on every request instead of only at ingest. That is the failure most teams find late, when an agent summarizes something into an answer the asker was never cleared to see.
One builder question: when the graph auto classifies data and gets a relationship wrong, how visible is that to the person asking? Citations help a lot, but a confidently wrong join is harder to catch than a hallucinated sentence.
Good call on the MCP side, that is the right seam for this.
Fluree
@paul_crinigan Paul, great question! We have a well modeled identity graph that encodes probabilities, evidence and summarizes this for AI. It is up to the use case how much you push AI to spend time getting into the details. Sometimes knowing it is considered a 'match' is good enough, sometimes knowing the match criteria, score and probability is warranted. You can guide your AI via MCP to lean in more if your use case warrants it, or use a custom Agent in Fluree which you optimize for diving in as needed.
I've watched a few AI agent rollouts stall because every app needed its own context setup. If one live data layer can actually serve dashboards, apps, and agents consistently, that's a real infrastructure win, not just a feature. I'd want to see how it handles schema changes over time though.
Fluree
@steven_granata Yes that's exactly what we tackle! We often talk about raw data change but rarely talk about the need for a parallel ontology that itself is constantly changing (the schema of the business). Both need to be able to work efficiently as both are constantly evolving, otherwise you are just looking at an outdated business view even if against live changing data.
Fluree
@steven_granata Very well put—thanks for the comment. Another big benefit of having a single live data layer is that as AI models come and go, Fluree retains all of your data, context, and institutional memory. That makes your AI stack both durable and highly pluggable (bring in whatever model/models you need, at any time). We believe intelligence shouldn't be locked inside a model—it should live in your data, so you can switch models without losing what your organization knows.
I manage integrations for a mid-sized company, and the hardest part has never been connecting an AI model, it's keeping every app's context consistent afterward. One team updates a field, another app doesn't know, and suddenly the AI is confidently wrong. A shared live data layer with built-in permissions addresses that directly instead of patching it downstream. I'd love to see a case study showing how this holds up when ten or more apps pull from the same source simultaneously.
Fluree
@grayson_carter3 That drift problem is exactly why we built it this way — one update, and every app querying that data sees it immediately, no sync jobs or stale caches to patch downstream. A really cool case study we have is with a large manufacturing org in Europe.
A global beauty brand consolidated marketing, product, and social knowledge into a governed "Agent Factory" spanning five core functions, all pulling from the same live graph: flur.ee/case-studies/marketing-intelligence-sovereignty
It's not ten-plus apps yet, but it shows the same-source, same-permissions model holding up across multiple teams and use cases at once. We'll keep pushing for a bigger-scale writeup as more of these land.
Also, hit us up if you'd like to talk shop :)
gnow
Fluree
@nolansym really solid question and honestly the right one to be asking, because the answer is exactly where the data industry is heading.
Short version: yes.
Fluree connects through Apache Iceberg, the open table format that Snowflake, Databricks, and AWS are all converging on. If your Snowflake tables are exposed as Iceberg (via Snowflake Open Catalog), Fluree reads them directly as a graph source — queryable in SPARQL, and joinable against native Fluree data in a single query. Same path works for any Iceberg-compatible lake or warehouse, plus Parquet directly on S3/GCS.
The part we care most about: your data stays in your lake. We don't ETL it into a proprietary store, and we don't route queries through Snowflake's compute — so no warehouse credits burned just to query it. Fluree reads the Parquet directly (with filter + partition pushdown) and adds the governance, reasoning, and verifiability layer on top of the lakehouse you already have. hope that helps!
Fluree
@nolansym Yes, native Iceberg and Snowflake Horizons catalog. Your lake data becomes part of your contextual organization graph -- data stays in Snowflake but queryable as a a graph and Fluree can even apply policy to those graph queries as it has its own Iceberg query engine that executes the queries efficiently. Other options too, but Iceberg is the best way today. :)
Interesting launch! Especially - building permissions into the query layer instead of bolting them onto the model, that's the exact spot access control leaks when it's an afterthought IMO. Do you guys surface the actual query that ran so I can catch an intent miss myself?
Fluree
@artstavenka1 Thanks for the question! Yes complete visibility into the queries and with Fluree immutability and time travel, the time it was executed, so event historical sessions can be accurately reproduced!