Multi-Agent & Agentic Systems

Designing a Shared Agentic Knowledge Infrastructure Across Slack, Notion, and Meetings

A proposed five-stage system that connects scattered institutional knowledge through shared anchors, and answers questions in Slack with citations back to the source.

August 21, 2026

OUTLINE

ENGAGEMENT SNAPSHOT

Figure 1 - Key figures from this engagement, at a glance.

EXECUTIVE SUMMARY

Our client's institutional knowledge was scattered across Slack, Notion, and Zoom, with no shared way to connect a decision made in a meeting to the Slack thread that led to it or the Notion page written up afterward. Reconstructing a past decision could take twenty minutes of scrolling and guessing, and the answer that eventually turned up was often already out of date.

Pfactorial Technologies proposed Hive Second Brains: a five-stage system that normalizes Slack messages, Notion pages, and meeting recordings into one common record format, connects related material through shared anchors rather than comparing every document pairwise, and extracts decisions and action items into structured, queryable records.

The design's most important commitment is architectural honesty: it names five concrete techniques for connecting related material across sources, explains exactly where each one is strong and where it struggles, and proposes measuring linking accuracy, extraction quality, and permission integrity against the client's own labeled data before any number is asserted as fact.

Why this engagement is representative This engagement demonstrates Pfactorial's approach to proposal-stage system design: naming the exact technique - anchor-based linking instead of pairwise comparison - that keeps a knowledge system affordable at real scale, and committing to measured evaluation against labeled data rather than an asserted accuracy number.

THE CHALLENGE

Nothing about this system exists yet; the proposal responds to a specific, recurring failure mode in how institutional knowledge gets lost across tools. Several problems needed solving together.

1. Related material has no shared connective structure

A decision, the Slack thread that negotiated it, the meeting where it was agreed, and the Notion page written up afterward exist as four disconnected items, with nothing joining them across systems.

2. Pairwise comparison doesn't scale to real history

Comparing every document against every other document to find relationships grows with the square of the corpus - with ten thousand documents, that's fifty million comparisons, which collapses before it begins against years of Slack history.

3. Most Slack traffic is noise, not knowledge

Lunch arrangements, reactions, and short acknowledgment replies make up a large share of any real Slack history; sending all of it to a language model means paying repeatedly to be told there's nothing there.

4. A single meeting often covers several unrelated topics

A forty-minute standup might work through four separate projects, and attaching the whole transcript to one topic - or to all four - both produce a worse result than knowing which minutes belong to which topic.

The real brief Not "search everything" but "answer a specific question, with a citation back to the source, using material connected across Slack, Notion and meetings even though those systems don't talk to each other."

THE SOLUTION

Pfactorial proposed a five-stage pipeline that flattens every source into one common record format, connects related items through shared anchors, extracts structured facts, and answers questions through an agent with retrieval as one of its tools.

Figure 1 - Proposed five-stage architecture: collection & normalization, storage, source connection, extraction, and retrieval via the agent.

Architectural principles

One common record, regardless of source - a Slack message, a Notion page, and an hour-long meeting transcript are all converted into the same record shape, with anything needed for search, filter, or sort promoted into common fields rather than left in a source-specific payload.
Connect through shared anchors, not pairwise comparison - items point at anchors - a project, a team, a client - rather than being compared against every other item directly, which avoids a cost that grows with the square of the corpus and produces a model that's easy to explain and audit.
Blocking narrows candidates before any expensive work runs - five proposed keys - container/location, participants, time, identifiers in the text, and semantic embedding - use cheap clues to eliminate obviously-wrong anchors before any costly comparison or model call happens.
New anchors are proposed for approval, never created automatically - material that doesn't match an existing anchor lands in a holding pool and is periodically grouped into a suggestion for a person to approve - preventing the same project from splitting into three slightly different names.

CAPABILITIES DELIVERED

The proposed system's capabilities span the full path from raw Slack, Notion, and meeting data to a cited, conversational answer.

CAPABILITY	WHAT IT DOES
Multi-Source Collection & Normalization	Converts Slack, Notion, Zoom, and meeting recordings into one common record format, with speaker identification treated as a first-class requirement.
Anchor-Based Linking	Connects related material across sources through shared anchors (projects, teams, clients) using five cheap-to-expensive blocking keys.
Confidence-Routed Item Handling	Routes every incoming item to auto-attach, model adjudication, or an unassigned pool based on how confidently it can be placed.
Structured Decision & Action-Item Extraction	Extracts decisions, owners, and deadlines into structured records, each linked back to its exact source text with a confidence score.
Permission-Filtered Retrieval	Resolves and applies access permissions before any search runs, so results only ever surface material the requester is already allowed to see.
Agent-Orchestrated Slack Answers	An agent calls retrieval and other tools as needed, composing a Slack-delivered answer with links back to the original message, page, or transcript point.

