Chapter 31 — The Sovereign Operating Model: Shift-Left Operations

Summary

This chapter argues that technical capabilities alone are insufficient without a corresponding transformation of the operating model, and presents the shift-left operations paradigm in which operational concerns — SLOs, observability instrumentation, policy-as-code evaluation, runbook authorship, and resilience testing — are addressed within the development lifecycle rather than deferred to downstream operations teams. It introduces new roles including sovereign zone owners, AI agent supervisors, policy engineers, and platform engineers, and defines a three-tier decision framework that clarifies which actions are automated, which require human approval, and which demand committee review. The chapter covers toil measurement with sovereignty-specific categories, the transformation of on-call practices when agents handle first response, and the skills atrophy risks that must be managed through game days and deliberate practice. Operating model effectiveness is measured through metrics spanning team cognitive load, toil percentage, automation coverage, sovereignty compliance rate, and continuous improvement cadence.

31.1 Why operating models must change

The preceding chapters of this book have described an expanding set of technical capabilities: topology-aware observability, zero-copy integration, policy-as-code guardrails, agentic automation with bounded autonomy, and agent-assisted incident management. Each of these capabilities represents a significant advance over the tooling that most enterprises relied upon a decade ago. Yet the organisations deploying them often discover, sometimes painfully, that the new technology sits uneasily within their existing organisational structures. The operating model—the combination of team structures, decision rights, processes, incentives and cultural norms through which an enterprise manages its technology estate—was designed for an earlier era. Attempting to run an agentic, sovereign, multi-cloud estate with the operating model of a traditional ITIL service desk is like fitting a modern turbofan engine to a biplane airframe: the power is there, but the structure cannot make productive use of it.

The traditional IT operating model that persists in most large enterprises was shaped by the ITIL service management framework in its various editions, by the NOC-centric monitoring paradigms of the 1990s and 2000s, and by organisational designs that drew sharp boundaries between development, operations, infrastructure, security and compliance [1]. In this model, development teams build software and hand it to operations teams who run it. Operations teams manage incidents, changes and problems through structured ITSM processes. Security teams audit periodically and issue findings. Compliance teams interpret regulations and produce policies that other teams are expected to follow. Infrastructure teams provision capacity on request. Each function has its own reporting line, its own tools, its own cadence and its own definition of success.

This functional separation was not irrational. It reflected genuine organisational concerns about segregation of duties, auditability and specialisation. But it created a set of structural problems that compound as estates grow in complexity and as regulatory obligations intensify. The most significant of these is the handoff tax: every boundary between teams creates a queue, a context loss and a delay. A development team that identifies a security vulnerability in a dependency must raise a ticket to the security team, wait for assessment, raise another ticket to the infrastructure team for a patching window, coordinate a change with the operations team, and navigate the change advisory board for approval. Each handoff loses context. Each queue adds latency. The aggregate effect is that even straightforward operational improvements take weeks rather than hours.

The second structural problem is the accountability gap. When development, operations, security and compliance are separate functions with separate incentives, it becomes possible—even rational, from each team’s perspective—to optimise locally at the expense of the whole. Development teams optimise for feature velocity and treat operational concerns as someone else’s problem. Operations teams optimise for stability and resist changes that introduce risk. Security teams optimise for policy compliance and issue findings without regard for the operational cost of remediation. No single team owns the end-to-end outcome of a service running reliably, securely and in compliance with sovereignty obligations. The result is what Skelton and Pais, in Team Topologies, describe as organisational friction that directly impedes the flow of change through the system [2].

The third problem is peculiar to sovereign estates. Sovereignty obligations—data residency, jurisdictional control, regulatory reporting—cut across every traditional function. They are simultaneously a development concern (applications must be designed to respect zone boundaries), an infrastructure concern (workloads must be placed in the correct regions), a security concern (access controls must enforce jurisdictional constraints), an operations concern (incidents must be managed within sovereign zone boundaries) and a compliance concern (evidence must be produced that all of these things are actually happening). No single team in a traditional functional structure owns sovereignty end to end. The obligation falls between the cracks, addressed partially by each team and fully by none.

