Most demos of AI over company knowledge show the agent answering. The moment that convinced me this prototype worked was when it didn’t.

I asked Claude Code a simple question: what is the per diem rate for London? The figure was in my knowledge base, on a travel policy page: £75. Claude replied that the knowledge base had no answer, explained that the only expense page it could find covered client dinners, and suggested asking Finance Ops, who own the expense policy.

That was the correct answer. The travel policy was still a draft, and nothing unapproved should reach an agent. Here is how I built it, and what it taught me about context engineering.

Why I built it

n8n talks about running a “company brain”: the layer of company knowledge that people and AI agents both rely on. I wanted to see how much of one I could build with n8n itself, and which decisions would matter most.

I planned the work as a four-hour ticket with one rule: secure the core deliverable before anything nice to have. A checkpoint at the two-hour mark had a fallback plan in case ingestion stalled. I didn’t need it.

Start with the structure, not the pipeline

The source is a Notion database called Company Brain, holding eight fictional policy pages. I chose Notion over a folder of documents because database properties give you taxonomy and governance fields for free. Every page carries:

• Function: Finance, Sales, Engineering, People, or Marketing
• Owner: the team accountable for the content
• Status: Draft, In review, or Approved
• Sensitivity: Public, Internal, or Restricted
• Last reviewed: a date, so freshness can be checked

I seeded the data with deliberate edge cases: a draft page (the travel policy and its unapproved per diem), a page still in review, and a restricted page (salary bands). A test set with no awkward cases proves nothing.

Two lanes, one canvas

The n8n workflow, Company Brain v0, has two lanes on a single canvas, so one screenshot tells the whole story.

Lane 1, governed ingest. A manual trigger and a daily schedule trigger fetch pages from Notion, keeping only those marked Approved. A governance gate (a Switch node) then routes Restricted pages to a dead-end branch labeled “Excluded: restricted.” Everything else is prepared, embedded with OpenAI embeddings, and indexed in a vector store.

Lane 2, served over MCP. An MCP Server Trigger exposes a single tool, search_company_knowledge, over that index. I connected Claude Code to it with one claude mcp add command and a bearer token.

The tool’s description deserves more care than its size suggests. Claude reads it to decide when to call the tool, which makes it documentation written for an agent, much like the description field of an agent skill. That is context engineering in miniature.

What the answers showed

> What's the limit for client dinners?

  Called company-brain

  Client dinners are capped at €60 per person, drinks
  included. If the total goes above €300, you need
  pre-approval.

  Source: Expense policy
  (https://app.notion.com/p/Expense-policy-…)
  (Finance Ops, last reviewed 2026-10-14).

> What is the per diem rate for London?

  Called company-brain

  The knowledge base has no answer on per diem rates for
  London. The only expense page it returned is the Expense
  policy (https://app.notion.com/p/Expense-policy-…), and
  that covers client dinners only (€60 per person,
  pre-approval above €300 total). Finance Ops owns that
  page, so they're the best people to ask about travel
  per diems.

Asked about the limit for client dinners, Claude called the tool and answered: €60 per person, drinks included, with pre-approval needed above €300 in total. It cited the Expense policy, its owner, and its last review date. The metadata did real work here. A reader can judge how far to trust the answer without opening the source.

The per diem question showed the other half. Governance happened at ingest, so the draft figure never entered the index. There was nothing for the model to leak and no prompt instruction to talk it around. And because the owner field came through with the results, even the refusal pointed somewhere useful.

What it doesn’t do yet

This is a prototype, and its limits matter. The vector store lives in memory, so it empties whenever the instance restarts. A production version needs a persistent store or a dedicated context platform such as Qontext. I scoped automatic stale-content flagging, which would tick a Needs review box when a page goes too long without a review, but didn’t build it in this pass. And eight tidy fictional pages are not a company’s worth of messy, contradictory knowledge.

The natural next step is to compare this against a dedicated platform: its change reviews against my Approved filter, its permissions against my sensitivity gate, and its retrieval logs against n8n’s execution history.

The takeaway

The interesting work wasn’t wiring nodes together. It was deciding what the properties should be, which states should block ingestion, and what an agent needs to see alongside an answer before anyone can trust it. Those are information architecture decisions: taxonomy, metadata, governance, and ownership. They are the same decisions I made for developer documentation sets at Oracle, now with an AI agent as one of the readers.

Docs as context, in other words. An agent can only be as trustworthy as the knowledge it is allowed to see.