> For the complete documentation index, see [llms.txt](https://oodlz-ai-studio.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://oodlz-ai-studio.gitbook.io/docs/inbound-agent/the-knowledge/the-knowledge-layer.md).

# The Knowledge Layer

Knowledge and tools live in their own MCP server — not bundled into the agent workflow — so every current and future client connects without duplication.

> **Knowledge separated from the agent — connectable, reusable, never duplicated.**

Most AI agents bundle their tools and knowledge into the agent workflow. That works until a second agent, a third channel, or a new interface needs the same knowledge — at which point the embeddings, the namespaces, the retrieval logic, and the escalation routing all have to be rebuilt. The Oodlz knowledge layer runs as a standalone MCP server. Any MCP-compatible client connects and gets the full toolset immediately.

## How It Works

The knowledge server exposes the agent's tools at a single fixed URL. The inbound agent connects via an MCP Client node and inherits every tool the server hosts — brand catalogue retrieval, FAQ retrieval, instructional content retrieval, and [human escalation](/docs/inbound-agent/the-knowledge/human-escalation.md). Embeddings models are configured once on the server side. Vector search namespaces are configured once on the server side. The human escalation routing is configured once on the server side.

When a new client needs access — a future voice agent, a future internal dashboard, a future MCP-compatible workflow — it points its MCP Client at the same URL and gets every tool the inbound agent gets. No new embeddings to provision. No new namespaces to spin up. No new escalation routes to wire.

## What You Get

* One source of truth for the brand's knowledge — every client connecting reads from the same store.
* Add a new client in one MCP Client node — no rebuilding of any retrieval or escalation logic.
* Embeddings and namespaces maintained in one place — when the catalogue updates, every connected client sees the change next call.
* Future-ready — agents and interfaces yet to be built will plug in via the same MCP protocol.