Staff ask a question in Microsoft Teams (this pattern can also port to other channels like Slack or WhatsApp by swapping the delivery step) and get an answer drawn from the company's own SOPs. One n8n router agent delegates to role-scoped specialist agents, each retrieving from its own knowledge base, with documentation an ops team can run from. Configurable to any role split. Reference build on synthetic data.

A staff-facing assistant that lives in Microsoft Teams and answers policy and procedure questions from an organization's own SOPs, not from a model's general training. A single router agent reads the question and hands it to the right specialist agent, and each specialist answers only from its own knowledge base. The pattern is configurable: point it at whatever set of roles an organization has, and give each one its own document set. This build wires up four functional domains (Frontline Operations, People and HR, Finance and Procurement, IT and Access) as a worked example. It is a self-directed reference build on a local n8n instance with synthetic SOPs, not a production deployment.

Most operators share the same problem. Staff ask the same policy questions repeatedly, the answers are scattered across SOP documents, and a generic chatbot will confidently invent an answer it does not actually have. A single all-purpose assistant also blurs boundaries, answering a finance question out of the HR material or the reverse.

The goal was a system where each area has its own grounded assistant, the routing between them is automatic, and any answer the system cannot support from its sources is declined rather than guessed.

Two n8n workflows over a configurable multi-agent design, documented from the build:

A router agent (Claude, with conversation memory) that classifies each Teams message and delegates to exactly one specialist. Specialists are attached as tools, so adding or renaming one is a configuration change, not a re-architecture.

One specialist agent per domain, each constrained by its system prompt to answer only from its own knowledge base and to name the owning team when something is not documented.

A retrieval layer (RAG). An ingestion workflow chunks and embeds each SOP set into a per-domain vector store, and at query time each specialist retrieves from its own store as a tool.

A Microsoft Teams integration through Azure Bot Service, with an async reply pattern that keeps the bot inside the Teams response window.

One router delegates to role-scoped specialists using n8n's AI Agent Tool node, so the specialists run as tools of the router rather than as separate sub-workflows.

The domain set is configuration. Four functional areas are wired up here as an example, and the same router supports any split.

Retrieval and knowledge isolation

Each domain has its own vector store, so a question is answered only from the matching corpus. Boundaries are enforced at the data layer, not just in the prompt.

The store is provider-agnostic. The demo runs on an in-memory store, and moving to Pinecone, Qdrant, Supabase, PGVector, or Azure AI Search is a one-node change, with the embeddings, loader, and agent chain unchanged.

Documents are retrieved at query time, never used to train or fine-tune a model.

Teams integration and reliability

Teams expects a fast acknowledgement to every activity, and an agent plus retrieval round trip can exceed that window. The webhook returns its 200 immediately, then the agent runs and posts the answer back as a proactive message through the Bot Framework Connector.

The native Teams trigger only fires on Microsoft Graph change notifications, which suits notifications but not a conversational bot, so the design routes through Azure Bot Service.

Documentation and handover

The system is documented from the build: an architecture overview, the routing and retrieval design, and a setup and reconfiguration guide, so an ops user can stand it up, run it, and add a domain without me.

A shared Claude model and a shared embeddings node feed every agent, for consistent behavior and simpler cost control.

The workflows and runs below are the real artifacts behind this write-up:

This is a reference build, so the honest result is what it demonstrates and how cleanly it holds together, not a production metric. End to end: a question in Teams is classified by the router, handed to the right specialist, answered from that specialist's own SOPs with the source cited, and declined when the sources do not cover it. Domains stay isolated, the Teams integration stays inside the response window, and the domain set can be reconfigured without touching the architecture. The system is documented well enough that someone other than the author can run it and extend it.