Fluree AI - Give every AI agent trusted context
by•
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.


Replies
MonoCloud for Startups
Provenance is the part of agent context most people ignore until an agent confidently acts on stale data in production. Building trust into the data layer instead of bolting it on later is the right call. The pitch I would lead with is auditability. When an agent makes a decision, teams need to trace exactly which context it used, and that is a security and compliance story that opens enterprise doors fast.
Fluree
@roguetink Thank you kindly. Auditability is a first-class citizen in our architecture, because it's exactly what the business needs for compliance, review, and quality control when building on agents + data.
Provenance means a few things to us:
- Where did that data originate?
- How did that data change over time?
- Who (or what) changed that data over time?
- Who is asking for that data?
Because we can do that for data through our git-like immutable updates to the db layer (docs here), we can also prove:
- Why did in agent come up with this answer, number, or dashboard?
- Exactly what set of queries led to this action?
- Where and how did this agent act (if allowed to)
More on Verifiable Data here: https://labs.flur.ee/docs/db/concepts/verifiable-data for the nerds :)
Appreciate your comment!
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.
@bplatz good to hear there's a confirmation threshold. is that threshold check blocking (the relationship doesn't go live in the graph until a human clears it) or does it ship immediately and get flagged for review in parallel, meaning an agent could act on the low-confidence link before anyone's looked at it?
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!
gnow
Fluree
@bplatz @nolansym Thanks Jordan! We <3 graphs because they allow for immense flexibility and amazing reasoning capabilities.
Fluree
@kevin_doubleday @nolansym Thanks Jordan!!!
The "zero hallucination" claim is worth scrutinizing. Grounding AI in a verifiable knowledge graph genuinely reduces confabulation, but it doesn't eliminate it,
the retrieval layer still has to correctly map a query to the right subgraph, and that step can fail quietly.
Fluree
@mohammed_messeguem Sure, and the AI model you use here can also make a big difference. But efficiently allowing the model to understand the knowledge that exists, how it is connected across graphs, and statistics about the data -- combined with a good AI model works incredibly well.
Fluree
@mohammed_messeguem adding 'confabulation' to my vocabulary immediately!
@kevin_doubleday it's just a fancier way to say hallucination
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. :)
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.
One of the biggest AI challenges today is reliable context, and Fluree seems to be addressing it head-on. Excited to see how developers build on this.
Fluree
Thanks @benln for hunting Fluree AI.
Models are moving fast these days.
Data, on the other hand, is still messy.
Fluree AI aims to solve that.
We use some really cool tech under the hood (knowledge graphs + ontologies) to get your data intelligently connected and "AI-Ready."
From there, you can build experiences and interfaces from this durable data layer. Build apps that query and transact to Fluree AI. Build dashboards that are always live against your data. Ask questions that you could never have possibly answered without integrating multiple silos together. The possibilities are endless!
We love feedback, so please hit us up in the comments :)
How do developers measure the accuracy improvements of applications built on Fluree? Cutomers case studies with measureable outcomes would answer that question well.
Fluree
@advin_jadis We have case studies on our website, but generally testing is best with your own use case and is pretty straight forward. Connect your relevant data with Fluree AI, use it or expose as MCP if similar/same data is in other places and you want to test against 10->20 questions. In this webinar we recently did you can see a side-by-side real-time example of Fluree data vs Snowflake MCP -- close to 10x better in Fluree across the board in speed, lower token usage, accuracy.