Most AI summaries die the day after you read them.
You ask a chatbot to summarise your notes, it returns a wall of text, and that is the end of the thinking. You cannot edit the structure. You cannot click a claim to see what it is based on. Tomorrow, when a new meeting transcript or document lands in your brain, the summary does not know about it. The summary was a photograph; what you needed was a document.
How a briefing gets built
- 1
Describe what the briefing is about.
Write a description in plain English. The brain parses it into a typed retrieval brief: anchors (the entities and topics the briefing centres on), intent axes (what angle of those topics matters), exclusions (what is off-limits), temporal window, and voice. Sparse descriptions still work, they just produce thinner briefs. The brief is the contract.
- 2
Pick which brains feed the briefing.
Each briefing can pull from multiple brains at once. The pipeline fans out across the selected brains in a single retrieval pass, then aggregates the candidates while preserving brain attribution across dedup. One briefing can draw on Personal plus Marketing plus one client brain, and every fact in the report still knows which brain surfaced it.
- 3
Edit the document, accept the proposed additions.
The brain proposes three to six sections from your description, routes candidates into them with a confidence score and a reason, and writes the body as a Notion-style block document with citations inline. As you add new material to your brains, the pipeline re-runs on the new content alone and drops proposals into a pending tray on the right rail. You accept what should land, you reject what should not.
Notion-style block editor, citations inline
The briefing is a real document. Edit any block, drag to reorder, insert your own paragraphs between the brain's blocks, restructure sections. Citations live as inline pills you can click to see the source fact. The brain writes the first version; the editor makes it yours.
The pending tray: new evidence waits for your call
As new material lands in your selected brains, the pipeline re-runs on the new content alone and proposes additions to the right rail. Each proposal carries a confidence score, the section the brain wants it under, the routing reason, and the source facts. Accept moves it into the document as a block. Reject teaches the brain to never propose that source to this briefing again.
Confidence on every card
Green at 0.85+, amber at 0.7+, red below. Below the threshold (default 0.6) the proposal never reaches you at all, dropped server-side.
Routing reason
Every proposal explains why the brain picked this section. Hover to see the model's reasoning, decide if it holds up.
Source facts attached
Each proposal carries the underlying facts from your brain, with the brain attribution. Click through to the original before accepting.
Reject is permanent
Rejected sources land in this briefing's exclusion list. The pipeline reads exclusions before routing, so the same fact never gets proposed again.
What keeps a briefing accurate
The description is the contract
Parses into a typed retrieval brief (anchors, intent axes, exclusions, time window, voice). The rest of the pipeline runs against that brief. Sparse description, thin brief. Specific description, sharp brief. The model cannot improvise around what you wrote.
Multi-brain by design
Retrieval fans out across the brains you selected in one pass. Dedup preserves brain attribution across namespaces, so a fact found in Personal and Marketing still surfaces both brains. No "everything looks like Personal" mis-attribution.
You stay the editor
The brain proposes. You accept or reject what enters. The block editor lets you rewrite, reorder, and insert your own thinking next to the brain's. Reject feeds exclusions, so what you said no to does not come back.
What you walk away with
- A Notion-style editable document, not a frozen summary
- Citations inline as pills you can click to verify the source
- Multi-brain routing in one retrieval pass, with brain attribution preserved
- Pending tray surfaces new evidence as your brain grows; you decide what enters
- Reject is permanent: exclusions feed back into the pipeline so the briefing never re-proposes what you said no to
- Confidence threshold (default 0.6) drops low-quality proposals server-side before you ever see them
- Section ids are enum-constrained so the model cannot fabricate a section
- Cited fact UUIDs are subset-verified server-side before any block persists
Pairs well with
Frequently asked questions
How is this different from asking a chatbot to summarise my docs?+
A chatbot reads what you paste and writes a flat reply. A briefing reads your brains as a connected knowledge graph, designs sections from a typed retrieval brief, routes each candidate into the right section with a confidence score and a reason, and writes the body as an editable document with citations on every claim. It also auto-updates when new material arrives in your brains, which a chat reply cannot do.
What does the Notion-style editor let me actually do?+
Everything you would expect from a block editor. Edit any block, drag to reorder, insert your own paragraphs between the brain's blocks, restructure sections. The brain writes the first version; the editor makes it yours. Citations live as inline pills you can click to see the source fact.
What is the pending tray and how does it stay accurate?+
A right-rail panel where the brain proposes additions to the briefing as you add new material to your brains. Each proposal shows the candidate content, the section the brain wants it under, a routing reason, the source facts, and a confidence score (green at 0.85+, amber at 0.7+, red below). You accept proposals you trust, reject the rest. Rejections feed back into briefing exclusions, so the same content never gets proposed again to this briefing.
Can a briefing pull from multiple brains?+
Yes, and that is the point. Every briefing accepts a set of brains. The retrieval pass fans out across them in one go; dedup preserves which brain each fact was found in (no 'everything looks like it came from Personal'). One briefing can mix Personal plus Marketing plus a client brain, and the brain attribution travels with every claim.
How does the description affect what ends up in the briefing?+
The description gets parsed into a typed retrieval brief: anchors (people, topics, projects), intent axes (the angle that matters), exclusions, time window, voice. The brief is then the contract for the rest of the pipeline. Vague description, thin brief, thin briefing. Specific description ('the cold-outreach experiments from March that earned a reply'), sharp brief, sharp briefing. Editing the description regenerates the brief; editing sections does not.
Can the model invent sources or sections?+
No, by construction. Section ids are enum-constrained on the routing step, so the model cannot route content to a section that does not exist. Synthesis returns cited fact UUIDs, which the server verifies are a subset of the candidates fed in. Anything below the confidence threshold (default 0.6) is filtered server-side before you see it. The guarantees are in the pipeline, not just in the prompt.
Can I tell the briefing what NOT to include?+
Yes, two ways. You can put exclusions directly in the description ('do not include anything from the failed pilots'), which the retrieval brief picks up and the pipeline strips before routing. Or you can reject a pending proposal, which adds the underlying source to briefing_exclusions so that fact never gets proposed for this briefing again.
Will my brains' data leak across briefings?+
No. A briefing only ever sees the brains you explicitly selected on creation. Each fact in the document keeps its brain attribution. Exclusions are scoped to one briefing, not your account.
Two ways to keep the briefing fed
A document, not a screenshot.
Start free with 40 documents. Build a brain. Write a description. Watch the briefing grow as your brain grows.