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 …
When Operational Reliability Is the Regulation
Most regulated industries have a data-protection focus: customer information, trade secrets, financial records. Critical infrastructure has something different — the regulation is about the system continuing to work. NIS2 in the EU. CIRCIA in the US. National-level resilience laws across G20 countries. The compliance bar for an energy utility, a water authority, a transit operator, or a telecommunications carrier is not “did the data stay private.” It is “did the lights stay on, did the water flow, did the trains run, did the network deliver.”
This shifts the architectural conversation for AI adoption in critical infrastructure in two specific ways:
First, the operational continuity bar is higher than the data-protection bar. An AI tool that occasionally leaks an email is bad. An AI tool that occasionally takes down a grid operation is catastrophic. The threshold for “acceptable failure mode” in critical infrastructure AI is much lower than in office-IT AI.
Second, the regulator’s interest in administrative actions is much higher. NIS2 explicitly requires logging of privileged access to in-scope systems, with reporting timelines for incidents. CIRCIA imposes 72-hour breach reporting in the US. The regulator wants to know what your sysadmins (human and agent) did, when, why, and with what authorization. The audit posture has to support this on demand.
This piece is about how governed-agent system administration lands specifically in critical-infrastructure environments, what NIS2 and adjacent regulations actually require, and how the architecture composes for energy, water, and utility operators.
The Regulatory Frame
┌──────────────────────────────────────────────────────────────┐
│ │
│ NIS2 — applies to "essential" and "important" entities │
│ ────────────────────────────────────────────────── │
│ Energy, transport, banking, financial market │
│ infrastructure, health, drinking water, wastewater, │
│ digital infrastructure, public administration, space, │
│ postal, waste management, chemicals, food, manufacturing. │
│ │
│ Key obligations: │
│ • Risk management measures (Art. 21) │
│ • Incident reporting (Art. 23) — within 24h initial, │
│ 72h full notification │
│ • Audit of cybersecurity practices │
│ • Supply-chain security (third-party risk) │
│ • Senior-management accountability │
│ │
│ National-level critical infrastructure laws overlay │
│ NIS2 with sector-specific requirements (e.g., France's │
│ LPM, Germany's KRITIS, equivalents in other member │
│ states). │
│ │
└──────────────────────────────────────────────────────────────┘
For US critical infrastructure operators, the equivalent frame includes CIRCIA (incident reporting), the various sector-specific regulations (FERC/NERC for bulk electric, EPA for water, TSA for pipelines and transit), plus state-level requirements that vary widely.
The common thread: privileged access to operational technology is the highest-scrutiny activity, and any change to OT systems must be auditable in a way that satisfies regulator examination.
The OT/IT Divide
Critical infrastructure operates two distinct technology stacks: operational technology (OT) and information technology (IT). The distinction matters for AI architecture:
┌──────────────────────────────────────────────────────────────┐
│ │
│ IT (corporate) OT (operational) │
│ ───────────────── ───────────────── │
│ Email, ERP, HR SCADA, DCS, PLCs │
│ Office productivity Sensor networks │
│ Customer-facing systems Plant control systems │
│ Standard cybersecurity Specialized cybersecurity │
│ Patching: scheduled Patching: extremely careful │
│ Failures: business impact Failures: physical impact │
│ │
└──────────────────────────────────────────────────────────────┘
AI workloads land first in IT for almost every critical-infrastructure operator: customer-service summarization, regulatory-filing drafting, internal-documentation generation. The IT footprint of AI is straightforward; the governance question is the same as for any regulated industry.
OT is where the architecture has to think harder. AI workloads that interact with OT systems — fault-pattern detection, predictive maintenance, anomaly classification — must be governed at a higher bar. Even read-only access to OT requires careful policy. Write access (configuration changes, control commands) requires multi-party approval, segregation of duties, and audit trails that can survive examination by sector regulators.
The architectural separation matters: IT and OT AI workloads should run on different sides of a network boundary, with explicit, governed crossing points. They should not share a runtime instance, an identity model, or an audit destination beyond what is necessary for unified reporting.
What Governed-Agent SysAdmin Looks Like for OT
The horizontal secure-administration piece covers the general architecture. For OT specifically, the configuration is stricter:
┌──────────────────────────────────────────────────────────────┐
│ │
│ OT-SPECIFIC GOVERNED AGENT CONFIGURATION │
│ │
│ 1. Read-only by default │
│ Agents acting on OT systems start with read-only │
│ scope. Write actions require explicit, named │
│ authorization per action, not per workflow. │
│ │
│ 2. Two-party approval for write actions │
│ No single human can approve an OT write. Two human │
│ approvals required, with logged roles (operator + │
│ shift supervisor, or equivalent). │
│ │
│ 3. Local execution, no model-provider context │
│ The agent runs inside the OT perimeter. Inference │
│ calls use local open-weights models. No OT context │
│ data leaves the perimeter. Period. │
│ │
│ 4. Time-window controls │
│ Write actions only permitted during designated │
│ maintenance windows. Outside the window, all writes │
│ escalate to human-driven workflow. │
│ │
│ 5. Rollback as first-class action │
│ Every write action has a paired rollback. The │
│ rollback executes without re-approval if anomalies │
│ trip within a defined window. │
│ │
│ 6. Mandatory observation │
│ A human operator is present (in person or via the │
│ operator dashboard) for every write action. │
│ "Lights out automation" not used for OT in │
│ critical-infrastructure contexts. │
│ │
└──────────────────────────────────────────────────────────────┘
This is more restrictive than IT-side governed-agent admin. The restrictions are not arbitrary — they map to NIS2 Article 21 risk management obligations, to sector-specific cybersecurity frameworks (ENISA OT security guidelines, NIST 800-82 for industrial control systems), and to the institutional knowledge that OT incidents have physical consequences.
The IT/OT Architecture in the Calliope Stack
A two-zone architecture is the recurring pattern in 2026:
┌──────────────────────────────────────────────────────────────┐
│ │
│ ┌──────────────────────────────────────────────────┐ │
│ │ IT ZONE — corporate network │ │
│ │ │ │
│ │ Calliope Workbench (employees, contractors) │ │
│ │ Astrolift Runtime (internal apps) │ │
│ │ Zentinelle Gateway (IT policies) │ │
│ │ Model providers: Anthropic, OpenAI, Mistral, │ │
│ │ or local open-weights │ │
│ │ │ │
│ └──────────────────────┬───────────────────────────┘ │
│ │ │
│ │ Controlled crossing │
│ │ (data diode or strictly │
│ │ governed gateway) │
│ │ │
│ ┌──────────────────────┴───────────────────────────┐ │
│ │ OT ZONE — operational network │ │
│ │ │ │
│ │ Restricted workbench (OT operators only) │ │
│ │ Astrolift Runtime (OT-side, isolated) │ │
│ │ Zentinelle Gateway (OT policies, stricter) │ │
│ │ Model providers: LOCAL OPEN-WEIGHTS ONLY │ │
│ │ No external inference │ │
│ │ No connectivity to model providers │ │
│ │ │ │
│ └──────────────────────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────────┘
The OT zone runs its own Astrolift install, its own Zentinelle, and uses only open-weights models hosted locally. No model-provider connectivity. No data flow from OT to external providers. Cross-zone data movement uses controlled crossing points (a data diode for high-sensitivity OT, a strictly-governed gateway for less-sensitive OT).
This is the architecture pattern that satisfies NIS2 examination today. The components are not new — utilities have run two-zone networks for decades — but the AI overlay requires the same discipline, including (especially) the discipline of no external model calls from the OT zone, ever.
The Workloads That Land in OT
┌──────────────────────────────────────────────────────────────┐
│ │
│ OT-side AI workloads (with read-only or strict approval) │
│ ────────────────────────────────────────────────── │
│ │
│ • Anomaly detection in sensor streams │
│ • Predictive maintenance on plant equipment │
│ • Fault-tree analysis on alarm cascades │
│ • Capacity-planning analysis on historical data │
│ • SCADA log summarization for shift handover │
│ • Compliance-evidence collection for regulator queries │
│ │
│ OT workloads where AI is NOT used in 2026 │
│ ───────────────────────────────────────── │
│ │
│ • Direct control commands to OT systems │
│ • Autonomous decision-making on safety systems │
│ • Anything where a model hallucination could produce │
│ a physical-world consequence │
│ │
└──────────────────────────────────────────────────────────────┘
The first category is where governed agents earn their keep — read-heavy work that produces summaries, alerts, and suggested actions for human operators. The second category is the discipline most mature critical-infrastructure operators apply: AI assists but does not act on safety-critical systems autonomously.
The Specific Win for Critical Infrastructure
Beyond regulatory compliance, the most-cited operational win from governed-agent sysadmin in critical infrastructure is shift-handover quality. Operators rotating shifts in a 24/7 operation need accurate, complete situational awareness of what happened during the previous shift, what is in progress, what to watch for. Manually written handover reports are inconsistent in quality and timeliness.
A governed agent workflow that summarizes the last 8 hours of operational events — alarms, incidents, manual actions taken, status of in-progress workflows — into a structured handover document is dramatically valuable. It runs read-only against the OT zone, uses local inference, produces an output that the incoming shift operator reviews and the outgoing operator certifies, and audit-chains the whole process.
The same architecture supports:
- Regulator-query response (collect the evidence the regulator asked for, formatted in the expected schema).
- Internal-audit walkthroughs (gather the artifacts for a periodic review).
- Vendor-coordination updates (summarize the state for an external maintenance partner).
Each is a structured, governed, audit-trailed workflow. None of them puts an AI in the OT control loop. All of them reclaim significant shift-operator time.
The Compliance Walkthrough
NIS2 examination, in practice, focuses on a few specific areas where governed-agent administration produces evidence:
"Show me your privileged-access management for in-scope
systems."
── Browser-as-bastion session log; per-action audit trail.
"Show me your incident response process and a recent
example."
── Workflow runs with structured event records; the
most recent incident's full timeline.
"Show me how you manage supply-chain risk for ICT services."
── Vendor register; exit strategies; BYOC architecture
reducing third-party concentration.
"Show me senior-management accountability for cybersecurity."
── Approval records showing executive sign-off on high-risk
workflows.
"Show me your audit logging — what is recorded, where it
is stored, how long it is retained."
── Zentinelle audit chain configuration; retention policies;
tamper-evidence verification.
Each is a query, not a project. This is the recurring property: the architecture produces compliance evidence continuously, so examinations become walkthroughs rather than scrambles.
Where to Go Next
- The horizontal secure-administration piece — the architectural argument.
- Astrolift — multi-zone BYOC runtime including air-gappable OT-side installs.
- Zentinelle.ai — policy gateway with NIS2-aligned framework mappings.
- AI for Energy and Utilities: Critical Infrastructure Protected — the broader sector pitch.
- calliope.ai/contact — for a critical-infrastructure architecture conversation.