These problems are not new observations. The DevOps movement, beginning in the late 2000s, identified the development-operations handoff as a primary constraint and proposed cross-functional teams, shared ownership and continuous delivery as remedies [3]. Site Reliability Engineering, as practised at Google and described in the foundational SRE texts, proposed a specific organisational model in which software engineers take responsibility for the reliability of production systems, with explicit error budgets, toil budgets and service level objectives as governance mechanisms [4]. Platform Engineering, the more recent evolution, proposes that internal platform teams provide self-service capabilities to stream-aligned teams, reducing the cognitive load on those teams while maintaining organisational standards [5]. Each of these movements has contributed valuable ideas. None of them, however, was designed with the specific constraints of sovereign, agentic operations in mind.

This chapter describes the operating model changes required when an organisation adopts the technical capabilities described in Parts VII through IX of this book. It addresses team structures, decision rights, automation economics, on-call practices and measurement frameworks, always through the lens of an estate where sovereignty constraints and agentic automation are architectural realities rather than aspirations. The chapter does not propose a single universal model—no such thing exists—but it does identify the structural patterns that recur in organisations that successfully operate sovereign, agentic estates, and the anti-patterns that cause others to struggle.

The operating model gap

31.2 Shift-left operations defined

The phrase “shift left” originates in software testing, where it described the practice of moving testing activities earlier in the development lifecycle—from post-deployment verification to pre-merge automated checks—so that defects are caught sooner, when they are cheaper to fix [3]. The principle has since been applied to security (“shift-left security” or DevSecOps), to compliance, and increasingly to operations. In each case, the underlying logic is the same: concerns that were historically addressed late in the lifecycle, by specialist teams, at high cost and with long feedback loops, are instead embedded into the development workflow itself, where they can be addressed by the people closest to the code, with fast, automated feedback.

Shift-left operations extends this principle to the full range of operational concerns. Rather than treating operability as something assessed after deployment—through post-release monitoring, incident retrospectives and capacity reviews—it embeds operational considerations into the design, development and deployment phases. The question is not “is this service operable?” asked after it is already running in production. The question is “will this service be operable?” asked while it is still being designed and built, with tooling and processes that make the answer verifiable before any production traffic arrives.

Concretely, shift-left operations encompasses several practices that, taken together, represent a significant departure from the traditional model.

Service level objectives defined at design time. Rather than establishing SLOs retroactively based on observed production behaviour, teams define them as part of the service design process. An SLO for a payment processing service—”99.95% of transactions complete within 800 milliseconds”—becomes a design constraint that influences architectural decisions, not merely a monitoring threshold applied after the fact. The Google SRE Workbook provides detailed guidance on this practice, emphasising that SLOs should be derived from user expectations and business requirements, not from infrastructure capabilities [6].

Observability instrumentation as a development activity. Rather than relying on operations teams to instrument applications after deployment, development teams instrument their services as part of the development process. OpenTelemetry SDKs are integrated into the application build, trace context propagation is verified in integration tests, and custom metrics that reflect business-meaningful behaviour are defined by the developers who understand the domain. Chapter 7 described the observability architecture; shift-left operations ensures that this architecture is populated by instrumentation that originates in development, not bolted on by a separate team.

Policy-as-code evaluated in CI/CD pipelines. Sovereignty constraints, security policies and compliance requirements are codified as machine-readable policies—using Open Policy Agent, Kyverno or equivalent frameworks as described in Chapter 10—and evaluated automatically as part of the continuous integration pipeline. A deployment that would place a workload in a non-compliant region, expose a service without the required authentication, or violate a data residency constraint is rejected before it reaches production, with a clear, actionable error message explaining the violation. This is fundamentally different from periodic compliance audits conducted after deployment, which discover violations weeks or months after they were introduced.

Infrastructure as code reviewed alongside application code. The Terraform modules, Helm charts and Kubernetes manifests that define the deployment topology of a service are stored in the same repository as the application code, or in a linked repository with shared review processes. Changes to infrastructure are reviewed by the same team that reviews application changes, ensuring that the operational implications of infrastructure modifications are understood by the people who will be affected by them. Chapter 11 described the infrastructure-as-code patterns; shift-left operations ensures that these patterns are integrated into the development workflow rather than managed by a separate infrastructure team operating on a different cadence.

Runbook authorship by service teams. Rather than relying on a central operations team to write runbooks for services they did not build, the teams that design and build services also author the runbooks for operating them. This follows naturally from the SRE principle that the people who understand a system best are the ones who should define how to respond when it misbehaves [4]. Chapter 12 described the anatomy of production-quality runbooks; shift-left operations assigns their authorship to the teams with the deepest understanding of the service’s behaviour.

