The topic of AI Sovereignty is now ubiquitous (delivered to the masses via CNBC and available to the terminally online via a wave of CEO essays and quote-tweets).
At deepset, we worked on sovereign AI even before we knew that term exists. From day one, our mission has been to help organizations build and run AI on their own terms, without being locked into a vendor, model, or stack.
Often, the discourse reduces sovereignty to deployment: where models are hosted and whose infrastructure sits underneath. Necessary considerations, but incomplete. Every agent runs inside a harness: the loop, tools, memory, context, and controls that turn a model call into a system. If you cannot understand or leave that harness, moving it into a more secure environment does not make it yours.
Sovereignty needs to be a property of the architecture itself.
Your most valuable asset is what accumulates around the model
Run an agent system in production for six months and see what has accumulated around it: instructions that encode how your team thinks and works. Skills refined against expert judgment. Tests and evaluations that decide whether output is good enough to ship. Corrections built from feedback only your people could give. Workflows, memories, and conventions that reflect how the organization operates.
Together, these form institutional intelligence. The model is replaceable; this is not. Thus, a second question emerges alongside deployment: not where the model runs, but what form this intelligence should take.
Decagon CEO Jesse Zhang summarizes the emerging answer well: in artifacts that models use in context, not in model weights. Artifacts can be inspected, updated, and deleted, and they survive a model swap.
But in our view, moving knowledge outside the model does not automatically make it sovereign. If that intelligence lives in artifacts, the third question is who controls the artifacts?
A skill you cannot read, running inside a loop you cannot audit, on infrastructure you cannot leave, does not eliminate lock-in. It moves the dependency from the model weights to the harness around them.
All three questions end at the same place, and it is what Haystack 3.0 delivers: control over the knowledge an agent uses, the logic that governs its actions, the environment it runs in, and the evidence by which its performance can be understood. It adds modular skills, agent hooks, and deeper introspection to two principles Haystack has been built on for years: model independence and open-source control.
The Haystack foundation
The stack outlives any model. In Haystack, models are components in a broader system. Pipelines and agent logic are provider-agnostic. Swap the model for price, capability, or jurisdiction, and everything you built comes with you.
The framework remains under your control. Haystack is open source: modify the code, extend its components, and operate in your environment of choice. That openness means the harness you build does not expire with a vendor license, disappear behind a proprietary service or change behavior opaquely with the next update. That’s why highly regulated institutions like the European Commission and Bosch trust Haystack in production.
What Haystack 3.0 adds
Skills turn knowledge into artifacts. A skill is a folder of files inside your boundary: read, version, share or delete them. In Haystack 3.0, agents discover skills at runtime through progressive disclosure – a skill's name and description first, the full content only when the task requires it – instead of one large system prompt carrying every instruction.
Skills do not capture every form of enterprise knowledge. Data, memory, evaluations, traces, and feedback each have different requirements. But they make one critical layer portable: the instructions that tell an agent how the organization wants work done.
Hooks make the agent loop programmable. Teams can insert their own logic at specific points: at the start or end of a run, before each model call, around tool execution, and on exit.
That control supports the production patterns enterprises need: screening sensitive data before it reaches a model, assembling the right context before work begins, compacting it when it grows too large, and requiring approval before a high-impact tool fires.
It also makes cost a design decision. Teams can use live token and step counts to trigger compaction, limit runaway loops, or change behavior as a run approaches a defined budget.
Introspection shows what happened. Haystack 3.0 exposes token usage, step count, and tool-call counts as built-in state during a run. Updated tracing emits step-level spans tagged with the tools each step used. When an agent produces an unexpected result, you see exactly what it did and in what order, instead of reconstructing the run from scattered logs.
Three additional enhancements make the framework easier to test and audit:
- Built-in mock generators and embedders let teams develop and test agents without external API calls, variable provider responses, or per-test usage costs.
- A leaner core moves legacy components and selected integrations into separate packages. The default installation has fewer dependencies, while integrations can release fixes independently of the core framework.
- YAML deserialization is hardened through a trusted-module allowlist. A pipeline definition can only load classes from modules the organization has explicitly allowed, reducing the risk of loading untrusted code through shared configuration files.
Build with Haystack 3.0
Every agent has a harness. Sovereignty is deciding who controls yours. A loop you can read, context you can keep, a model you can replace. That is what Haystack 3.0 is built for. Install it, read the migration guide, and start building.
pip install haystack-ai · [Haystack blog] · [migration guide] · [documentation]
