"Open core" is one of the most abused phrases in software. Plenty of vendors ship a hollow free tier, paywall anything anyone would actually run in production, and still call themselves open. So when Wegenty says the core is open and only the compliance layer is closed, you are right to ask: open how, closed why, and where exactly is the line? This post answers all three — for the engineer who wants to read the source before trusting the marketing.
The short version: everything that touches your knowledge and decides what a customer can see is open source. The one closed component is Cloud Shield, the compliance umbrella. Drawing the line there is not a compromise on openness — it is what makes the openness honest.
What is actually open
Wegenty is an open, governed AI core: one locally-hosted LLM serving many knowledge bases. Open in this context means you can read it, fork it, self-host it, and audit what it does on your own hardware.
The open surface, component by component
Concretely, the open surface includes:
- The retrieval and inference pipeline — how documents are chunked, indexed, embedded and served to the local model. No black box deciding what your assistant knows.
- The projection engine — the part that takes your internal knowledge base (the superset) and produces the governed public agent (a strict subset). This is the heart of the governance model, and it is open.
- The correction loop — when the agent is unsure it escalates to a human, and that human answer is captured back into the knowledge base. The mechanism that makes the assistant improve over time is inspectable.
- The widget — the embeddable public-facing agent your customers actually talk to.
- The admin console — where knowledge bases, sensitivity labels and per-base policy are managed.
- The safety-adapter SDK — the toolkit for caging third-party tools (declared permissions, no knowledge-base access by default, controlled egress).
If a component decides what your assistant knows, says, or escalates, it is open. That is the rule, and there is exactly one exception.
The one closed component — and why that is honest
The single closed piece is Cloud Shield: a compliance umbrella that maintains a live regulatory posture, an audit trail, and certification support under the DSGVO and the EU AI Act. It is closed because it is a continuously operated, certified service, not a static library you fork and forget. Regulatory posture is only meaningful if someone keeps it current as the law moves — and the law is moving fast. The EU AI Act has been in force since August 2024, GPAI obligations went live in August 2025, it becomes fully applicable on 2 August 2026, and some Annex III high-risk duties phase in through 2027. We cover that timeline in the EU AI Act guide for SMEs.
Here is why drawing the line at Cloud Shield is the opposite of open-washing. The closed component does not sit in the data path. It does not decide what your customer sees, it does not hold your knowledge base, and your agent answers perfectly well without it — that is exactly what the free Community tier is. Cloud Shield is an umbrella over a system that already works, not a gate you must pass through to make the system work. The usual open-core trick is to paywall the load-bearing parts. We did the reverse: the load-bearing parts are open, and the one paid, closed thing is a compliance service you can take or leave.
The test for honest open core is simple: can you run the real thing without the closed part? With Wegenty, yes — the closed part is a compliance umbrella, not a hostage.
The trust-boundary invariant
If you read one architectural idea before adopting this, make it this one. The governance model rests on a single invariant:
The internal knowledge base is the superset; the public agent is a governed projection of it — never the reverse.
Information flows one way. Internal knowledge can be projected outward into a public agent, filtered by sensitivity labels and per-base policy. But the public agent can never write back into, expand, or leak the internal base on its own. Everything is default-private; a customer only ever sees what a label and a policy have explicitly allowed to be projected. The correction loop is the one deliberate channel back — and it runs through a human, who reviews the escalated answer before it is captured into the knowledge base.
For an engineer, this is the property to verify in the open source. You are not trusting a promise that "we filter sensitive data." You are checking that the projection is structurally one-directional: that there is no code path by which the public widget reads an unlabelled internal document, and that the only write-back is the human-reviewed correction loop. The boundary is the product. We make the full argument in the product is governance.
Two transports, one connection artifact
Governance does not stop at your knowledge base — it extends to the tools the assistant can reach. Wegenty connects an assistant to an instance over two transports:
- REST + OpenAPI — for the vast world of services that already speak HTTP and describe themselves with an OpenAPI schema.
- MCP — the Model Context Protocol, for tools built to the emerging standard.
Both are wrapped in the same governance discipline. Third-party tools are caged by safety adapters: they carry declared permissions, get no knowledge-base access by default, and have controlled egress. The pairing itself is deliberately boring to deploy — a single connection artifact, one droppable file that pairs an assistant to an instance over either transport. No bespoke integration project. (A gated marketplace for vetted adapters comes later; the SDK to build them is open now.)
From self-hoster to builder: the Community path
The free Community tier is self-hosted, no Cloud Shield, and it is the real product — not a crippled demo. You download the open core, run it on your own metal, point it at your own knowledge base, and get a governed, sovereign assistant with the projection engine and correction loop intact. The model stays local. The data never leaves the building.
From validating to delivering
That is also a path, not a dead end. The same people who validate the open core by running it are exactly the people who go on to deliver it — a local consultant who installs the open stack on a customer's servers under the Self-managed shape, or who builds a safety adapter for a tool their clients need. Distribution runs through a network of local consultants who own the customer relationship and earn a recurring share. If you are a builder evaluating the core, the consultant programme is where the open source turns into a business. When you do want the compliance umbrella and a supported deployment, the pricing page lays out Professional and Enterprise.
Anti-lock-in, on purpose
Open core only means something if leaving is realistic. Because the model is local and the core is open, you are never holding a vendor's data hostage and you are never holding a vendor's source hostage either. Self-host on your own servers, fork the projection engine, audit the data path, swap the deployment shape — the leverage stays with you. The one closed component is a service you opt into for compliance, not a lock you opt out of with pain. That is exactly the contrast we draw against closed cloud assistants on the compare page. That is the whole point of staying honest about the line.
If you want the deeper map of what is open and how the pieces fit, the open-source overview is the place to start — and the platform page shows the governance flow end to end. When you are ready to see a governed agent answer on real knowledge with nothing leaving the building, try the live demo.