Chaos engineering and resilience testing in pre-production. Rather than discovering failure modes through production incidents, teams proactively inject failures in pre-production environments to verify that their services degrade gracefully, that their runbooks are accurate and that their observability instrumentation provides sufficient signal for diagnosis. This practice, pioneered by Netflix and formalised in the chaos engineering discipline, is the operational equivalent of the testing shift-left that transformed software quality a generation earlier [7].

The Platform Engineering movement provides the organisational substrate that makes these practices scalable. Individual stream-aligned teams cannot each independently build CI/CD pipelines with policy evaluation, observability instrumentation frameworks, infrastructure-as-code templates and chaos engineering tooling. The cognitive load would be paralysing. Instead, a platform engineering team provides these capabilities as self-service products—golden paths that embed operational best practices, sovereignty constraints and organisational standards into reusable templates and toolchains that stream-aligned teams consume [5]. The platform does not dictate; it enables. Teams retain autonomy over their service design and deployment decisions, but those decisions are made within a framework that makes the right thing easy and the wrong thing difficult.

Shift-left operations

31.3 The sovereign operations team structure

Adopting shift-left operations and agentic automation does not mean that dedicated operations roles disappear. It means that the roles change, that new roles emerge, and that the boundaries between existing roles shift. The operating model must accommodate these changes explicitly, or the organisation will end up with a set of roles that no longer match the work that needs to be done.

Skelton and Pais propose four fundamental team types—stream-aligned, enabling, complicated-subsystem and platform—as the building blocks of effective technology organisations [2]. This taxonomy is a useful starting point, but it requires extension to address the specific concerns of sovereign, agentic estates. The following roles and team structures have emerged in organisations that operate such estates effectively.

Sovereign zone owners are accountable for the end-to-end operational integrity of a specific sovereign zone. A sovereign zone, as defined in Chapter 4, is a bounded operational domain with specific jurisdictional, regulatory and data residency constraints. The zone owner is not a traditional infrastructure manager; they are a cross-functional role that bridges development, operations, security and compliance within the zone boundary. They ensure that all services deployed within the zone comply with its constraints, that the zone’s observability and audit posture is maintained, and that incident response within the zone follows the zone-specific escalation paths. In organisations with multiple sovereign zones—an EU regulated zone, a UK sovereign zone, a US federal zone—each zone has a designated owner who understands both the technical topology and the regulatory obligations specific to that jurisdiction. The zone owner role is analogous to the service owner role in traditional ITSM, but scoped to a jurisdictional boundary rather than a single service.

AI agent supervisors are responsible for the governance and operational oversight of the agentic automation deployed within the estate. As described in Chapters 21 through 23, AI agents operating within bounded autonomy require ongoing supervision: their actions must be audited, their decision quality must be assessed, their scope boundaries must be reviewed, and their behaviour under novel conditions must be monitored. The agent supervisor role combines elements of traditional change management (reviewing and approving the scope of agent actions), quality assurance (assessing whether agent recommendations are accurate and appropriate) and risk management (identifying conditions under which agents should be constrained further or granted additional autonomy). This is a new role with no direct precedent in traditional IT operating models, and organisations that attempt to distribute agent supervision across existing roles without dedicated accountability frequently discover that supervision is performed inconsistently or not at all.

Policy engineers author, maintain and evolve the policy-as-code artefacts that govern the estate. These are the Open Policy Agent Rego policies, the Kyverno cluster policies, the Sentinel rules and the custom guardrail definitions described in Chapter 10. Policy engineering is a specialised discipline that requires understanding of both the regulatory intent behind a policy and the technical mechanism through which it is enforced. It sits at the intersection of compliance, security and platform engineering. In traditional organisations, compliance teams write policies in natural language and expect other teams to implement them; policy engineers close the gap by translating regulatory requirements into executable code, testing that code against realistic scenarios, and maintaining it as both the regulatory landscape and the technical estate evolve.

Platform engineers build and maintain the internal developer platform that provides self-service operational capabilities to stream-aligned teams. Their products include the CI/CD pipeline templates with integrated policy evaluation, the observability instrumentation libraries, the infrastructure-as-code modules for sovereign zone deployment, the runbook templates and the agent interaction frameworks. The platform engineering role is well-established in the industry [5], but in a sovereign, agentic context it carries additional responsibilities: the platform must encode sovereignty constraints into its golden paths, and it must provide the interfaces through which agents interact with the operational substrate.