Figure 2 - How a question is answered: permission filtering first, dual-path search, related-material expansion, and a cited response.

Design note This document describes a proposed method, not a finished system. Where a claim is genuinely uncertain, or depends on the client's own data - such as how cleanly meeting transcripts split by topic - the proposal says so rather than asserting a number that hasn't been measured.

ENGINEERING FOR SCALE AND RELIABILITY

Several design decisions in the proposal target the specific failure modes a naive knowledge-linking system runs into at real organizational scale.

Keys are combined, not trusted individually

no single blocking key is strong enough to be trusted alone, but an item matching an anchor on container, people, and timing simultaneously is treated as close to certain - a language model is invoked only when scoring genuinely can't decide.

Rarer people count for more than common ones

the participant key weights individuals by how informative their presence is - a person who only ever works on one project is strong evidence, while an executive who appears in every meeting tells the system nothing.

Explicit links are exploited before anything probabilistic runs

where a Slack message links directly to a Notion page, that connection is parsed and written at ingestion with no blocking, no scoring, and no model call - the cheapest and most accurate signal available, used first.

Meeting transcripts can be linked at the segment level

a link may carry a start and end position within a transcript, so a forty-minute meeting covering four topics can have specific minutes attributed to each anchor without splitting the underlying record.

Extraction favors precision over coverage, deliberately

the design explicitly accepts missing some decisions - recoverable by ordinary search - over filling the system with plausible-looking non-decisions, because a knowledge base full of false decisions poisons every answer built on it.

Permissions are enforced inside every tool, never by the agent

because the agent reads content that could contain text specifically written to influence it, permission checks live inside each tool rather than in the agent's own reasoning, so no such text can widen anyone's access.

DELIVERY APPROACH

As a proposal, the engagement's phases describe the proposed build sequence for the proof of concept.

1. Collection and normalization - build source readers for Slack, Notion, Zoom, and recordings, converting everything into one common record format with speaker identification for transcripts.

2. Storage layer - stand up the three-way split across object storage, the relational system of record, and the vector index, with the link resolver running as a background job.

3. Anchor-based connection - implement the five-key blocking approach, import anchors from existing Slack channels and Notion databases, and build the propose-for-approval flow for genuinely new anchors.

4. Extraction - build the cheap pre-filter, thread/section grouping, and the structured decision/action-item extraction step, with every item linked back to its source evidence.

5. Retrieval and the agent - build the five-step retrieval flow and wrap it in an agent with a capped clarification loop, delivering cited answers directly in Slack.

RESULTS AND IMPACT

Figure - Key outcomes from this engagement.

As a proposal-stage engagement, no production results exist yet. The design instead commits to what will be measured before real users see the system: linking coverage and accuracy, extraction quality, answer quality, and permission integrity - judged strictly pass/fail, since any leak is treated as a defect that must be fixed before launch - each scored against examples labeled by hand from the client's own data.

The proposal is explicit that dividing a meeting transcript into topics is not a reliably solved problem, and commits to measuring that specific capability on the client's real meetings during the proof of concept, rather than asserting an accuracy figure in advance.

What it enabled commercially

If built as proposed, the system would let anyone at the client's company ask a plain-language question in Slack and get a cited answer drawn from the current, connected state of a decision - rather than reconstructing it by hand across three disconnected tools.

WHY PFACTORIAL

This engagement draws on Pfactorial's data and pipeline infrastructure capability: designing knowledge-linking systems that scale through anchors rather than brute-force comparison, and committing to measured evaluation against real data before any accuracy claim is made.

Figure - Service lines this engagement draws on.

Engagement enquiries Pfactorial Technologies works with teams whose institutional knowledge is scattered across chat, docs, and meetings with no shared index. If you are evaluating whether a knowledge infrastructure system is worth building properly, we are happy to give you an honest read on scope, cost, and risk before anyone commits to anything. · pfactorial.ai

APPENDIX A - TECHNOLOGY STACK

The technology stack underpinning the system, grouped by the layer it serves.

Result and Analysis

ENGAGEMENT SNAPSHOT

A proposed five-stage system that connects scattered institutional knowledge through shared anchors, and answers questions in Slack with citations back to the source.