> Quelle: https://souverana.ch/en/insights/souveraene-ki-integration/
> Sprache: en

# Sovereign AI integration: when AI starts to act

The moment an agent acts instead of merely reading, a mistake becomes an incident. Integration is where your IP is built and where you have to keep control. How that works.

Integration · Published 12 Jul 2026 · Updated 24 Aug 2026 · Joel Barmettler

## What integration means in AI

**The moment AI acts in your systems instead of merely reading, a mistake becomes an incident. That is exactly what happens at the integration layer: here agents are connected to your business software and triggered from your own applications. It is the first layer where AI writes, and the layer where your most valuable own knowledge is built. Acting demands approval; knowledge demands portability.**

**In brief**

-   As long as an agent reads, a mistake is annoying. The moment it writes, it becomes an incident. Acting therefore needs approval, transparency and an audit log.
-   This is where your money and your IP are built. Build it for portability: logic in MCP? servers that you own and can take to any provider.
-   The code of modern agents is often portable; the runtime environment and the graphical no-code interfaces usually are not. Check what of your own effort actually belongs to you.
-   Trust in an agent comes from transparency and control. You cannot demand that of a black box.

The parts before this one dealt with data at rest: the model, its preparation, the platform. Integration is different. Here AI starts to act in your world. That acting runs as a loop.

An agentic loop: the language model reasons, calls a tool via MCP, observes the result and reasons again until it answers. Two control points are marked: the approval gate before write actions, and the audit log that records every step.

An agentic? process is not a single answer but a loop: reason, act, observe, reason again. Each round can call a tool and thereby cause something to happen in your systems. This is exactly where it is decided whether the AI becomes a useful colleague or a risk, and exactly where the largest share of your investment sits.

This is the last part of our series on sovereign AI, and it covers the layer with the biggest impact and the biggest risk.

Series · Sovereign AI

1.  1[What sovereign AI actually means for Swiss companies](/en/insights/was-ist-souveraene-ki/)
2.  2[AI strategy for SMEs: the questions to answer first](/en/insights/ki-strategie-kmu/)
3.  3[Sovereign AI infrastructure: why the model is the easy part](/en/insights/souveraene-ki-infrastruktur/)
4.  4[Sovereign AI platform: why it binds more than the model](/en/insights/souveraene-ki-plattform/)
5.  5Sovereign AI integration: when AI starts to actYou are reading this part

## Building it yourself: the stages, and the question of portability

Almost every platform lets you create simple agents without code: write a prompt, upload files as knowledge, attach a few tools. That is the basic kit, and it is enough for a great deal. Whoever wants more needs their own logic in code, meaning an SDK, and above all the ability to feed that logic back into the platform so that it runs there with the platform’s own permissions and knowledge.

Portability deserves a precise distinction here, because marketing misleads on this point. The large providers have open-sourced their agent SDKs: the code you write is often portable. What stays bound is the runtime environment it runs on, including login, knowledge connections and orchestration. Least portable of all are the graphical no-code interfaces. OpenAI discontinued its Agent Builder, launched only in 2025, a few months later, and by OpenAI’s own account the export does not fully carry over the flow. What you click together there never durably belongs to you.

At the other end stand the open platforms. In Open WebUI you write your own logic directly into the running platform using Pipelines and Functions, with almost no limits, self-hosted and in your own possession. Between the two ends sits Mistral, the one proprietary provider whose runtime can run on your own infrastructure, a sensible middle path for European requirements.

## Start with the MCP servers

There is a sequence that saves a great deal of lock-in. Start with the MCP servers, not with your own agents. An MCP server connects an agent to one of your systems through an open standard, and it is vendor- independent: build it once and you can attach it to any compatible platform and take it with you. Whoever can build their own agents can build MCP themselves anyway, and a simple server is a matter of days. Doing the integration work at this layer turns the connection to your systems into portable IP that you own. The platform above it becomes interchangeable.