These new roles do not replace existing ones wholesale. They interact with and extend the roles that organisations already have.

Site reliability engineers continue to own the reliability of production services, but their focus shifts from reactive incident response toward proactive reliability engineering. In an estate where agents handle first-response diagnostics and routine remediation, SREs spend less time on operational toil and more time on systemic improvements: refining SLOs, improving observability coverage, designing for failure, and reviewing agent performance. The SRE role becomes more architectural and less operational in the traditional sense.

Security engineers continue to own the security posture of the estate, but their work increasingly takes the form of policy authorship and review rather than periodic auditing. In a shift-left model, security engineers contribute to the policy-as-code corpus, review infrastructure-as-code changes for security implications, and participate in the design of agent scope boundaries. The shift from gatekeeper to enabler—from “no, you cannot do that” to “here is how to do that securely”—is a cultural transition that this chapter’s companion, Chapter 32, addresses in more detail.

Compliance analysts continue to interpret regulatory requirements and assess organisational adherence, but they increasingly work with machine-readable evidence rather than manual audit artefacts. In a sovereign, agentic estate with rich observability and policy-as-code enforcement, the evidence of compliance is generated continuously and automatically. The compliance analyst’s role shifts from periodic evidence gathering toward continuous assurance: monitoring the compliance dashboards, investigating policy evaluation failures, and working with policy engineers to refine rules as regulatory interpretations evolve.

The organisational structure that accommodates these roles is not a hierarchy but a network. Skelton and Pais’s team interaction modes—collaboration, X-as-a-Service, and facilitating—describe how these teams work together [2]. The platform team provides capabilities as a service to stream-aligned teams. Policy engineers collaborate closely with compliance analysts and security engineers. Sovereign zone owners facilitate coordination across the teams operating within their zone. Agent supervisors interact with every team whose services are subject to agentic automation. The interaction patterns are deliberately fluid; rigid reporting structures that force all communication through management chains are actively harmful in environments where cross-functional coordination is the norm.

Sovereign operations team topology

31.4 Decision rights and escalation frameworks

In any operating model, clarity about who decides what is essential. In a sovereign, agentic operating model, this clarity is not merely an organisational preference—it is a regulatory requirement. DORA’s Article 5 mandates that financial entities establish governance arrangements with clear allocation of roles and responsibilities for ICT-related functions [8]. NIS2’s Article 20 requires management bodies to approve and oversee the implementation of cybersecurity risk-management measures [9]. These requirements demand that decision rights be documented, that escalation paths be explicit, and that the boundary between automated and human decisions be both clear and defensible.

The decision framework for a sovereign, agentic estate can be organised into three tiers based on the scope and reversibility of the decision.

Tier 1: Fully automated decisions. These are decisions that agents make autonomously, within the bounded autonomy framework described in Chapter 21. They include: scaling a stateless service within pre-approved resource limits; restarting a failed pod that has not exceeded its restart budget; executing a pre-approved runbook step in response to a well-characterised alert; rotating a certificate before expiry using the automated rotation workflow. Tier 1 decisions share common characteristics: they are reversible, their blast radius is bounded, they operate within a single sovereign zone, and the policy framework has a pre-evaluated rule permitting the action. No human approval is required, but every action is logged to the audit trail with full provenance, and the aggregate pattern of Tier 1 decisions is reviewed periodically by agent supervisors.

Tier 2: Human-approved decisions. These are decisions that agents propose but that require human approval before execution. They include: deploying a new version of a service that has passed all automated checks but carries a risk score above the auto-approval threshold; modifying a network security group rule; changing the configuration of a shared database; executing a remediation action that affects multiple services or crosses a sovereign zone boundary. Tier 2 decisions are surfaced to the appropriate human decision-maker through the recommendation-driven operations interface described in Chapter 28, with the agent providing a structured recommendation that includes the proposed action, its expected impact, the evidence supporting it, and the rollback path. The human approves, modifies or rejects the recommendation, and their decision is recorded in the audit trail alongside the agent’s original recommendation.

