Launching today
qbrin
Qbrin: The universal trust layer for enterprise AI agents
129 followers
Qbrin: The universal trust layer for enterprise AI agents
129 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.
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.