There are two things worth knowing here. First, “supports MCP” is not a clear statement. The standard has three building blocks (tools, resources and prompts), yet almost every platform supports only the tools. So ask which building blocks a platform actually handles, and whether it allows arbitrary servers of your own or only ones from its marketplace. Second, there is the reverse direction: your own software, your mail system, your CRM should be able to trigger the agents. For that, a good platform exposes the agents as a secured interface that respects your access rules. For collaboration across system boundaries, a dedicated open standard called A2A (Agent-to-Agent) is currently emerging.

## Why lock-in hits hardest here

Lock-in hits hardest here because this layer is where most of the money and the most valuable IP are built. Whoever puts hundreds of thousands into their own agent tied to a proprietary platform faces a choice at every price rise: pay the higher price or write off the entire investment. That makes switching uneconomical. Developing your own agents inside vendor-bound environments is considered the largest hidden driver of switching costs.

The answer to this is a question of architecture. Put the valuable logic where it belongs to you and stays portable: in your own MCP servers and, where possible, on an open platform that you operate yourself. If you use a proprietary platform, keep the platform’s own agent logic thin and push as much as possible onto servers you can take with you.

## When AI starts to act

Up to this point it has been about building. Now it is about the acting itself, and that is where the real risk lies. As long as an agent only reads, a hallucination is annoying. The moment it writes, into a database, into your mail, into your software, a mistake becomes an incident. The examples are real. An AI agent from Replit deleted a production database in 2025 during an explicit code freeze, fabricated data and claimed that recovery was impossible. Cursor’s support agent invented a company policy that did not exist, which led customers to cancel. And a manipulated public entry made an agent expose data from private projects through the GitHub MCP server. The researchers explicitly called that an architecture failure, not a coding bug.

The pattern is always the same: an agent that is allowed to act and is trusted blindly causes more damage than one that only makes suggestions. An agent can report a task as done without having solved it.

## Trust comes from transparency and control

Trust in an agent rests on two things a platform must provide. The first is control. Dangerous write actions are not executed immediately but are first put to a human for approval (the human-in-the-loop pattern), while harmless read actions pass through automatically. On top of that comes the principle of least privilege: an agent sees only the tools it needs for its task, and read tools are kept separate from write tools.

Human in the loop: write actions stop at the approval gate until a human confirms them. That keeps risky actions under human oversight without slowing down every harmless query.

The second is transparency. You want to see every step the agent takes: every thought, every tool call, every result. Open-source, self-hostable tools exist for exactly this, recording the whole process, plus a complete audit log that records what the agent did. That lets you reconstruct afterwards why something happened, and prove, in a serious incident, what happened.

The audit log records every pass through the loop. What matters for accountability is an unbroken trail of every step that led to the result.

## No surprises: you decide when things change

Control also means that the foundation does not shift under you unnoticed. On a proprietary platform, the provider can change the model or the environment without changing the interface, and with it the behaviour of your agents. One documented case shows that this really happens:

Key figure

up to 16% of requests

In September 2025, Anthropic disclosed that three infrastructure bugs degraded Claude's quality over weeks with no change to the interface at all. Detection took as long as it did partly because the company's own privacy rules restricted access to the affected requests.

Source: Anthropic, postmortem of 17 September 2025

Even the most careful provider can quietly change how its service behaves, and from the outside it is barely visible. With open, fixed model weights [that you operate yourself↗](/en/insights/llm-selbst-hosten/), you decide when something changes. A switch becomes a deliberate, testable decision against your own test cases, instead of a surprise in live operation.

## No trust for a black box

All of this presupposes one thing: you must be able to understand how the platform works. A black box cannot be trusted in the long run, least of all when it acts in your name. The GitHub case shows why: the vulnerability could only be fixed because the interaction was open and inspectable. An open, self-operated platform is auditable from the ground up; a proprietary one stays opaque.

That brings control back to the platform layer. Whoever wants to keep control over what their agents do needs a platform underneath that shows its inner workings. The transparency that is a convenience at the third layer becomes a precondition at the fourth.