Tier 3: Committee-reviewed decisions. These are decisions with estate-wide, irreversible or regulatory implications that require review by a governance body. They include: establishing a new sovereign zone; modifying the policy-as-code rules that govern agent autonomy boundaries; granting an agent a new class of write access; decommissioning a service that is a dependency for multiple other services; making architectural changes that alter the data flow topology across sovereign zone boundaries. Tier 3 decisions follow a formal review process—analogous to a change advisory board but structured for an agentic estate—with documented input from sovereign zone owners, agent supervisors, policy engineers and the relevant compliance analysts. The review produces a recorded decision with rationale, conditions and review date.

The RACI model (Responsible, Accountable, Consulted, Informed) provides a useful framework for documenting these decision rights, provided it is adapted for agentic operations. In a traditional RACI matrix, all actors are human. In an agentic estate, agents occupy the “Responsible” column for Tier 1 decisions—they are the actors performing the work—while humans remain “Accountable” in all tiers. The distinction between Responsible and Accountable is not academic; it is the structural mechanism that satisfies regulatory requirements for human oversight of automated systems. An agent may be responsible for executing a scaling action, but the sovereign zone owner is accountable for the outcome. If the action causes harm, the accountability rests with the human role that approved the autonomy boundary, not with the agent.

Escalation paths in a sovereign estate must be sovereignty-aware. An incident affecting a service in the EU regulated zone escalates to the EU zone owner and to compliance analysts familiar with DORA and GDPR obligations, not to a generic global escalation chain. An agent action that is blocked by a policy evaluation failure escalates to the policy engineer who authored the relevant rule, not to a general operations queue. The escalation framework encodes jurisdictional knowledge: who understands the regulatory context of each zone, who has the authority to approve exceptions, and who must be notified when specific classes of event occur. This jurisdictional routing is itself implemented as policy-as-code, using the same guardrail framework that governs agent autonomy, so that escalation paths are enforced consistently rather than relying on human memory of organisational charts.

Three-tier decision framework for sovereign agentic operations

31.5 Toil reduction and automation economics

Google’s SRE framework introduced the concept of toil as a formal operational category: work that is manual, repetitive, automatable, tactical, lacking in enduring value, and that scales linearly with service growth [4]. The SRE model prescribes that SRE teams should spend no more than fifty per cent of their time on toil, with the remainder devoted to engineering work that reduces future toil. This is not a vague aspiration; it is an explicit budget, monitored and enforced, that prevents operations teams from being consumed by repetitive work at the expense of systemic improvement.

In a sovereign estate, the toil landscape has characteristics that the original SRE toil model did not anticipate. Sovereignty obligations generate their own categories of toil: manually verifying that deployments land in the correct regions, manually producing compliance evidence for audit cycles, manually reviewing agent actions that cross zone boundaries, manually coordinating with zone-specific contacts during incidents. These sovereignty-specific toil categories are invisible in organisations that measure toil only in traditional infrastructure terms—patching, provisioning, alert triage—but they consume significant engineering time and scale with the number of sovereign zones the organisation operates.

Measuring toil in a sovereign estate therefore requires an expanded taxonomy. The following categories have proven useful in practice.

Alert triage toil encompasses the time spent reviewing, classifying and routing alerts that do not require engineering judgement. In estates with mature observability and agent-assisted triage (as described in Chapter 30), a significant proportion of alerts can be triaged automatically, but the residual manual triage—alerts that the agent cannot classify with sufficient confidence—still consumes time.

Compliance evidence toil encompasses the time spent assembling, formatting and delivering evidence for regulatory audits and internal compliance reviews. In organisations with policy-as-code and continuous compliance monitoring (Chapter 10), much of this evidence is generated automatically. But the final-mile work—explaining evaluation results to auditors, reconciling discrepancies, preparing narratives—often remains manual.

Sovereignty coordination toil encompasses the time spent ensuring that operational actions respect sovereign zone boundaries. This includes verifying that change requests affect only the intended zone, coordinating with zone-specific contacts, and reviewing agent recommendations that have cross-zone implications.

Agent supervision toil encompasses the time spent reviewing agent actions, validating agent recommendations, and investigating agent behaviour anomalies. As the volume of agent-assisted operations increases, supervision toil can grow substantially unless the supervision process itself is supported by tooling—dashboards that highlight anomalous agent behaviour, automated quality metrics that flag declining recommendation accuracy, and sampling-based audit workflows that make supervision efficient without requiring review of every individual action.

