Brekfuz answers questions about what a company already knows, in the channel and the thread where the question was asked, with the sources attached. The part of the answer you are cleared to read posts in public; the rest arrives as a direct message, and nothing crosses that line.
- EverySources per answer, checked before generationSource permissions are resolved before the model is given any content, so material a person cannot open never enters their answer. · as of 6 Sep 2026
- 2Delivery surfaces per answerOne answer is delivered to two audiences: the cleared part in the channel, the restricted remainder to the asker alone. · as of 6 Sep 2026
- 0Write scopes requested on mail and calendarGoogle is granted read-only access. Slack is the only surface written to, and the app posts as itself rather than as a user. · as of 6 Sep 2026
The problem
Search across a company's Slack, mail and calendar is either useless or unsafe. Index everything and answer at the asker's permissions, and a restricted memo surfaces in a public channel. Index only what is safe for the channel, and the detail that actually answered the question quietly disappears.
Most of what an organisation knows was never written down anywhere, so retrieval returns nothing and the question goes back to whoever remembers. Because those questions never pass through one place, nothing about them is countable: which topics are surging, which have no owner, which people the organisation quietly depends on.
The system
A permission-aware retrieval layer over Slack, mail and calendar that carries per-source clearance from the query all the way through to delivery.
What it is made of
- Read-only connectors. Mail and calendar are granted read access and no write scope at all. Slack is the only surface written to, and the app posts as itself, never as a user.
- Retrieval that fails closed. Source permissions are resolved on every query before generation, so content a person cannot open never enters their answer, and each answer keeps a record of which sources it used and who is cleared for each one.
- Audience-aware delivery. That per-source record is what makes the split possible: the cleared part posts in the channel with its sources attached, the restricted remainder reaches the asker as a direct message, and every access decision lands in an append-only audit log.
- Routing for what nobody wrote down. A question with no documented answer is put to the person who made the call, inside Slack; their reply is captured so the same question resolves from the index next time.
My role
I am the first and only engineer at Brekfuz. The connectors and the indexing behind them, the retrieval path that resolves source permissions before a model sees any content, the clearance split and the two delivery surfaces it writes to, the tenant boundary underneath all of it, and the reporting layer that counts what the organisation could not answer. The scope decisions are engineering here rather than a compliance afterthought — read-only on mail and calendar, write to nothing but Slack — because the permissions an integration holds are the blast radius of a bug in it.
The decisions
Isolation belongs in the database, not in the query. Row-level security is forced on the tables holding customer data, so the database refuses another customer's rows even when application code asks for them incorrectly, and each customer's search data sits in a separate namespace rather than a shared index filtered by query. The alternative was the usual multi-tenant answer — a tenant filter applied in application code on every read and write — which holds exactly as long as nobody writes the one query that forgets it. The gain is that the invariant became assertable: the services check it at boot against the live catalogue and refuse to start if a table is unprotected.
Split the answer rather than downgrade it. One answer, assembled per source and delivered to two audiences. The three alternatives are each a different failure: answering in full at the asker's permissions puts the restricted part in a public channel; answering only from channel-safe sources loses the detail that mattered without anyone noticing; answering only in private teaches the channel nothing, so the question gets asked again next quarter. The cost is that clearance has to survive the whole pipeline — retrieval cannot flatten sources into one block of context, and generation has to track which claim came from which source.
The outcome
The mechanism is public rather than promised: the clearance split is presented as the product itself, not as a setting a customer switches on. No usage figures are published, and none appear here.
What is unresolved
Permission-aware retrieval is only ever as correct as the access-control state it last read, and that state moves. A document gets re-scoped, a channel is made private, someone leaves a group — and an answer that was correct when it was assembled is one the system would not assemble today. The audit log faithfully records that the decision was right at the time, which is the wrong guarantee when the citation is still sitting in a channel whose source has since been restricted. Nothing un-says a Slack message. The failure runs the other way too: an index working from a stale snapshot over-restricts as often as it over-shares, and a person granted access an hour ago cannot tell whether a source was withheld because they still cannot read it or because the permissions have not been re-read yet.