Most platform comparisons start with licensing cost. That is the wrong place to start — license fees are often the smallest number in a three-year budget.
The real split between open-source and proprietary AI agent platforms shows up in three places that vendor pricing pages never mention: who owns the infrastructure your customer data flows through, who controls the upgrade path when the platform pivots, and how much internal engineering capacity you need to operate each option. For Swiss and EU companies, a fourth dimension compounds all three: data residency rules that make some proprietary platforms operationally difficult regardless of their features.
This article models that full picture. The goal is a decision framework you can apply to your specific situation — not a recommendation that pretends every company has the same risk profile.
What “Open-Source” and “Proprietary” Actually Mean for Agent Platforms
The labels are murkier than they seem. Frameworks like LangGraph and CrewAI publish their core code under permissive MIT licenses. You can read the source, host it yourself, and modify it without paying anyone. That is genuine openness. n8n takes a different path: it uses a “fair-code” Sustainable Use License that restricts commercial redistribution and embedding without a paid enterprise agreement — it is source-available rather than open source in the OSI sense.
Proprietary platforms — Microsoft Copilot Studio, Salesforce Agentforce, ServiceNow AI Agents, and several startup-category tools — provide managed infrastructure, pre-built connectors, and an SLA in exchange for a subscription. The agent runtime runs in their cloud; you configure rather than build.
A third category complicates the picture: open-weight model providers (Mistral, Meta’s Llama family) paired with a managed hosting layer. You get the model weights under a source-available or custom licence — Mistral’s models use Apache 2.0 (genuinely permissive), while Meta’s Llama family uses a custom community licence that the Open Source Initiative does not recognise as open source and which includes restrictions for EU users — but you are still running on someone else’s compute unless you self-host. For the purposes of this comparison, we treat “proprietary” as any arrangement where the runtime and data pipeline sit in a vendor’s cloud under their terms of service.
The 3-Year TCO Model: Where the Numbers Actually Diverge
A mid-sized firm deploying its first serious agent — let’s say an operations team of 50 people, running three automated workflows handling a combined 2,000 tasks per month — faces a cost structure that looks roughly like this:
Proprietary platform path
Year 1 costs are low and predictable. Costs vary significantly by platform and usage pattern — Microsoft Copilot Studio can start below CHF 200/month for light credit usage (sitting atop mandatory M365 base licences), while Salesforce Agentforce at per-user rates can exceed CHF 3,000/month for even a small team. A rough SMB starting range across the major platforms is CHF 300–2,000/month for moderate agent usage, excluding base platform licences; verify current rates on vendor pricing pages before budgeting, as these change frequently. Implementation time is measured in weeks rather than months. The platform handles hosting, scaling, monitoring, and model version management, and total Year 1 outlay including setup typically falls between CHF 20,000–50,000 depending on integration complexity.
By Year 3, the picture changes. Usage-based fees compound as you expand to more workflows. Proprietary platforms also tend to reprice at renewal when they have sufficient lock-in. More significantly: if the platform changes its agent execution model, deprecates an API, or gets acquired, your workflows may require expensive rework with no code you can fork.
Open-source framework path
Year 1 costs are front-loaded with engineering. A realistic timeline to get a production-ready agentic workflow on LangGraph or CrewAI — including infrastructure setup, observability tooling, LLM API integration, and internal testing — is 2–4 months of developer time for a team without prior experience on the framework. At current Swiss contractor rates of CHF 100–200/hour (market benchmarks, mid-2026), that represents CHF 40,000–120,000 before the first workflow goes live.
By Year 3, the calculus inverts. Infrastructure costs on a self-hosted stack are largely fixed. There are no per-seat or per-execution fees beyond your LLM API costs and compute. Critically, you own the code: migration to a different LLM provider, addition of a new tool integration, or architectural changes can all be made without a vendor conversation.
The crossover point for a typical SMB sits somewhere between 18 and 30 months — after which the open-source path tends to be cheaper on a pure cash basis, assuming you have the engineering capacity to operate it.
Data Residency: Why This Changes the Calculus for Swiss and EU Buyers
This is where the comparison shifts from financial to existential for many Swiss companies.
The nFADP (Switzerland’s revised Federal Act on Data Protection) and GDPR both impose obligations on where personal data is processed and who can access it. Many proprietary agent platforms process data — including conversation transcripts, document contents, and workflow outputs — on infrastructure that may route through US-based servers, subject to US cloud provider terms and potentially US government data access provisions.
The practical risk: if your agent handles employee records, client communications, financial data, or health-adjacent information, you may be in a difficult position trying to demonstrate adequate data protection if that data transits a US-managed proprietary platform. Some platforms offer EU-region deployments; a smaller number offer genuine EU-only processing guarantees. Fewer still can accommodate Swiss-specific requirements under the nFADP.
Open-source frameworks, deployed on Swiss or EU infrastructure (a domestic cloud provider, an on-premises server, or a Tier-1 EU region with appropriate DPA terms), give you the cleanest story to auditors and to your own data protection officer. That simplicity has real value — not just in compliance overhead avoided, but in the fact that you can actually demonstrate the data flows rather than relying on a vendor’s attestation.
See also: AI Agents and GDPR: Deploying Automation You Can Defend and AI Agent Governance: A Practical Playbook for SMEs.
Lock-In Beyond the Contract: Three Risks Proprietary Buyers Under-Price
The concept of AI agent platform lock-in goes deeper than most buyers anticipate when signing up.
Workflow logic lock-in. Most proprietary platforms use a visual or declarative workflow format that is not portable. If you build 40 automations on Platform A and want to move to Platform B — or to a custom stack — you are rebuilding from scratch. The sunk cost of that logic is real.
Model binding. Many proprietary platforms restrict which models you can use. Salesforce Agentforce now offers a bring-your-own-LLM option supporting Bedrock, Azure OpenAI, and Google Vertex AI, and Microsoft Copilot Studio supports custom Azure OpenAI connections — but both still constrain you to pre-approved provider lists and charge platform fees regardless of which model you use. Startup-category proprietary tools typically impose tighter restrictions. Open-source frameworks are generally model-agnostic.
Observability opacity. When an agent behaves unexpectedly on a proprietary platform, your debugging surface is limited to what the vendor exposes in their logs and trace tools. On an open-source stack, you instrument exactly what you need — and you own that telemetry data.
Internal Skills: The Honest Prerequisite Check
Open-source does not mean “free in terms of human cost.” The frameworks that give you the most control — LangGraph’s stateful graph model, for example — have meaningful learning curves. Operating a production agent stack requires skills in:
- Python or TypeScript (framework-dependent)
- LLM API integration and prompt engineering
- Container orchestration (Docker at minimum, Kubernetes if scale demands it)
- Observability tooling (logging, tracing, alerting)
- Security hardening for agent tool access
If your team has none of these, the Year 1 cost estimate above understates reality significantly. The gap is either hired, contracted, or bridged by a specialist partner — but it exists and needs to be priced.
Proprietary platforms lower this bar substantially. A technically competent operations person — not a software engineer — can build and maintain meaningful automations on a well-designed managed platform. That is a genuine advantage, not marketing spin.
Who Should Choose What
Open-source is the stronger choice when:
- Data residency requirements are strict and you need an auditable data-flow story
- You expect the agent footprint to grow significantly over 2–3 years (TCO advantage compounds)
- You have or can hire engineering capacity to operate the stack
- You need model flexibility or custom tool integrations beyond what managed platforms expose
- You are building a product or service on top of agents (IP ownership matters)
Proprietary is the stronger choice when:
- Speed to first working automation matters more than long-term flexibility
- Your use case fits cleanly in the platform’s pre-built connector library
- You lack the engineering bandwidth to operate and maintain infrastructure
- The workflows you’re automating don’t involve sensitive personal data — or your platform of choice offers credible EU/CH-only processing
Hybrid paths exist. Some organisations run proprietary platforms for low-sensitivity, low-complexity automations — internal scheduling, non-PII document routing — while keeping a self-hosted open-source stack for anything that touches regulated data. This adds operational complexity but distributes risk sensibly.
For a broader framing of the build-versus-buy dimension, see Build vs Buy: A Decision Framework for AI Agents.
Where a Partner Changes the Equation
The open-source TCO advantage is real, but it depends on that Year 1 engineering investment landing correctly. A bad architecture decision at the start — the wrong framework for your use case, an inadequate observability setup, a data model that doesn’t account for future scale — erases the advantage quickly.
Working with a specialist who has built and operated open-source agent stacks in production before means you are not paying for someone’s learning curve. You are paying for a pattern that already works, applied to your specific workflows and data environment.
That is precisely the work we do at Orange ITS. Our AI agent development practice is framework-agnostic: we pick the right tool for the client’s technical maturity, regulatory context, and growth trajectory — which sometimes means recommending a managed platform, and sometimes means building on open-source. We have no vendor incentive to push either path.
Ready to Map This to Your Situation?
The framework above narrows the decision space, but the right answer still depends on your specific workflows, your data classification, your team’s technical profile, and your growth plans.
A 30-minute call with our team is enough to tell you which path fits — and to estimate the real 3-year cost for your scenario rather than a generic model. Get in touch with Orange ITS to book that conversation.