Your company already has knowledge. The problem is that a product decision is in Slack, the signed brief is in Drive, implementation lives in GitHub and delivery status is in Linear. Search returns fragments; people still ask which one is current.
An AI company knowledge base should not begin with “move everything into one tool”. Build a searchable operating memory: keep authoritative records in their working systems, index permitted context, refresh it through observable workflows, answer with sources and limits, then route approved actions back to the right owner.
This is a reference architecture, not a deployed IZZY client case or performance result. Product plans, permissions, indexing latency, retrieval quality and operational controls need tenant-specific testing.
The answer in 60 seconds
- Keep records where teams create and maintain them.
- Add an index; do not create a second uncontrolled truth.
- Give each indexed item identity, authority, access and freshness metadata.
- Require answers to cite evidence and expose uncertainty.
- Treat stale, denied and contradictory results as designed states.
- Start read-only. Add actions only after named owners accept the controls.
In this article
- Searchability is not a migration project
- Build five layers, not one brain-shaped database
- Define the minimum viable operating record
- Ingest selectively and preserve the source
- Make every answer prove itself
- Follow one question across four systems
- Design the failure state first
- Roll out from questions to bounded actions
1. Searchability is not a migration project
IBM distinguishes systems that create and maintain domain records from systems that harmonise information across domains. The practical point is simple: one search surface does not need to replace the applications that run the work.
A search layer answers “where is the evidence?” An authority rule answers “which record wins?” Confusing them creates a polished new silo: copied documents with no owner, old decisions that still look valid and summaries that cannot update the source.
Notion Enterprise Search and AI Connectors show one native approach: search a workspace and connected applications, with citations and permission mapping. Their own documentation also describes plan, setup, coverage, lookback, indexing and aggregation limits. Connected is not synonymous with complete, immediate or authoritative.
2. Build five layers, not one brain-shaped database
The “one brain” metaphor is useful only when it produces clear responsibilities. Use five layers:
| Layer | Job | Must not decide |
|---|---|---|
| Source systems | Create and maintain records | Cross-system interpretation |
| Knowledge/index | Make permitted content discoverable | Which record is authoritative |
| Orchestration | Detect, transform, refresh and report state | Business meaning |
| Interpretation | Retrieve, compare, cite and express uncertainty | Permission to act |
| Action | Write through an approved system and owner | Its own authority |
n8n’s RAG documentation separates ingestion from querying: fetch content, split it into chunks, create embeddings, add metadata and retrieve a limited set of relevant chunks. That is useful plumbing. Your operating design still has to define authority, access, freshness, evaluation and failure.
3. Define the minimum viable operating record
Before choosing a vector store or connector, define what the index knows about each item:
| Field | Question it answers |
|---|---|
record_id | Can we update the same item rather than duplicate it? |
source_url and source_system | Where is the original? |
record_type and authority | What is it, and when can it win? |
owner and status | Who maintains it, and is it active? |
permission_class | Who may retrieve it? |
source_updated_at / indexed_at | How fresh is source and index? |
effective_from / review_at | Is the rule current? |
relations | Which project, customer or decision does it concern? |
Use durable organisational locations for durable records. For example, Google says shared-drive files belong to the team, not an individual, subject to edition and policy. But “in a shared drive” still does not mean “authoritative”: the record needs an owner, status and rule for what it governs.
If you cannot fill these fields for a content class, do not quietly index it as trusted knowledge. Classify it as reference-only, exclude it or give it a review queue.
4. Ingest selectively and preserve the source
Select sources by recurring business question, not by connector availability. Slack has search and configurable retention; messages may be edited or deleted. GitHub has repository search, roles and webhooks. Linear searches issues, projects and documents, with documented mode and result limits. Each system exposes useful evidence under different access, history and update rules.
Choose ingestion behaviour per record type:
- Link when users need the current native record.
- Index text needed for cross-system retrieval.
- Copy only a justified immutable snapshot with provenance and expiry.
- Exclude secrets, noise or content whose access cannot be mapped.
n8n’s data loader can attach metadata for later filtering. In Notion, API search is not exhaustive; use structured data-source queries when complete database retrieval is required.
Freshness also needs state. Google Drive notifications say that something changed; the consumer must read the change feed. Store the last successful source event, retrieval and index update. A green connector icon is not evidence that every record is current.
5. Make every answer prove itself
Semantic retrieval returns plausible matches, not a business verdict. n8n’s vector tools expose a result limit; Notion says its connectors are better suited to finding and summarising than complex calculation or broad aggregation.
Require an answer contract:
- Direct answer - concise and scoped to the question.
- Evidence - links to the exact records or passages.
- Authority - which source governs each part.
- As-of time - source update and index time.
- Conflict/uncertainty - missing, stale or contradictory evidence.
- Next action - permitted read-only step or named approval route.
The answer “Launch is 14 October” is unsafe if it hides that Slack says 14 October, the approved Drive brief says 21 October and Linear has no committed milestone.
Preserve access boundaries. If the system cannot map a searcher’s rights to a source, deny or escalate rather than copy the content into a broader index. Connector vendors document permission mapping; treat those statements as capabilities to test, not independent assurance. See IZZY’s guide to AI-agent permissions.
6. Follow one question across four systems
Suppose a founder asks: “Are we ready to launch Atlas on 14 October?”
- Drive contains the approved launch brief and acceptance criteria.
- Slack contains a later pricing discussion, but not an approved change.
- GitHub shows the release branch and an open security fix.
- Linear shows delivery items, owners and current states.
The operating memory retrieves all four, but does not flatten them. It reports: the approved brief names 14 October; one required security fix remains open; delivery state comes from Linear; the Slack pricing discussion is context, not approval. It links every statement, shows when each source changed and routes the readiness decision to the named launch owner.
That is more useful than a confident paragraph assembled from the most semantically similar chunks. It helps a person decide without pretending the retrieval layer made the decision.
7. Design the failure state first
| State | What the user should see | Operating response |
|---|---|---|
| Stale | Last source/index times | Refresh or label answer time-bounded |
| Denied | Source exists but is inaccessible | Stop; request access through owner |
| Contradictory | Both records and authority gap | Escalate; do not choose silently |
| Missing | No adequate evidence | Say “could not verify” |
| Duplicate | Same source/version appears twice | Reconcile identity and re-index |
| Partial | Some sources processed, others failed | Return bounded result and failure state |
n8n can route execution failures, but business recovery remains yours. Record the failed source, stage, last successful checkpoint, owner and replay eligibility. Duplicate comparison helps only when identity fields, history and scope are designed; it is not end-to-end idempotency.
Do not hide a failure behind a fluent fallback answer. “No evidence found”, “access denied” and “index older than source” are useful outputs.
8. Roll out from questions to bounded actions
Start with ten to twenty recurring questions - not as a universal sample, but as a working inventory. For each, name expected sources, authority, access class, acceptable freshness and what a good “could not verify” response looks like.
Run a read-only pilot. Review citations, missing evidence, permission behaviour, contradictions and update lag. Add sources only when they improve a defined question. This is also where you decide whether native enterprise search is sufficient or a custom retrieval layer deserves its operating cost; that later build-versus-connect decision needs its own assessment.
Enable actions only for a narrow pattern with a named owner, exact write parameters, approval rules, write-back, monitoring and fallback. n8n can pause selected AI tool calls for human review, but only tools wired to that review step are gated.
The rollout gate is evidence from your corpus and workflows, not a generic accuracy claim. If the team cannot maintain authority and source metadata manually, automation will not repair the ownership problem.
Conclusion: build a company memory that knows its limits
A useful company brain is not one database and not one chatbot. It is a governed path from authoritative records to permitted retrieval, evidence-led interpretation and controlled action.
Keep working systems accountable. Make the index observable. Make answers cite, date and qualify themselves. Then expand only where the business question, owner and failure path are clear.
Map one recurring company question
Bring one question that currently requires searching several tools, the systems involved, your current authority rule and one recent wrong or contradictory answer. IZZY can map the smallest knowledge-and-action architecture worth testing. The right recommendation may be better record ownership or native search - not a custom AI build.
This is exactly the scope of our n8n AI Automation service.
Frequently asked questions
It is a searchable layer over permitted company knowledge. A production design also needs identity, authority, freshness, citations, failure state and ownership.
No. Keep authoritative records where teams maintain them; index or link only what defined questions need.
Retrieval should preserve source access. If permissions cannot be mapped reliably, deny or escalate instead of widening access through the index.
Not necessarily. Native search/connectors may cover the questions. Custom retrieval is justified only when the required coverage, controls or workflow cannot be achieved acceptably without it.
Start with recurring questions, expected evidence, authority and freshness. Pilot read-only before adding sources or actions.
Sources and method
Research was checked on 2026-07-27 using current official Notion, Google, Slack, GitHub, Linear, n8n, IBM and NIST pages. Links sit beside material claims.
This article is IZZY architecture guidance. No live tenant, retrieval corpus, permission model or end-to-end workflow was tested. Search quality, completeness, latency, security, outcomes, ROI and legal compliance remain unverified.