The economics of automation investment in a sovereign estate differ from those in a conventional environment because the cost of manual processes includes not only engineering time but also compliance risk. A manual process that occasionally produces an incorrect result in a non-regulated environment creates a reliability problem. The same manual process in a regulated sovereign zone creates a compliance exposure. The economic case for automating a process in a sovereign estate therefore includes the avoided cost of compliance failures, regulatory findings and the remediation effort they trigger, in addition to the engineering time saved.

The practical approach to toil reduction follows a cycle that is familiar from SRE practice but adapted for sovereign constraints. First, measure: instrument the time spent on each toil category, using time-tracking mechanisms that are lightweight enough for engineers to use honestly. Second, prioritise: rank toil categories by the product of their time cost, their compliance risk and their growth rate as the estate scales. Third, automate: invest engineering effort in reducing the highest-priority toil categories, using the agentic automation patterns described in Chapters 18 and 19. Fourth, verify: confirm that the automation produces correct results, complies with sovereignty constraints, and actually reduces the time engineers spend on the toil category it was designed to address. Fifth, iterate: as automation eliminates one category of toil, the next-highest-priority category becomes the focus.

The toil budget concept is directly applicable. An organisation might establish that sovereign operations teams should spend no more than forty per cent of their time on toil, with the remaining sixty per cent devoted to engineering work that improves the platform, refines policies, enhances observability, or extends agent capabilities. The specific threshold matters less than the existence of the threshold: without an explicit budget, toil expands to fill available capacity, and the engineering work that would reduce future toil never happens.

31.6 On-call and incident response in an agentic world

On-call duty has long been one of the most demanding aspects of operations work. The traditional on-call model places a human engineer as the first responder for any production issue, at any hour, with the expectation that they will diagnose the problem, determine the appropriate response, execute it, and communicate with stakeholders—all under time pressure and often with incomplete information. The cognitive and physiological costs of this model are well documented. Dekker’s research on human error in complex systems demonstrates that fatigue, time pressure and information overload systematically degrade human decision-making quality [10]. The Google SRE framework addresses this directly, prescribing that on-call engineers should handle no more than two events per twelve-hour shift on average, that on-call load should be distributed equitably across the team, and that on-call engineers should have adequate time for post-incident recovery [4].

Agentic operations changes the on-call model in ways that are significant but that must be implemented carefully to avoid creating new problems while solving old ones.

The most immediate change is that agents handle first response for well-characterised incidents. When an alert fires for a known failure mode—a service exceeding its error budget, a pod crash-looping, a certificate approaching expiry—the agent executes the pre-approved diagnostic and remediation workflow without waking a human. The on-call engineer is notified that the incident occurred and was resolved, but they are not interrupted during the resolution. This reduces the interrupt frequency for on-call engineers substantially. In organisations that have implemented mature agent-assisted first response, the number of incidents that require human intervention during on-call hours drops by fifty to seventy per cent, with the exact figure depending on the maturity of the runbook corpus and the breadth of the agent’s approved action scope.

The second change is that when human intervention is required, the on-call engineer arrives to a richer context than was historically available. Rather than starting from a raw alert and a set of dashboards, they receive an agent-prepared incident summary that includes the initial diagnostic findings, the actions already taken, the current state of the affected services, the dependency graph of potentially impacted components, and a set of recommended next steps. Chapter 30 described this pattern in detail. The effect on the on-call experience is substantial: the cognitive ramp-up time—the period between receiving the alert and understanding enough to begin meaningful action—is compressed from minutes to seconds.

The third change is more subtle and more important to manage deliberately. As agents handle an increasing proportion of routine incidents, human operators have fewer opportunities to practise their diagnostic and remediation skills on real production problems. This is the skills atrophy risk: the possibility that as agents become more capable, the humans who supervise them become less capable, precisely at the moment when human capability matters most—during the novel, complex incidents that agents cannot handle alone. Aviation has grappled with exactly this challenge as cockpit automation has advanced, and the lessons are directly applicable. Pilots who rely heavily on autopilot can lose proficiency in manual flight skills; the solution is not to disable automation but to ensure that training, simulation and deliberate practice opportunities maintain human proficiency alongside automated capability [10].

In a sovereign operations context, maintaining human skills requires deliberate investment. Practices that have proven effective include the following.

Game days and chaos engineering exercises provide controlled opportunities for operators to practise diagnosis and response in realistic conditions without the consequences of real production incidents. These exercises should include scenarios that agents cannot handle—novel failure modes, ambiguous signals, cross-zone incidents—so that operators maintain the skills needed for precisely the situations where they will be called upon.

