Launched this week
qbrin
Enterprise AI trust layer with citations & 20x fewer tokens
177 followers
Enterprise AI trust layer with citations & 20x fewer tokens
177 followers
Qbrin is a trusted enterprise layer for AI agents, built for companies that cannot afford wrong answers. It turns messy company knowledge from documents, Slack, Gmail, tickets, wikis, databases, and systems into structured, evidence-backed memory with permissions, provenance, citations, freshness, relationships, and abstention. For high-stakes teams in defense, medicine, drones, security, finance, and compliance, Qbrin helps AI agents know what to trust, when to answer.
Tested it with our messy internal docs and the citations actually trace back to the right Slack thread, which is rarer than it should be. The abstention behavior when it lacks confidence feels genuinely useful for high-stakes workflows.
@eymenyabasoqjc Really appreciate you testing it; that’s exactly the use case we care about. For high-stakes workflows, we believe the system should either show the evidence clearly or abstain instead of guessing. In our benchmarks, Qbrin still maintains a high answer rate, but when the evidence is weak, stale, or conflicting, it chooses not to guess.
how does it handle data freshness when a source like slack or a wiki changes constantly does it re-embed in real time or batch and how much lag should i expect before an agent reflects the latest info
@rorbay74131 Great question. Here are the actual mechanics: it's event-driven, where the source can push, and an incremental batch where it can't. Slack messages arrive as webhooks and go straight onto the ingest queue, so new threads are chunked and embedded within seconds, while non-push sources (some wikis, mail sync) are polled at a tunable 15-minute default. We never re-embed the corpus: everything is content-hashed, so a wiki edit costs one document's worth of work, not a rebuild. And retrieval always reads the live index (our compressed "brain" layer is just an accelerator on top), so agents see fresh content immediately. Measured, not promised: in our change-to-answer benchmark today, a newly uploaded fact came back as a correct, cited answer in 15 seconds median, 30/30 trials, script in the repo. So expect seconds for pushed or uploaded content, and worst case one poll interval for everything else.
the permission-respecting part is what I'd actually want to stress test. Access isn't static - someone leaves a team, a channel gets locked down, a doc's sharing changes. If a document was ingested when a user had access and their permissions get revoked later, how fast does that propagate to what the agent will surface to them? That's usually the gap between "respects permissions" in theory and in an actual audit.
@galdayan yes true that’s exactly where permission-aware systems usually break. For Qbrin, permissions are checked at query time, not baked into embeddings or the index. So every answer re-evaluates whether the user can access the source right now. If access changes, the next connector sync updates that state; immediate for push-based sources like Slack, and bounded by the sync interval for polled sources like Drive/wiki.
Because enforcement happens at query time, no re-embedding or rebuild is needed. And we fail closed by default: unknown identity or unclear permission = denied, not allowed.
Happy to walk through the enforcement path; we designed it to be small and auditable.
@kate_saikishore that bounded window for polled sources is the part I'd want visibility into as an admin, not just trust. can you actually see what the current sync interval is per connector, and get alerted if it drifts (say a wiki poll that's supposed to run hourly silently stops for a day)? fail closed on unknown identity is the right default, but a stale-but-still-authorized state is a different failure mode than access being unclear
@galdayan, completely agree. Stale-but-still-authorized is a separate failure mode, not the same as unclear access.
That’s why we treat connector freshness as an auditable control: admins should be able to see last sync, expected sync interval, permission-state age, and connector health per source. If a connector misses its sync SLA or permissions become stale beyond the allowed window, it should alert and optionally fail closed for that source until refreshed. So the goal is not just “we respect permissions,” but “you can prove the permission state was fresh enough at answer time.”
@kate_saikishore that's the right framing - provable freshness rather than just a policy statement. this is a genuinely solid answer, most tools i've seen in this space just wave their hands at "we respect permissions" and stop there. following the launch
the abstention behavior here is a really thoughtful design choice, so many RAG setups will confidently fabricate instead of admitting uncertainty.
@eyll63557046664 Thanks! That was exactly the goal in production: a system should know when the evidence is weak; either it will ask to connect more data sources or say “I don’t know” instead of giving a confident wrong answer.
Macaly
citations + 20x fewer tokens is the enterprise combo everyone wants 👏 landing any big logos yet?
@petrkovacik Hey Petr, We’re currently testing with a few startup design partners and are now starting broader cold outreach to enterprise teams. No big logos to announce yet, but the early focus is proving the hard parts first: citations, permission-aware retrieval, freshness, and lower token usage in real workflows. If you know teams struggling with internal knowledge trust, happy to connect. Appreciate the support! :)
How are you claiming that its gives only right answers? And dont you think the other products do the same mean the RAG systems?
@keerthi_reddy12 Yes, true. RAG systems do give citations and verification! And we have done better with our patented technology!