# AI agents fail on data access: How Swiss SMEs become agent-ready

> Author: Chris Jon Graf (AI Strategist & CEO)
> Updated: 2026-09-14
> URL: https://ai-outsourcing.ch/insights/ai-agents-fail-on-data-access-how-swiss-smes-become-agent-ready

## Summary

AI agents rarely fail because of the model; they fail because they cannot access the right data. MCP reduces integration effort from O(N×M) to O(N+M). Swiss SMEs need three layers: MCP servers per system, a federated query layer, and identity-based permissions—otherwise agents remain chatbots.

## The real problem: Not the model, but access

Most SME AI-agent projects fail not because the model is weak, but because the agent cannot access the right data at the right time. Swiss SMEs typically run 3 to 8 core systems—ERP, CRM, DMS, HR, ticketing—each with its own API, permissions, and data format. The result is agent sprawl: many half-finished agents that see only a slice of the truth.

- Agents only access one system and give incomplete answers
- Permissions are configured manually per tool and drift apart
- Every new integration costs O(N×M) effort instead of O(N+M)

## MCP: A common standard for agent access

The Model Context Protocol (MCP) has emerged as the de facto standard. It connects AI agents to tools and data sources through a uniform protocol—described by SAS as a "USB-C port for AI." In December 2025, MCP was transferred to the Agentic AI Foundation under the Linux Foundation. The protocol now sees 97 million monthly SDK downloads.

> The Model Context Protocol is a USB-C port for AI.
>
> — SAS Model Context Protocol

For SMEs this means: instead of building N×M point-to-point integrations, one MCP layer per system is enough. An MCP server encapsulates access, exposes tools and resources in a controlled way, and aligns permissions. When connecting systems today, look for MCP compatibility.

**97M** — monthly MCP SDK downloads

**3–8** — typical core systems in Swiss SMEs

## Layer 1: MCP servers for each core system

Each core system gets its own MCP server. Microsoft SQL Server already includes one: the SQL MCP Server from DAB 1.7 exposes SQL operations as MCP tools with built-in RBAC. Monarch goes further: its Product Graph captures not only documented APIs but also undocumented endpoints, UI paths, permissions, and workflow rules—so agents can reliably access systems that were never designed for AI.

> **Governance warning**
>
> Raw SQL exposure is a governance problem. Giving agents direct database access risks uncontrolled queries. MCP tools with clear permissions are the safer path.

## Layer 2: Federated data layer or AI gateway

The second layer connects the MCP servers and keeps agents from getting stuck in data silos. Two patterns have proven useful: catalog-first governance and direct access. Databricks Agent Bricks rely on Unity Catalog and AI Gateway; ibl.ai connects SIS, LMS, CRM, HRIS, and ERP through an Integration Bus for real-time queries without data duplication. Oracle positions its AI Database for secure access to operational data.

1. Catalog-first: The agent only gets access to data released in the catalog
2. Direct access: The agent queries the source system via controlled MCP tools

## Layer 3: Identity-based access control

The best infrastructure is useless without clear permissions. MCP plugins like Kaman.ai rely on OAuth 2.0 fields to bind every access to an identity. Unity Catalog and AI Gateway provide end-to-end permissions. This also matters legally: the Swiss revised Data Protection Act (revDSG) requires clear data flows and traceability—a federated architecture with identity-based access fulfils this better than a central data lake.

## The Swiss path: data sovereignty as an architecture principle

Swiss SMEs have specific requirements: revDSG, data sovereignty, and often no large enterprise data platform. A federated data layer that leaves data where it resides fits better than a central data lake. Projects like [Apertus LLM from ETH Zurich](https://www.ki-podcast.ch/apertus-llm-eth-zuerich-digitale-souveraenitaet) show how confidential computing can protect sensitive data even during external processing.

> **Data protection as an architecture principle**
>
> When planning agent access, build privacy in from the start rather than retrofitting it.

## First step: inventory, not big bang

Agent-ready infrastructure does not appear overnight. The smartest first step is an honest inventory: Which core systems exist? Which APIs are available? Where do permissions live today? Then pilot one MCP server with a small use case. That foundation allows you to add more systems step by step without rebuilding the architecture.

1. Create an inventory of all core systems and APIs
2. Connect one pilot system with an MCP server
3. Couple identity provider and permission concept
4. Start with a clearly scoped use case

## FAQ

### What is the Model Context Protocol (MCP)?

MCP is an open standard that connects AI agents to tools and data sources via a uniform protocol. It reduces integration effort from O(N×M) to O(N+M) and is maintained by the Linux Foundation.

### Why do AI agents in SMEs often fail on data access?

Because core systems like ERP, CRM, and DMS have different APIs, permissions, and data formats. Without MCP servers or a federated data layer, agents see only fragments and deliver incomplete results.

### Does every system need its own MCP server?

Ideally, yes. One MCP server per system encapsulates access, provides tools and resources in a controlled way, and unifies permissions. That is the foundation for agent-ready infrastructure.

### How does this align with the Swiss revDSG?

The revDSG requires clear data flows and traceability. A federated architecture with identity-based access fulfils this better than a central data lake because data stays where it belongs.

### What is the difference between a data lake and a federated data layer?

A data lake copies data centrally, causing privacy and freshness problems. A federated layer queries data in real time at the source without duplication—better suited to the requirements of Swiss SMEs.

## Sources

- [From silos to insights: Federated data access patterns for AI agents](https://aws.amazon.com/blogs/big-data/from-silos-to-insights-federated-data-access-patterns-for-ai-agents/)
- [Agent Bricks: The Governed Enterprise Agent Platform](https://www.databricks.com/blog/agent-bricks-governed-enterprise-agent-platform)
- [Federated AI Data Layer](https://ibl.ai/resources/capabilities/federated-ai-data-layer)
- [Monarch: AI agents that operate your systems](https://www.monarchagents.ai/)
- [Oracle Unveils AI Database Agentic Innovations for Business Data](https://www.oracle.com/news/announcement/oracle-unveils-ai-database-agentic-innovations-for-business-data-2026-03-24/)
- [SQL MCP Server overview](https://learn.microsoft.com/en-us/azure/data-api-builder/mcp/overview)
- [Model Context Protocol: What it is and why it matters](https://www.sas.com/en_nz/insights/analytics/model-context-protocol.html)
- [The Model Context Protocol and Enterprise Tool Orchestration](https://ijcesen.com/index.php/ijcesen/article/view/5402)