Enterprise Agentic RAG with Social Connectors
One question box over internal docs, Slack, Jira, and Gmail, where the answer you get is scoped to the department you actually belong to.
Two Kinds Of Knowledge
Knowledge inside a company splits across two kinds of storage that behave nothing alike. There are documents that sit still, such as policies, specs, and onboarding guides. Then there is the conversational record: Slack threads, Jira tickets, email. Most answers live in the gap between them. The policy explains what the process is; the Slack thread explains why it changed three weeks ago.
What it cost to leave that gap open
Every department paid the same tax. A question that should take thirty seconds turned into a cross-team ping and a wait, repeated across engineering, HR, and finance daily. The real cost was not any single lookup. It was that people stopped asking and started guessing.
Why this is an access problem, not a search problem
A single shared index over company knowledge will happily hand finance salary data to an intern, because a vector store has no concept of who is asking. Every retrieval design decision here is downstream of that fact.
The Leak In The Obvious Design
What most teams build
Embed everything into one shared vector store, wire up three API clients for Slack, Jira, and Gmail, and filter results for permissions after retrieval returns them.
Why that boundary is cosmetic
Filtering after retrieval leaks. The model has already read the chunks by the time the filter runs, so a restricted document still shapes the answer even when it is stripped from the citation list. Top-k makes it worse: if six of the ten nearest chunks are filtered out, the answer is now built on four weak matches with no signal that anything was dropped.
How A Query Gets Scoped
Read this one left to right along the token. Department is resolved at the edge, and everything downstream inherits that scope rather than re-deriving it.
What it reads from
What an employee gets
Holding The Boundary
- 01
Metadata partitioning at query time, not filtering after retrieval
Department is resolved from the OAuth token and pushed into the vector query as a filter, so out-of-scope chunks are never candidates for top-k. This is the difference between an access boundary and a redaction step. It also keeps top-k honest, since all ten results are ten results the user is allowed to see.
- 02
Identity Server at the boundary rather than in application code
Role-to-department mapping enforced at the gateway means the retrieval layer receives an already-scoped token and cannot be tricked by a malformed request. Putting that check inside the application would make every new endpoint another place to get it wrong.
- 03
WSO2 Integrator as a single connector contract
Slack, Jira, and Gmail have nothing in common in how they paginate, authenticate, or rate-limit. Normalizing them at the integration layer means the agent reasons about one interface, and a provider-side change is absorbed in the connector instead of rippling into orchestration logic.
- 04
Agent-driven tool selection over hardcoded routing
Routing rules encode the queries you thought of. Real questions cross sources in ways nobody enumerates, like a spec and the Slack thread that revised it. Letting the WSO2 AI Agent choose at query time covers those without a rule written per case.
What It Refuses To Answer
Partitioning by department means a genuinely cross-functional question, the kind where an engineer legitimately needs finance context, returns nothing rather than offering an exception path. That is deliberate, and it is the part of the design most likely to be argued with. Failing closed is the correct default when the alternative is a silent leak, but it does push some real questions back to a human, and the system does not currently distinguish between a question with no answer and a question the asker is not cleared for. Making that distinction visible without leaking the existence of restricted material is genuinely unsolved here.
The WSO2 Layer
Committing to this stack traded portability for a large amount of integration work that would otherwise be hand-rolled. That is the right trade in an enterprise already running WSO2, and the wrong one starting from nothing.
WSO2 Integrator
Normalizes Slack, Jira, and Gmail behind one contract so the agent is not carrying three OAuth flows, three pagination models, and three rate limits in its own logic.
WSO2 AI Agent
Handles reasoning and tool selection at query time, which is what lets a question span a document and a live thread without a routing rule written for that combination.
WSO2 Micro Integrator
Runs the service layer close to the connectors, keeping the hop between orchestration and data sources short enough to stay inside the sub-2s budget.
WSO2 API Manager
Handles exposure and throttling at the edge, so a single team hammering the assistant cannot degrade retrieval for everyone else.
WSO2 Identity Server
Enforces OAuth2 and maps roles to departments at the boundary. The scoped token it issues is what the vector filter is built from, so access control has one source of truth.
LangChain
Handles the prompt chaining that merges static document knowledge with live project state pulled through the connectors into a single grounded answer.
Results
Results
Sub-2s responses on complex multi-source queries at 93%+ retrieval accuracy, with department isolation holding across every access boundary. Replaced cross-team manual lookups as the default path for internal questions in every department.
What I would measure next
How often the fail-closed boundary blocks a legitimate question. A high rate would mean the department partition is the wrong shape and the model should be per-role rather than per-department, which is a schema decision that gets harder to reverse the longer it runs.
What I'd Do Differently
- 01
Build the permission model before the retrieval layer, not alongside it. Department scoping was designed early, but late enough that some ingestion had already run without the metadata, which meant a re-index that a day of upfront schema work would have avoided.
- 02
Treat connector freshness as a first-class concern. Slack and Jira change constantly, and the initial design leaned harder on periodic sync than it should have. Anything backed by a conversation record wants change-driven ingestion.
- 03
Instrument which source answered each query from day one. That signal tells you where knowledge actually lives in the company, and it would have shaped chunking priorities much earlier.
Solving a similar problem?
I'm open to conversations about production AI systems -agentic workflows, RAG pipelines, or messy integration problems like this one.