Two terminal agents was one too many
For most of this year we were building two terminal agents. AGTerm had a CLI and an orchestration layer of its own, and …
A Higher Bar Than Banking
European banks face a strict sovereignty requirement, driven by DORA, GDPR, and national banking regulators. The public sector faces something stricter still. Government agencies, defense ministries, intelligence services, and operators of national critical infrastructure cannot rely on the same architectures that satisfy private-sector compliance. The bar is operational sovereignty: the ability to keep running, with full audit trail, even under hostile conditions where commercial cloud providers may be unable or unwilling to operate normally.
For EU public sector AI procurement in 2026, the questions a vendor must answer have shifted from “where is the data hosted” to “can this run when the US-headquartered providers turn off.” That second question is harder. The architectural response is more structured. The capability gap between vendors who can credibly answer it and vendors who cannot is wider than for any other regulated sector.
This piece is about the specific shape of EU public-sector sovereignty requirements, why open-weights models running inside fully-controlled infrastructure are the operational ceiling, and how the Calliope + Mistral architecture composes with sovereign substrates for the highest-bar workloads.
The Three Bars
┌──────────────────────────────────────────────────────────────┐
│ │
│ EU PUBLIC-SECTOR SOVEREIGNTY BARS │
│ │
│ Bar A — Standard government │
│ ────────────────────────── │
│ Civil service, non-classified workflows. │
│ Comparable to a regulated private-sector posture. │
│ GDPR + national data protection laws. │
│ EU-hosted infrastructure + EU-domiciled providers │
│ sufficient. │
│ │
│ Bar B — Sensitive government │
│ ─────────────────────────── │
│ Tax, social services, judicial, immigration. │
│ Categories of "sensitive personal data" under GDPR. │
│ Sovereign-cloud substrate or on-prem typically required. │
│ Operator-jurisdiction must be EU. │
│ │
│ Bar C — Classified / defense │
│ ──────────────────────────── │
│ Defense ministries, intelligence services, certain │
│ critical infrastructure operators. │
│ On-prem or air-gapped only. │
│ No external dependencies for ongoing operation. │
│ Often national-classification levels above standard EU │
│ commercial classifications. │
│ │
└──────────────────────────────────────────────────────────────┘
A given public-sector entity may operate across multiple bars simultaneously — a ministry might run civilian-services workloads at Bar A, citizen-data workloads at Bar B, and a few specific workloads at Bar C. The architecture has to support all three, with the routing decided per workload, not per organization.
The hardest of the three is Bar C. For workloads that genuinely cannot tolerate external dependencies, the model itself must run inside the perimeter. Mistral’s open-weights tier — Mistral, Mixtral, Codestral — running on customer-controlled compute is the only category of foundation-model capability that satisfies Bar C without compromise. US-headquartered proprietary models cannot satisfy Bar C under any commercial arrangement, because the model weights are not portable to the customer’s infrastructure.
What Public-Sector Procurement Specifically Asks For
┌──────────────────────────────────────────────────────────────┐
│ │
│ Procurement question Architectural answer │
│ ──────────────────────── ────────────────────────── │
│ │
│ "Where is the data?" Customer's EU cloud or │
│ sovereign cloud or on-prem │
│ │
│ "Where are the models?" EU-hosted (Mistral SA) or │
│ inside the customer perimeter │
│ │
│ "Who operates the platform?" Customer's own staff + │
│ EU-domiciled support; no │
│ US-jurisdiction operators in │
│ the runtime path │
│ │
│ "Can you operate if the US Yes — open-weights inside │
│ providers go offline?" the perimeter; runtime on │
│ substrate the customer │
│ controls │
│ │
│ "Show us the audit trail." Tamper-evident chain in │
│ customer's own audit systems │
│ │
│ "Show us the exit strategy." Already running (the │
│ open-weights tier is the │
│ exit destination) │
│ │
│ "Show us the source code." Open components are visible; │
│ commercial components have │
│ source-code-escrow │
│ arrangements where required │
│ │
└──────────────────────────────────────────────────────────────┘
The “source code” question is one many public-sector procurement teams ask but commercial vendors often cannot answer satisfactorily. For EU public sector, escrow arrangements (a neutral third party holds source code, released to the customer on defined trigger events) are routine for critical software. The architecture has to accommodate this; commercial vendors that cannot offer escrow do not pass procurement.
The Calliope stack accommodates all of these questions cleanly because the runtime is BYOC, the most sensitive workloads use open-weights models inside the perimeter, the governance layer is operated by the customer, and the commercial components can be wrapped in standard public-sector contracting frameworks including escrow.
The Reference Architecture for a Ministry
A representative architecture for an EU ministry running workloads across Bars A, B, and C simultaneously:
┌──────────────────────────────────────────────────────────────┐
│ │
│ MINISTRY — MULTI-BAR SOVEREIGN AI ARCHITECTURE │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Bar A workloads (civil service) │ │
│ │ Substrate: EU region of public cloud │ │
│ │ Models: Mistral commercial EU endpoint │ │
│ │ Governance: Zentinelle in same EU region │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Bar B workloads (sensitive personal data) │ │
│ │ Substrate: Sovereign cloud (Bleu / S3NS / nat'l) │ │
│ │ Models: Open-weights Mistral inside the perimeter │ │
│ │ Governance: Zentinelle on sovereign substrate │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Bar C workloads (classified) │ │
│ │ Substrate: On-prem private cloud, optionally │ │
│ │ air-gapped │ │
│ │ Models: Open-weights only, fully local │ │
│ │ Governance: Zentinelle on private cloud, │ │
│ │ audit trail inside the air gap │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ All three bars: same workbench UX, same operator surface, │
│ same policy framework. Substrate flexes per bar. │
│ │
└──────────────────────────────────────────────────────────────┘
A ministry employee whose role spans multiple bars has one workbench experience. The substrate underneath changes as the data class changes. The policy gateway enforces the residency rule per request, not per session. An employee working on a Bar A task can shift to a Bar B task without changing tools; the routing changes underneath.
This is the architecture pattern that has emerged through real EU public-sector deployments. It is not theoretical; it is the operational shape that works.
What Makes Bar C Actually Work
The Bar C case — fully-local inference, no external dependencies — is where the architecture proves it can handle the hardest version of the requirement.
Three operational properties are necessary:
The model weights are portable and stable. Open-weights Mistral and Mixtral families are released with clear licensing for commercial and government use. The customer can stage the weights into the air-gapped environment and operate indefinitely.
The runtime tooling does not require ongoing connectivity. Astrolift’s vanilla-Kubernetes provider supports fully-disconnected installations. The runtime control plane is self-contained. Updates can be staged through controlled gateways.
The governance and audit layer is fully internal. Zentinelle, deployed inside the air gap, produces the same audit chain available outside the air gap. Compliance evidence is queryable by internal audit; no external dependency.
For the hardest defense and intelligence workloads, this is the minimum viable architecture. The vendor must be able to ship and operate inside the air gap. Many cannot. Few can do so while still offering a coherent multi-bar architecture that the same ministry can use for its less-sensitive workloads.
The Workloads That Show Up
Specific AI workloads that EU public-sector entities run in 2026, with sovereignty class:
┌──────────────────────────────────────────────────────────────┐
│ │
│ Workload Typical Bar │
│ ─────────────────────── ───────────── │
│ │
│ Citizen-services chatbot A (civil service) │
│ │
│ Document translation / A or B (depending │
│ summarization (public docs) on document class) │
│ │
│ Tax-form processing B (sensitive personal │
│ assistance data) │
│ │
│ Social-services case B (sensitive personal │
│ summary drafting data) │
│ │
│ Court-filing assistance B (judicial data) │
│ │
│ Immigration-case B (immigration data; │
│ analysis often higher than B) │
│ │
│ Defense intelligence C (classified) │
│ summarization │
│ │
│ Defense logistics C (classified or │
│ optimization restricted) │
│ │
│ Critical-infrastructure Often C; varies by │
│ operations analysis sector and operator │
│ │
└──────────────────────────────────────────────────────────────┘
The distribution is roughly: 40–60% Bar A, 30–50% Bar B, 5–15% Bar C in a typical ministry. The Bar C workloads are few but they are the ones that determine whether the architecture can support the organization at all. A platform that cannot do Bar C is not a candidate for public-sector procurement.
The Compliance Walkthrough
When an EU public-sector compliance officer or auditor walks through the platform, the questions they ask map to specific properties of the architecture:
"Where is the data right now, by class?"
── Query against the runtime's data-flow audit chain.
"Show me every cross-border data flow in the last quarter."
── Query against the policy gateway's routing decisions.
"Show me every model call with classified data in the prompt."
── Query against the audit chain with the classification tag.
"Show me the lawful basis for each cross-border transfer."
── Query against the per-request audit, plus the linked
DPA / inter-administration agreement.
"Show me the exit strategy for the commercial AI provider."
── Show the open-weights model running in production for
the most-sensitive workloads; the commercial relationship
is exit-able by configuration change.
"Show me the access record for every privileged action."
── Query against the bastion-replacement session log.
"Show me the records of processing activity required
under GDPR Article 30."
── Continuous output of the platform; per-application
records auto-maintained.
Each question is a query, not a project. This is the property that makes the architecture defensible at examination — and it is what differentiates this from “we logged it somewhere” answers that procurement teams have learned to distrust.
Where to Go Next
- The sovereign-AI horizontal piece — the architectural argument.
- The European banking variant — for adjacent regulatory context.
- Astrolift — BYOC runtime including vanilla-Kubernetes for air-gapped installs.
- Zentinelle.ai — governance and audit, deployable across all sovereignty bars.
- AI for Government and Defense: Sovereign AI Infrastructure — the broader public-sector pitch.
- calliope.ai/contact — for a public-sector procurement conversation.
