Logic/architecture of the external integrations

[olharaujo]

Hi everyone, how are you? Could you explain why the logic/architecture of the external integrations is so fragmented? I mean: why do I have separate connectors for RAG, App in Craft, and for MCP and OpenAPI actions? Why can't I, for example, perform a single authentication on Google Drive and configure whether I'll use it for RAG and also for actions?

Is there some product logic or business rule that I'm missing that would have led to it being done this way?

[P4ST4S]

I do not maintain Onyx, but I think the separation is intentional and mostly comes from security and lifecycle boundaries.

The way I would think about it is:

1. RAG connectors are ingestion pipelines
   They crawl a source, normalize documents, sync permissions, chunk/index content, and keep that index fresh over time. For Google Drive, this usually means read/search/list scopes, scheduled sync jobs, ACL mapping, deletion handling, and retrieval-time permission checks.

2. MCP/OpenAPI actions are runtime capabilities
   They are invoked by an agent during a conversation and may have side effects. Even when they use the same external provider, they need a different control plane: tool schema, auth at execution time, rate limits, approval/confirmation UX, error handling, auditability, and sometimes broader OAuth scopes.

3. One OAuth token is not always the same product permission
   A single Google Drive authentication sounds convenient, but "allow Onyx to index my Drive" and "allow an agent to act on my Drive" are different trust decisions. In enterprise setups, the first is often admin-managed or read-only, while the second may need user-delegated consent, narrower runtime policy, or explicit approval before writes.

So the fragmented model has a real product/security reason: it avoids turning a knowledge connector into an action permission by accident.

That said, I agree the UX could probably be unified without collapsing the backend boundaries. A good model would be:

• one visible "Google Drive integration" in the UI
• separate toggles/capabilities under it, for example:
  • use for search/RAG
  • expose read-only actions
  • expose write actions
• separate scopes and policy per capability
• shared auth only when the scopes and trust model are actually compatible

So I would not merge the concepts internally, but I would consider presenting them as one integration with multiple capability surfaces.

Did this resolve it? Feel free to mark as answer if so.