Agent-assisted training mode is a practice in which agents operate in a shadow mode during training exercises, generating recommendations that the trainee can compare against their own analysis. The divergence between the agent’s recommendation and the trainee’s approach becomes a learning opportunity, revealing both gaps in the trainee’s knowledge and limitations in the agent’s reasoning.

Rotation through agent supervision ensures that operators regularly review agent actions, not merely to audit them but to maintain their own understanding of the estate’s operational patterns. An operator who has spent a week reviewing the agent’s incident handling across the estate develops a broader understanding of failure modes and remediation patterns than one who only encounters incidents in their own service area.

Post-incident reviews that include agent performance assessment create a feedback loop in which human operators evaluate the quality of agent actions and recommendations. This evaluation serves dual purposes: it improves agent performance through feedback, and it ensures that human operators maintain the analytical depth required to assess whether an agent’s actions were appropriate.

The on-call escalation model also changes in an agentic estate. Rather than a simple primary-secondary-manager chain, escalation follows the sovereignty-aware paths described in section 31.4. An agent that encounters an incident it cannot resolve within its autonomy boundary escalates to the on-call engineer for the affected service. If the incident has cross-zone implications, it simultaneously notifies the relevant sovereign zone owners. If the incident involves agent behaviour that the agent supervisor has flagged as anomalous, it escalates to the agent supervision function. The escalation paths are encoded in the same policy-as-code framework that governs agent autonomy, ensuring consistency.

31.7 Measuring operating model effectiveness

An operating model that is not measured cannot be improved. Traditional IT operations metrics—mean time to restore (MTTR), mean time between failures (MTBF), change success rate, incident volume—remain relevant but are insufficient for measuring the effectiveness of a sovereign, agentic operating model. They measure the outputs of the operational process without capturing the health of the operating model itself. An organisation can have a good MTTR because a few heroic individuals work punishing on-call shifts, not because the operating model is sound. A comprehensive measurement framework must include metrics that reflect team health, automation effectiveness, sovereignty compliance and organisational learning.

The following metric categories have proven valuable in organisations operating sovereign, agentic estates.

Team cognitive load measures the subjective and objective burden on operations teams. Subjective measures—periodic surveys asking teams to rate the cognitive demand of their work—are simple but revealing. Objective proxies include the number of context switches per on-call shift, the number of distinct systems an operator must interact with during a typical incident, and the ratio of reactive to proactive work. Skelton and Pais argue that cognitive load is the fundamental constraint on team effectiveness and that organisational structures should be designed to minimise it [2]. In a sovereign estate, cognitive load has a sovereignty dimension: teams operating across multiple sovereign zones with different regulatory regimes carry higher cognitive load than teams operating within a single zone, and this should be reflected in team sizing and scope.

Toil percentage measures the proportion of engineering time spent on toil, as defined in section 31.5. This metric is tracked per team, per sovereign zone and in aggregate, with a target ceiling (typically forty to fifty per cent) below which the metric should remain. Trends are more important than point-in-time values: a toil percentage that is rising despite automation investments indicates that either the automation is not effective or that new toil categories are emerging faster than existing ones are being eliminated.

Automation coverage measures the proportion of operational tasks that are fully or partially automated, segmented by task category (incident response, compliance evidence, change execution, provisioning). This metric should be paired with an automation quality metric that assesses whether automated tasks produce correct results—an automation that runs frequently but fails silently is worse than a manual process that succeeds reliably.

Sovereignty compliance rate measures the proportion of operational actions—deployments, configuration changes, data movements, agent actions—that comply with the sovereignty constraints of the zone in which they occur, as evaluated by the policy-as-code framework. A rate of one hundred per cent is the target; deviations indicate either policy violations (which require investigation and remediation) or policy mis-specifications (which require policy refinement). The trend and the root cause distribution of non-compliant actions are more informative than the aggregate rate.

Agent utilisation and effectiveness measures the volume and quality of agent-assisted operations. Utilisation metrics include the number of incidents handled autonomously by agents, the number of recommendations generated and accepted, and the proportion of on-call alerts resolved without human intervention. Effectiveness metrics include the accuracy of agent diagnoses (assessed through post-incident review), the acceptance rate of agent recommendations (a declining rate may indicate declining recommendation quality or changing team confidence), and the mean time from agent recommendation to human decision for Tier 2 actions.