## What this means for your company

Integration is the layer where your AI creates value and where it can cause damage. Treat both with the same care. Build your IP for portability, at the MCP layer, which belongs to you. And only give an agent free rein once you can see every one of its steps, approve dangerous actions and prove everything. At this layer, sovereignty means: nobody can take away your platform, your agents or your control over what they do.

Want to build your own agents and integrations that belong to you and stay under your control?

[AI Architecture & Solution Selection](/en/leistungen/ki-architektur/)

That completes the series: from the terms through strategy to the three layers of infrastructure, platform and integration.

The author

![Portrait of Joel Barmettler](/_astro/joel-barmettler.CGKHGWrV_sJ0IG.webp)

Joel Barmettler

AI Architect · Souverana, Zurich

Joel Barmettler guides Swiss companies from AI strategy to integration: sovereign, confidential and production-ready. He built the Swiss AI Hub as its architect and today co-owns its architecture; he personally leads every Souverana mandate. Mandates from one-person firms to Fortune 500 corporations.

[Book an intro call](https://meet.brevo.com/joel-barmettler/30-minute-meeting) [More about Souverana](/en/) [LinkedIn](https://www.linkedin.com/in/joel-barmettler-b9ab361b7)

## Frequently asked questions

What is the integration layer in AI?

The layer where AI connects to your systems and acts within them: your own agents and logic, the connection to your business software (usually via MCP servers), and triggering agents from your own applications. It is the first layer where AI writes rather than merely reads, and the layer where your most valuable IP is built.

What is an MCP server, and why does it matter for sovereignty?

An MCP server connects an AI agent to one of your systems through an open standard. It is vendor-independent: build it once and you can attach it to any compatible platform and take it with you. Whoever does the integration work at the MCP layer builds portable IP that they own and can move to another provider at any time.

How do you keep control over AI agents?

Through transparency and control: make every step the agent takes visible, require manual approval for dangerous write actions first (human in the loop), limit tools to the principle of least privilege, and keep a complete audit log. That requires a platform whose inner workings you can inspect, not a black box.

Why is the integration layer the biggest lock-in risk?

Because this is where most of the money and the most valuable IP are built: your own agents and integrations. Whoever invests hundreds of thousands in logic tied to a proprietary platform can no longer switch when prices rise. That is why you build for portability: logic in MCP servers that you own.

Should you build AI agents on a proprietary platform?

Only with caution. The code of modern agent SDKs is often portable; the runtime environment and the graphical no-code interfaces usually are not. On a proprietary platform, shift as much work as possible onto your own MCP servers, which you can migrate, rather than building deep logic into the platform itself.

LinkedIn

## Share this article

Ready-formatted graphics and a suggested post for your LinkedIn feed: download, copy, post.

![Four levels of portability for AI agents, from your own MCP servers through self-hosted open platforms and proprietary platforms on your own infrastructure to a graphical no-code interface.](/media/souveraene-ki-integration-en/infografik.png)

[Download infographic (PNG)](/media/souveraene-ki-integration-en/infografik.png)

Suggested post

Is your AI agent allowed to write in your systems, or only to read?

The difference is bigger than it sounds: the moment AI acts instead of merely reading, a mistake becomes an incident. In 2025, an agent from Replit deleted a production database during an explicit code freeze, and a manipulated public entry made an agent expose data from private projects through an MCP server. The researchers explicitly called that an architecture failure, not a coding bug.

The same layer is where your most expensive own IP is built, and with it the hardest lock-in. How portable it stays depends on where you build it: your own MCP servers travel with you anywhere. A graphical no-code interface travels nowhere, as OpenAI's Agent Builder showed: launched in 2025, discontinued a few months later.

Our conclusion: build the logic where it belongs to you, and only give an agent free rein once you can see every step, approve dangerous actions and prove what happened.

The article covers the agentic loop with its two control points, four real incidents as warning patterns, and eight control questions for your own agents. Link in the comments.

#AI #MCP #AIAgents #DataSovereignty