Deployment frequency and lead time measure the flow of changes through the operational pipeline. The DORA research programme (not to be confused with the EU regulation of the same acronym) has established deployment frequency, lead time for changes, change failure rate and time to restore service as the four key metrics for software delivery and operational performance [3]. In a sovereign estate, these metrics should be segmented by sovereign zone, since different zones may have different change cadences driven by their regulatory constraints—a zone subject to strict change freeze windows will have lower deployment frequency during those periods, and this should be treated as expected behaviour rather than a deficiency.

Continuous improvement cadence measures the rate at which the operating model itself evolves. Indicators include the number of post-incident improvement actions completed, the number of toil-reduction automation projects delivered, the number of policy-as-code rules refined, and the frequency of operating model retrospectives. An operating model that is static is, by definition, falling behind: the estate evolves, regulations change, agent capabilities expand, and the operating model must adapt to remain effective.

These metrics should be assembled into a sovereign operations dashboard that is reviewed regularly—weekly by operations leadership, monthly by the broader governance body—with trends, anomalies and improvement actions tracked explicitly. The dashboard is itself an operational artefact: it demonstrates to regulators and auditors that the organisation measures its operational effectiveness continuously, not merely in response to incidents or audit findings.

Sovereign operations measurement framework

Key Takeaways

Bridge to Chapter 32 — Skills, Culture, and Human Factors

Restructuring teams, redefining decision rights and measuring new metrics are necessary but not sufficient. An operating model is, in the end, a human system. Its effectiveness depends on the skills, attitudes and cultural norms of the people who inhabit it. Chapter 32 examines the human factors that determine whether a sovereign, agentic operating model succeeds or fails: the skills gap created by agentic automation, the cultural shift from gatekeeper to enabler, the trust calibration required when humans and agents share operational responsibility, and the learning practices that keep the organisation ahead of its own complexity.

References

[1] AXELOS, ITIL Foundation: ITIL 4 Edition. London: TSO (The Stationery Office), 2019. [Online]. Available: https://www.axelos.com/certifications/itil-service-management/itil-4-foundation

[2] M. Skelton and M. Pais, Team Topologies: Organizing Business and Technology Teams for Fast Flow. Portland, OR: IT Revolution Press, 2019. [Online]. Available: https://teamtopologies.com/book

[3] G. Kim, J. Humble, P. Debois, J. Willis, and N. Forsgren, The DevOps Handbook: How to Create World-Class Agility, Reliability, & Security in Technology Organizations, 2nd ed. Portland, OR: IT Revolution Press, 2021. [Online]. Available: https://itrevolution.com/product/the-devops-handbook-second-edition/

[4] B. Beyer, C. Jones, J. Petoff, and N. R. Murphy, Eds., Site Reliability Engineering: How Google Runs Production Systems. Sebastopol, CA: O’Reilly Media, 2016. [Online]. Available: https://sre.google/sre-book/table-of-contents/

[5] L. Reeves and C. Campbell, Platform Engineering on Kubernetes. Shelter Island, NY: Manning Publications, 2024. [Online]. Available: https://www.manning.com/books/platform-engineering-on-kubernetes

[6] A. Fong-Jones, G. Blanco, N. R. Murphy, and S. Thorne, The Site Reliability Workbook: Practical Ways to Implement SRE. Sebastopol, CA: O’Reilly Media, 2018. [Online]. Available: https://sre.google/workbook/table-of-contents/

[7] C. Rosenthal and N. Jones, Chaos Engineering: System Resiliency in Practice. Sebastopol, CA: O’Reilly Media, 2020. [Online]. Available: https://www.oreilly.com/library/view/chaos-engineering/9781492043850/

[8] European Parliament and Council, “Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA),” Official Journal of the European Union, vol. L 333, pp. 1–79, Dec. 2022. [Online]. Available: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32022R2554

[9] European Parliament and Council, “Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS2),” Official Journal of the European Union, vol. L 333, pp. 80–152, Dec. 2022. [Online]. Available: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32022L2555

[10] S. Dekker, The Field Guide to Understanding ‘Human Error’, 3rd ed. Boca Raton, FL: CRC Press, 2014. [Online]. Available: https://doi.org/10.1201/9781317031833

Sovereign Cloud Operations: AI-Driven Management of Sovereign Estates © 2026 by Alan Hamilton is licensed under CC BY-SA 4.0