The Future of Operations: Will Anyone Be on Call in 2036?

This chapter looks ahead at operations with the series' discipline and asks the question that the book has so far kept at arm's length: will anyone be on call in 2036, or will operations converge into agents and provider-run services with no person who can take over? It concerns all five operations functions, O1 Observe, O2 Diagnose, O3 Change, O4 Restore and O5 Sustain, because each is a candidate for further automation and because the answer decides who holds the observer, the stop path and the manual capability that Chapters 4, 17 and 19 made the safety net. The chapter treats the outlook as a horizon register, states the evidence under each label, stages the debate between concern and calm, and then gives the author's own projection, labelled as such, with the evidence that would change it.

Three earlier volumes asked the same kind of question about a neighbouring function. AI Blue, Chapters 24 and 28, asked whether there will be a security operations centre in 2036 and kept an accountable function wherever a person must verify and stop the AI (302, Nordqvist, 2026). The Transformed Security Architect, Chapters 23 and 27, kept the role wherever accountability for a boundary must be human (300, Nordqvist, 2026). AI Purple, Chapter 25, asked whether red and blue will be separate teams and concluded that independence is needed in every future, while where it lives is open (304, Nordqvist, 2026). This chapter does not repeat those answers. It builds on an outlook governed as a horizon register, in which observable trends justify commitment, expected ones preparation and speculative ones reversibility, with the author's judgement kept apart from the findings (AI Governance, Chapters 22 and 24) (296, Nordqvist, 2026), and it asks what is particular to operations: the oldest automation in the series, the credentials that make the operator's AI a Tier 0 asset and a duty of the management body that no tool can take over.

Observable, expected and speculative trajectories to 2036, with what stays constant in every future

Figure 27.1: Trajectories to 2036 labelled by evidence. The observer, the stop path and practised manual recovery are held constant, and the register relabels what the evidence changes. The table below lists the items.

The table lists the items in the figure.

Label Items
Observable Agent products investigate incidents; benchmarks show low resolution on unseen faults; change volume rises and stability lags; critical providers come under DORA oversight
Expected Level 3 widens class by class on evidence; the bottleneck moves from authoring to verification; a named human stays accountable for Tier 1
Speculation Unattended recovery of whole estates; a provider-run loop with no customer-side observer; no one on call
Constant in every future An independent observer and a drilled stop path outside the platform; manual recovery practised with agents off; a horizon register reviewed with triggers

A horizon register for operations

Ten years is a long horizon, and those best placed to speak about operations have a stake in the answer. A vendor has a reason to describe the autonomous estate as near, a head of operations to describe it as far, and a finance director to count the on-call rota as a cost that agents will remove. Tetlock's study of expert political judgment compared experts' predictions with those of well-informed laypeople and with simple extrapolation, and reported that the thinkers who know many little things were more successful at predicting than those who know one big thing (290, Tetlock, 2005). The study concerned political forecasts and says nothing about operations. Its use here is as a discipline: hold many small, dated, falsifiable views and revise them, and do not hold one large view.

The register makes such views reviewable. Each trend carries one label, names the functions it concerns, points to evidence, states the trigger that would change the posture, and names an owner and a review date. A trend is observable if it is happening now and documented, expected if it is supported by a stated trend or a decided instrument, and speculation if it is plausible but unsupported by present evidence. The posture follows the label: commit to what is observable, prepare for what is expected, and keep reversible what is speculation. Keeping a decision reversible, in operations, has a concrete meaning: the manual runbook is kept and drilled, the stop path stays in place, and the contract keeps its exit.

A register for operations differs from those of the earlier volumes in one respect that helps it. Its triggers can be computed from the loop's own records. Operations already produces dated evidence per action class: autonomy-budget consumption (Chapter 4), seeded-fault catch rates and stop-drill times (Chapter 17), restore-test results and their evidence age (Chapter 19), and the distribution of restore times (Chapter 20). A trigger such as "the observer caught fewer than nine in ten seeded faults for the rollback class in the last quarter" is a measurement and not an opinion. The register is kept by the people who run the loop and approved by someone who does not, because a register that only its keepers maintain drifts towards the answer that keeps their post.

What is observable

Observable trends are happening now and are documented. They justify commitment: a decision can be taken on them today.

Agent products for investigation are on the market. Amazon Web Services announced the general availability of AWS DevOps Agent on 31 March 2026, describing it as an always-available operations teammate that resolves and proactively prevents incidents, and that connects observability data, runbooks, code and deployment history to investigate problems. The announcement says that the agent autonomously triages incidents and guides teams to rapid resolution; it does not state that the agent changes production itself (291, AWS, 2026). The text is a vendor's description of its own product and carries no measurement. It shows that the incident assistant of Chapter 7 is a product category, and that the question for an organisation is the level at which it accepts one (Chapter 24).

Measured performance on unseen faults is low, and the measurements date quickly. On OpenRCA, a benchmark of 335 failures from three enterprise software systems, the best model with the authors' agent solved 11.34 per cent of the failures (128, Xu et al., 2025). On ITBench, agents built on state-of-the-art models resolved 11.4 per cent of the site reliability engineering scenarios (225, Jha et al., 2025). Both studies measured the models their authors could test, with a given agent scaffold. They are evidence about that generation on those benchmarks and do not describe an agent on a particular estate in 2036. Chapter 10 drew the line accordingly: catalogued, reversible classes at Level 3 Bounded, unfamiliar diagnosis with a person.

Capability is measured as rising quickly on software tasks. Kwa and colleagues propose the length of task, in the time a person needs, that a model completes with 50 per cent success, and report that for frontier models of early 2025 it was around 50 minutes in the first version of the paper (around 110 minutes for the strongest model in the current version) and that it has doubled approximately every seven months since 2019 (289, Kwa et al., 2025). The tasks were software and research-engineering tasks timed by people, the authors name external validity as a limit, and their projection that many month-long software tasks could be automated within five years is conditional on the results generalising to real-world software tasks. The trend is observable; its extension to operations is not shown, since an incident on an estate with dependencies, change windows and a freeze calendar is not a benchmark task.

Change volume grows, and stability lags without controls. The 2025 report of the DevOps Research and Assessment programme, drawing on nearly 5,000 technology professionals, found that 90 per cent of respondents used AI at work, a positive relationship between AI adoption and delivery throughput, and a continuing negative relationship with delivery stability. The report's own reading is that acceleration can expose weaknesses downstream, and that without robust control systems an increase in change volume leads to instability (117, Harvey & DeBellis, 2025). The finding is a survey association and not a trial; it supports the structure of Chapters 8 and 9.

Perceived and measured speed differ. In a randomised trial, 16 experienced open-source developers completed 246 tasks on their own repositories; developers had forecast a 24 per cent reduction in completion time and afterwards estimated 20 per cent, and the measured effect was an increase of 19 per cent (231, Becker et al., 2025). The study concerns software development, not operations, and is a caution about any forecast built on how fast operators feel (Chapter 20).

Automation still fails, and people still repair it. In the AWS disruption of 19 and 20 October 2025, a latent race condition in the DNS management of DynamoDB left the regional endpoint with an empty DNS record that automation failed to repair; the provider's report states that the situation ultimately required manual operator intervention to correct. DynamoDB was affected from 11:48 PM PDT on 19 October, DNS was restored by about 2:25 AM, and dependent EC2 impact continued until 1:50 PM PDT on 20 October (75, AWS, 2025). Google's account of a decommissioning automation that treated an empty list as everything and wiped the disks of its content delivery machines, with about two days to recover, is older and makes the same point (252, Murphy et al., 2017). The two incidents show that automated operations fail in ways that need a person who can operate by hand; they do not measure how often.

Concentration is under supervision. On 18 November 2025 the European Supervisory Authorities published the list of critical ICT third-party providers designated under DORA, and state that designated providers come under direct oversight of their risk management and governance (7, EBA, 2025). Article 31(1)(a) of DORA gives the Authorities the power to designate providers that are critical for financial entities, and Article 28(8) requires financial entities to put in place exit strategies for ICT services supporting critical or important functions (2, European Union, 2022).

Where a human is required, the instruments say so. For high-risk AI systems, Article 14(4) of the AI Act requires that the natural persons to whom oversight is assigned can decide not to use the system or to disregard, override or reverse its output, and can intervene or interrupt the system through a stop button or a similar procedure that allows it to halt in a safe state; Article 26(2) requires deployers to assign human oversight to natural persons with the necessary competence, training and authority, and the necessary support (1, European Union, 2024). Regulation (EU) 2026/1744 moved the application of those provisions to 2 December 2027 for systems classified under Article 6(2) and Annex III and 2 August 2028 for those under Article 6(1) and Annex I (11, European Union, 2026). An operations agent is not in general a high-risk AI system, and an organisation checks its classification; the provisions matter here as the clearest statement in EU law of what a stop path and an assigned person are. DORA Article 5 and NIS 2 Article 20 place the approval and oversight of ICT and cybersecurity risk management on the management body (2, European Union, 2022) (3, European Union, 2022), as Chapter 4 recorded.

The human side of automation is documented across domains. Bainbridge's paper on industrial process control describes the irony that automation leaves the operator to monitor and to take over when it fails, and that skills deteriorate when they go unused (217, Bainbridge, 1983). A review of complacency and bias in human use of automation found both in naive and in expert participants (218, Parasuraman & Manzey, 2010). Google's chapter on automation records the same warning: that human operators are progressively relieved of useful direct contact with the system, so that their mental models no longer reflect what it is doing (252, Murphy et al., 2017). Cook's note on how complex systems fail adds that practitioners both operate the system to produce its product and work to forestall accidents, and that complex systems require substantial human expertise in their operation (260, Cook, 2000).

What is expected

Expected trends rest on a stated trend or a decided instrument, but their timing is uncertain. They justify preparation: decisions that cost little now and save a great deal if the trend arrives.

Routine diagnosis and catalogued, reversible remediation move to agents at Levels 1 to 3. The products of the previous section exist, measured capability on software tasks is rising (above), and the cost of toil is a standing argument for delegation (Chapter 10). The degrees of Chapter 4 give the shape: read and annotate at the highest level, restart, scale out and certificate renewal at Level 3 Bounded where the observer and the stop exist, and rollback and failover widened one class and one service pair at a time on evidence. Expected, with timing set by each organisation's own records, since no benchmark says that a given estate's runbooks are safe at a higher level.

The bottleneck moves from authoring to verification. If agents draft changes, runbooks, timelines and reviews at the rate Chapters 8, 12 and 16 describe, the scarce activity becomes the independent check, as it became for the security architect (The Transformed Security Architect, Chapter 14). The report of the DevOps Research and Assessment programme points the same way for software delivery: without control systems, more change means more instability (117, Harvey & DeBellis, 2025). Expected.

Regulation tightens the evidence and keeps the person. DORA Articles 11, 12 and 24 and NIS 2 Article 21 are written in terms of testing, recovery and measures, and supervisors can be expected to ask for dated evidence of what was tested and with what result (Chapters 19 and 23). That the management body remains answerable under DORA Article 5 and NIS 2 Article 20 is a decided instrument. Expected; the instruments are decided, and the supervisory practice towards AI remediation agents is not yet visible.

Concentration oversight deepens and provider contracts change. The designation of critical providers has begun, and the requirement of exit strategies for critical or important functions is in force for financial entities. For organisations that buy operations with AI inside, the annex of Chapter 21 and the exit test of Chapter 24 become standard clauses. Expected.

Compute and energy become design constraints for agent-heavy operations. The International Energy Agency reports that data centres used around 415 terawatt-hours of electricity in 2024, about 1.5 per cent of the world's consumption, and its base case projects around 945 terawatt-hours by 2030 (120, IEA, 2025). The 2024 figure is a measurement and the 2030 figure a projection. For an operator the consequence is local: inference for agents competes with production workloads for reserved capacity (Chapters 11 and 15). Expected.

What is speculation

Speculation is plausible but unsupported by present evidence. It justifies keeping a decision reversible, and the most consequential speculations in operations are those that would remove a safeguard.

Unattended recovery of whole estates. An estate in which agents diagnose, choose, execute and verify across services without a person who can read the record is describable. The benchmarks do not support it, the controls it would need have not been shown at that scale, and Chapter 10 labelled it speculation. Speculation.

A provider-run loop with no customer-side observer for a critical function. A provider that operates the service, detects its own faults, remediates and reports on itself would be the case of Chapter 17 in which the observer depends on the observed. DORA Article 28(8) would still require a financial entity to have an exit strategy, and Article 5 would still place responsibility on its management body (2, European Union, 2022). Nothing in the evidence cited shows that such a loop yields fewer or shorter customer-impacting incidents, and a single provider's control plane would be a single point of failure for every customer that adopted it. Speculation, and one the book advises against for Tier 1 services.

The extrapolation of task length to operations. That the time horizon measured on software tasks carries over to diagnosis and change on a live estate, and doubles every seven months for the next decade, is a conditional extrapolation by the authors of the measurement themselves and has not been tested for operations (289, Kwa et al., 2025). Speculation.

No one on call. That a Tier 1 service will have nobody who can be reached, who holds the stop and who answers for the incident is not supported by any instrument or any outcome evidence. The more careful forms of the claim are in the three futures below. Speculation.

An agent that verifies its own work. A loop in which the remediating agent confirms its own fix with the metric it changed, to be trusted on that confirmation, is ruled out by the observer principle, and the research on correlated model errors and on models that often recognise an evaluation is a reason to doubt a verifier drawn from the same family (103, Kim et al., 2025) (105, Needham et al., 2025). Speculation, and the design here excludes it.

Limits: compute, energy, regulation and trust

Four limits bound the trajectories. Compute and energy limit where agents can run and what they may cost: the reserved capacity of an organisation such as Nordvik Region is fixed in advance, and an agent that loops against it consumes capacity that citizen services need (Chapter 15). The pressure is expected, and the control is a cost cap in the mandate that the policy decision point enforces outside the agent. Regulation limits autonomy by assigning duties to persons, as the AI Act, DORA and NIS 2 provisions above do, and the GDPR's rules on decisions about people limit what an agent may do about a named person's access to work (Chapter 23); the limit is observable in the text and expected to move towards more evidence, not less. Trust limits what an agent's own report counts for: the studies of correlated errors and of evaluation awareness are measurements on benchmarks (103, Kim et al., 2025) (105, Needham et al., 2025), and their meaning for an operations agent is the inference of Chapter 17, which is a reason for verification by a probe that does not depend on a model. Skill limits what happens when the agent is unavailable: a skill that is not exercised decays (Bainbridge), and the claim that operators can restore manually is a claim with a date (Chapters 4 and 26).

Three futures for 2036

The futures say how the trends could combine. They are devices for thinking and not forecasts, and none carries a probability. Each label names the trend or instrument it rests on.

Future A: the conductor rota. Large enterprises and public authorities keep a small, named rota of operators who conduct agents at Levels 1 to 3, hold the stop, declare incidents and fail over, and who are paged less often and for heavier decisions. Agents resolve catalogued, reversible work and prepare the rest. The observer and the drills are engineered, owned and tested. Its strength is that accountability sits where the instruments put it; its weakness is cost, and the tendency of a rota that is rarely woken to lose its practice. Label: expected for large regulated groups and for public authorities with Tier 1 services, on the decided instruments cited above; its names and staffing are speculation.

Future B: the bought loop with a verifier. Smaller organisations and many Tier 2 and Tier 3 services are operated by a provider whose agents act under the provider's mandate, and the customer keeps a small team that holds the contract, the independent observer, the exit test and the stop right over what touches its data. Its strength is that scarce skills are pooled; its weakness is that independence depends on contract terms. Label: expected for organisations with few operators, on the resource position of Nordvik Region; speculation as the default for a Tier 1 service.

Future C: the unattended estate. Agents run the estate across providers with a very small human function that audits. Label: speculation. Its parts are observable or expected, and the whole is unsupported by outcome evidence.

Question Future A Future B Future C
Who is paged for a Tier 1 incident A named operator on a rota The customer's small team, and the provider's A human function that audits, or no one
Who verifies a remediation An independent probe owned by the organisation A customer-owned probe, with the provider's evidence Agents, possibly of one family
Where manual capability lives In the rota, drilled with agents off In the customer's exit test and the provider's staff Nowhere unless designed in
What the supervisor asks Who holds the stop and when it was drilled What the contract lets the customer see and stop Who is accountable at all
Main risk A rota that loses its practice Dependence on one provider's loop Unseen failure and no fallback

The futures do not differ on whether an independent observer and a stop path are needed. They differ on who owns them.

The debate

Whether anyone will be on call in 2036 is a question on which serious practitioners disagree. The debate is staged in four steps, as the authoring rule requires.

The case for concern

The case for concern says that the trajectory removes the person who could take over, and that it does so gradually and without any single decision. Capability measured on software tasks has doubled about every seven months since 2019 (289, Kwa et al., 2025), agent products for investigation have reached general availability (291, AWS, 2026), and change volume rises with AI-authored code while stability lags without controls (117, Harvey & DeBellis, 2025). Each step is small and defensible, and each removes a little of the practice that makes the next failure survivable. Bainbridge's irony is the mechanism: the more automation handles the routine, the less the operator exercises the skills that are needed on the day automation fails, and the failure that remains is by selection the hard one (217, Bainbridge, 1983). The evidence on complacency and automation bias covers naive and expert participants (218, Parasuraman & Manzey, 2010), and Google's own account records that operators lose the mental model of what the system is doing (252, Murphy et al., 2017). Concentration compounds it: if a few providers operate most of the estate with their own agents, a failure in one control plane reaches many customers at once. The AWS event of October 2025 began in automation that failed to repair its own state and ended with manual operator intervention (75, AWS, 2025). Those who hold this position conclude that the question is not whether a person will be on call but whether a person who can still do the work will be, and that the answer depends on decisions taken now.

The case for calm

The case for calm answers that operations has repeatedly absorbed automation without losing the operator, and that the present evidence is of agents that are weak where it matters. Google's SRE organisation automated restarts, rollouts and decommissioning for years, credits automation with consistency, an extensible platform and faster repair, and after the decommissioning incident added sanity checks, rate limits and idempotent workflows, which is the pattern of a profession learning to bound its automation (252, Murphy et al., 2017). The benchmarks say that agents resolved about 11 per cent of unseen failures in the cited studies (128, Xu et al., 2025) (225, Jha et al., 2025), and a randomised trial found that experienced developers who believed AI sped them up were measured at 19 per cent slower (231, Becker et al., 2025). A capability curve measured on software tasks is not a curve for incident diagnosis, and its authors say as much. Regulation requires named people: management bodies answer under DORA Article 5 and NIS 2 Article 20, deployers of high-risk systems assign oversight to competent persons under AI Act Article 26(2), and a supervisor will not accept an agent as the accountable party (2, European Union, 2022) (3, European Union, 2022) (1, European Union, 2024). Novel failures call for judgement about the business, the contract and the law that is not in the telemetry. On this view on-call changes in form and not in kind.

Where the positions meet

Both positions accept the following. A stop path outside the platform and a trained person who can use it are the safety net in every future. An independent observer is needed wherever an agent performs and verifies, and the observer must survive the failure of what it observes. Catalogued, reversible work is properly automated and its automation should be measured. Manual capability decays unless it is exercised, and exercising it is a cost that is paid on purpose. And the management body remains answerable, whoever or whatever does the work.

The disagreement that remains is one of proportion and of evidence. The concerned ask how much human practice is the minimum and fear that the minimum will be set by cost; the calm ask what the practice costs and whether the organisation could show, by measurement, that it is needed. Neither side has multi-year outcome evidence from independent incident data comparing estates with and without independent verification and manual practice, and that evidence will not arrive unless organisations record the data that would produce it.

What can be done

For CIOs and heads of operations: decide who is on call for each Tier 1 service in 2030 and 2033 and write it into the delegation profile and the register, so that a change in the organisation chart cannot silently remove the person; review the horizon register twice a year. For SRE and platform leads: widen one action class at a time on the evidence of the autonomy budget, the seeded-fault results and the stop drills, and keep a share of drills with the agents off (Chapter 19). For incident commanders: hold the stop right, drill it quarterly and record the time. For resilience officers and boards: ask what was tested, when and with what result before accepting "recoverable", and ask the same of manual capability. For buyers of managed operations: write a customer-controlled probe, notice of change to the provider's agents and an exit test into the annex (Chapters 21 and 24). For works councils and unions: agree early how roles change, because a move from rota to conductor is a change in the conditions of on-call (Chapter 25). Keep the choice reversible until the register shows that the replacement works.

Verdict

The verdict separates three questions that the title runs together. Whether a named person will answer for each Tier 1 service in 2036, with the authority to stop an agent and to declare and run an incident, is expected, resting on DORA Article 5, NIS 2 Article 20 and, where a system is high-risk, AI Act Articles 14 and 26 (2, European Union, 2022) (3, European Union, 2022) (1, European Union, 2024). Whether that person is called an on-call engineer, an incident commander or an operations conductor, whether they are an employee or a provider's staff, and how often they are woken are speculation, and the least important of the choices. Whether the organisation still has people who can operate by hand and verify an agent's work is decided now, and it is the part leaders can influence.

By function: at O1 Observe, agent-assisted correlation and summarisation are observable, an observer outside the observed is the rule in every future, and the removal of the observer is speculation the book advises against. At O2 Diagnose, agent investigation is observable and its widening to more routine incidents expected, with the accepted diagnosis remaining a named person's decision. At O3 Change, the rising volume of AI-authored change is observable and the shift of effort to policy checks, progressive delivery and verification expected. At O4 Restore, Level 3 for catalogued reversible classes is observable, its widening to rollback and to failover for defined service pairs expected on evidence, and unattended recovery of whole estates speculation. At O5 Sustain, the cost, capacity and energy pressure is expected, the keeping of manual capability is a decision for the organisation, and a route into the craft that needs no routine work is speculation (Chapter 26).

Organisations can influence the catalogue, the ceilings, the probes, the stop and its drills, the contract annex, the share of drills with agents off and the register. They cannot influence how fast the models improve or how a provider operates its own estate, and the design assumes both.

The author's projection

This section is the author's judgement. It goes beyond the evidence of the preceding chapters, it is the part of the book most likely to be wrong, and it is written to be falsified. Each item carries one of the three labels and is marked as the author's judgement. Chapter 31 collects the other projections.

My judgement is that by 2036 a person will still be on call for the Tier 1 services of large European enterprises and public authorities, and that the work will differ from today's in five ways.

  1. Expected (author's judgement): a named human who can be reached within minutes, holds the stop and declares the incident will exist for every Tier 1 service in a large regulated organisation. Pages will be fewer and heavier, concentrated on novel faults, irreversible decisions and decisions with a legal consequence. I hold this with more confidence than the rest.
  2. Expected (author's judgement): Level 3 Bounded will cover catalogued, reversible classes in most such organisations, widened class by class on evidence of the kind the autonomy budget records, and for some organisations failover between a defined service pair. Deletion of production data, restore over existing data and the disabling of observation or the stop will remain with people, because the prohibitions of Chapter 4 follow from reversibility and not from the capability of the models.
  3. Expected (author's judgement): the binding constraint will shift from the capacity to act to the capacity to verify. The organisations that do well will have treated the observer, the stop path and the manual drill as products with owners and budgets before the routine work went.
  4. Speculation (author's judgement): the rota and the conductor role will merge, so that the person on call is the engineer who designs the runbooks, owns the mandates and reviews the agents' proposals. If I am wrong, it is more likely that the two will remain separate roles in large estates with a distinct incident commander.
  5. Speculation (author's judgement): a bought, provider-run loop will be common for Tier 2 and Tier 3 services and for small authorities, and some organisations will extend it to Tier 1. I would advise against that without a customer-controlled probe and a tested exit. If I am wrong, it is more likely that independent evidence from providers' own incident data will show such loops doing better than I expect, and I would then change the advice. A major incident traced to a loop with no independent observer, or to operators who could not operate manually, may settle the debate in practice. I would rather the register settled it first.

On the question of the title: in 2036 a person should answer for what cannot be undone, a pipeline of agents should run what is catalogued and reversible, a probe that does not depend on the agent should confirm the result, and the people who hold the stop should be able to operate the service by hand. Whether they sit in one team, in a rota or in a provider's contract is the least important of the choices, and the one most likely to be decided by cost.

What would change the view

A projection that cannot be falsified is not worth holding. Each trigger has a threshold and belongs in your own register.

  • Independent outcome evidence for unattended operation. If independent incident data from at least two organisations over at least three years showed that autonomous remediation without independent verification and without practised manual operation produced fewer customer-impacting incidents and a lighter tail of severe events than a loop that keeps those properties, I would treat the safeguards as costs that can be dropped more often than I have judged. This is also the first refutation of the book's thesis.
  • Manual practice shown to be unnecessary. If, over four consecutive quarters of your own game days, teams that had not practised manual recovery for twelve months met the restore objective of a drilled claim as often as teams that had, I would worry less about skill decay.
  • A measured end to the correlation, or its confirmation. If your seeded-fault results showed the observer catching at least nine in ten of the faults the remediating agent mishandled, across four quarters, for the rollback class, I would expect Level 3 for rollback sooner; if the catch rate fell towards the agent's own, later.
  • Held-out performance. If an agent's mitigation success on held-out faults in your own estate stayed above nine in ten for the failover class for four quarters, with a passing re-test of the claim and a stop drill inside its target, I would expect Level 3 for that service pair, and not Level 4 for any excluded class.
  • A legal change. If an amendment or a supervisory statement under DORA or NIS 2 allowed accountability for the recovery of critical functions to be met without a named person, my view would need rewriting. I see no sign of it.

Keeping a register in practice

The register of this chapter is a file in version control that is reviewed on a schedule. The example is illustrative and fictional.

Worked example: horizon register HZN-HM-OPS-01

Hansa Mutual's head of Group Site Reliability and Incident Management, Tobias Richter, keeps the register, and the head of operational resilience, who is independent of operations, approves it. It is recorded as AIDR-0977 (dated 2029-02-15) in answer to the question of AIDR-0950 on how far the IT-operations agent's autonomy may reach, and it carries the triggers that the board's first report of 2029-03-31 will rest on. Trend T06 builds on the failover test RST-HM-2027-007, which passed at 1 hour 35 minutes against 2 hours on 2027-10-05 and has stood expired since 2028-04-02 on the 180-day clock, so that the trigger needs a fresh passing test.

horizon_register: HZN-HM-OPS-01
decision_record: AIDR-0977
date: 2029-02-15
keeper: "Tobias Richter"
approver: "head of operational resilience"
consulted: ["group AI governance board", "Konzernbetriebsrat under KBV-IT-2024-OPS"]
review: {every_days: 180, next: 2029-08-14, also_on_trigger: true}
postures: {observable: commit, expected: prepare, speculation: keep_reversible}
trends:
  - {id: T01, label: observable, fn: [O2], claim: "agents draft investigations from telemetry and history", evidence: "src 2703; AIDR-0951 replay", trigger: "top-3 cause hit rate on replayed incidents below 0.60 for 2 quarters", owner: "HM-OPS-002 owner"}
  - {id: T02, label: observable, fn: [O1, O2], claim: "agents resolve a minority of unseen faults", evidence: "src 701, 705", trigger: "held-out seeded-fault mitigation below 0.80", owner: "SRE lead"}
  - {id: T03, label: observable, fn: [O3], claim: "AI-authored change volume rises, stability lags", evidence: "src 306", trigger: "change-correlated incident rate up 2 quarters", owner: "platform lead"}
  - {id: T04, label: observable, fn: [O4], claim: "Level 3 for restart, scale, certificate renewal", evidence: "DLG-HM-OPS-001", trigger: "half the 90-day budget spent in first third", owner: "agent operator"}
  - {id: T05, label: expected, fn: [O4], claim: "rollback reaches Level 3 for catalogued pairs", evidence: "OBS-HM-0001 seeded faults", trigger: "catch rate 0.90 for 4 quarters and stop drill within 5 min", owner: "SRE lead"}
  - {id: T06, label: expected, fn: [O4], claim: "failover Level 3 for Frankfurt to Cloud A payments", evidence: "RST-HM-2027-007", trigger: "3 supervised failovers passed and claim verified within 180 days", owner: "incident commander lead"}
  - {id: T07, label: expected, fn: [O1, O4], claim: "provider oversight and contract change", evidence: "src 311; DORA Art 28(8)", trigger: "a Hansa provider appears on the ESA list", owner: "head of operational resilience"}
  - {id: T08, label: expected, fn: [O5], claim: "compute and energy bound agent use", evidence: "src 310", trigger: "agent budget cap exceeded 2 months running", owner: "HM-OPS-004 owner"}
  - {id: T09, label: expected, fn: [O5], claim: "verification is the bottleneck", evidence: "src 306", trigger: "median age of unreviewed agent proposals over 2 working days", owner: "SRE lead"}
  - {id: T10, label: speculation, fn: [O2, O4], claim: "unattended recovery of whole estates", evidence: "none", trigger: "independent multi-year outcome data", owner: "group CIO"}
  - {id: T11, label: speculation, fn: [O1, O4], claim: "provider loop with no customer-side observer", evidence: "none", trigger: "provider offers autonomous action without notice", owner: "head of operational resilience"}
  - {id: T12, label: speculation, fn: [O5], claim: "route into the craft without routine work", evidence: "none", trigger: "fewer than 2 of 3 new engineers pass manual drill in 12 months", owner: "SRE lead"}

Each trend has a label, the functions concerned, a checkable claim, evidence, a trigger that the loop's own records can compute and an owner. The speculative trends have no evidence by definition, and their triggers say what would change that.

Practical guide: keeping a horizon register for operations

Purpose. Hold the organisation's view of the future of its operations in a form that can be wrong in a reviewable way, and tie each trend to a decision.

Roles. The SRE lead or the platform lead keeps the register. The CIO, or in a regulated entity the head of operational resilience, approves it. The incident commanders, the agent operators, the service owners, the CISO and the employee representatives are consulted, because the register touches roles and on-call.

Steps.

  1. List the trends that bear on operations: at most eight for a small team and fifteen for a large one, including at least one that would be bad news for the plan.
  2. Label each trend and write evidence that a reader can look up. A trend without evidence is speculation. Name its functions by the exact names.
  3. Write a trigger for each trend, taken from the loop's own records where possible, with a threshold and a direction: seeded-fault catch rate, stop-drill time, evidence age, budget consumption, share of drills passed with agents off.
  4. Set a posture by label (commit, prepare, keep reversible) and write what keeping reversible means for each speculative trend, such as the retained manual runbook, the exit test or the stop path.
  5. Record the register in an AI Decision Record with an owner and a review date: every 180 days, and at once when a trigger fires.
  6. Consult the employee representatives before adoption if a trend or posture touches rotas, roles or monitoring of staff. Report results about people for teams and services only.
  7. At each review, record which trends were right and which wrong, and change a label only on evidence.

Definition of done. Every trend has a label, functions, evidence, a trigger and an owner; the register has a review date in the diary; the approver is not the keeper; the employee representatives have seen it; and the last review recorded at least one trend whose label was changed or confirmed by evidence.

Across the degrees of delegation

The table sets the expected ceiling per action class over time. The first column is the present default of Chapters 4 and 10 (observable). The later columns are the register's expectation and the author's judgement, and each is a ceiling that an organisation sets for itself in a delegation profile on its own evidence. No row moves to Level 4 Autonomous for a class that the prohibitions of Chapter 4 exclude.

Function and action class Default now (Chapters 4 and 10) Review of 2030 Review of 2033 Author's judgement for 2036
O1 read, annotate Level 4 (read within data class) Level 4 Level 4 Level 4 (expected)
O1 change an alert, threshold or monitor Level 0 Advisory Level 0 Advisory Level 0 Advisory Level 0 Advisory; never Level 4 (expected)
O2 propose a diagnosis Level 1 Assisted Level 1 to Level 2 (expected) Level 2 (expected) Level 2; a named person accepts the cause (expected)
O3 deploy a pre-approved standard change Level 2 Supervised; Level 3 in progressive delivery Level 3 (expected) Level 3 (expected) Level 3 inside window and freeze (expected)
O4 restart, scale out, certificate renewal Level 3 Bounded Level 3 Level 3 Level 3 (expected)
O4 roll back Level 2 Supervised Level 3 for catalogued pairs (expected) Level 3 (expected) Level 3 (expected)
O4 fail over Level 1 to Level 2 Level 2 (expected) Level 3 for a defined service pair (speculation) Level 3 for some pairs (speculation)
O4 delete production data, restore-overwrite Level 1 Level 1 Level 1 Level 1 or Level 2 with a named person; never Level 4 (expected)
O5 spend, rightsize, retire Level 1 Assisted Level 2 within a cap (expected) Level 2 to Level 3 within a cap (speculation) Level 3 within a cap; a person approves removal (speculation)

The columns are not forecasts. They are what an organisation expects to have the evidence for, and the review is where it finds out.

Nordvik Region and Hansa Mutual

Both organisations adopt a register and both revisit their ceilings in 2030 and in 2033 against evidence, and neither moves a class on the calendar alone. They differ in what the register is for.

Nordvik Region records its register as HZN-NR-OPS-01 in AIDR-0927 (dated 2029-02-13). Maja Lindqvist keeps it, Henrik Dahl approves it, and the CISO, the AI architect, the data protection officer and the chair of the union's joint committee are consulted, as for AIDR-0900. The Region has no Mode 5 agent and its operations assistant NR-OPS-001 is at Level 0 Advisory, so its register concerns the conditions under which a first class could reach Level 3 Bounded: AIDR-0910 (2028-11-06) holds that no scripted runbook reaches Level 3 until OBS-NR-0001 is in force, effective 2028-11-20, with the first quarterly seeded fault in the first quarter of 2029. Its future is B for the services that SamDrift or the hosting provider operate and A for the Tier 1 services it runs itself, and its most important speculative trend is the provider's embedded agent: the Region treats any provider notice of a change in how its agents act as a change request (AIDR-0902), and the trigger is a notice that arrives with no period. Its trend on the route into the craft concerns how a trainee reaches the standard of Joakim Wester, who writes the runbooks and takes the most weekend on-call, when entry tasks are automated (Chapter 26). The agreement MBL-NR-IT-2027-01 applies: results are reported for teams and services and never by name.

Hansa Mutual records its register as HZN-HM-OPS-01 in AIDR-0977 (dated 2029-02-15). Tobias Richter keeps it, the head of operational resilience approves it, and the group AI governance board is consulted. Hansa has a Mode 5 agent in production, so its register concerns the widening of classes: T05 and T06 are the register's version of the question of AIDR-0950, and the answer remains that no level rises without a verified claim, a seeded-fault result and a stop drill inside its target. Its night window, with Ewa Kowalczyk as agent operator, is where the conductor rota is likely to be tested first, and the Konzernbetriebsrat has asked to see the trend on merging rota and conductor, under KBV-IT-2024-OPS-01 on rotas and rest and KBV-IT-2024-OPS-03 on tools that log commands. DORA applies, so Articles 5, 11 and 24 turn the register into evidence that a supervisor can ask for. Nordvik's register is about whether to begin, and Hansa's about how far to go.

Summary

This chapter looked ahead at operations with labels, and it concerns all five functions: O1 Observe, O2 Diagnose, O3 Change, O4 Restore and O5 Sustain. It treated the outlook as a horizon register in which each trend carries a label, the functions it concerns, evidence, a trigger and an owner. Observable are the agent products for investigation, the low measured performance of agents on unseen faults, the rising volume of AI-authored change with lagging stability, automation failures that needed people, the oversight of critical providers and the instruments that require named persons. Expected are the widening of Level 3 class by class on evidence, the shift of the bottleneck to verification and the pressure of compute, energy and concentration. Speculation are unattended recovery of whole estates, a provider-run loop with no customer-side observer for Tier 1 and the claim that no one will be on call.

The debate set the case for concern, that gradual and defensible automation removes the person who could take over and the practice that makes the next failure survivable, against the case for calm, that operations has absorbed automation before, that agents are weak where it matters and that regulation keeps named people. Both accept that an independent observer, a stop path outside the platform and a trained person are the safety net, and neither has multi-year outcome evidence. The verdict is that a named person answering for each Tier 1 service is expected, that the form of the role is speculation and that whether the organisation can still operate by hand is decided now. The author's projection, labelled as such, is that a person will still be on call in 2036 for large organisations' Tier 1 services, with fewer and heavier pages and the binding constraint moved to verification; five thresholds would change it. Nordvik Region and Hansa Mutual adopted registers and will revisit their ceilings in 2030 and 2033 on evidence. Chapter 28 turns to the record, with public cases and anti-patterns analysed by mechanism, and Chapter 31 gathers the author's other projections.

Sources

  1. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union, 12 July 2024. (1, European Union, 2024)
  2. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Official Journal of the European Union, 27 December 2022. (2, European Union, 2022)
  3. European Parliament and Council of the European Union. Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). Official Journal of the European Union, 27 December 2022. (3, European Union, 2022)
  4. Nordqvist, G. (2026). AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. The Transformed Architecture, Book 2. (296, Nordqvist, 2026)
  5. Nordqvist, G. (2026). The Transformed Security Architect. The Transformed Architecture, Book 6. (300, Nordqvist, 2026)
  6. Bainbridge, L. (1983). Ironies of Automation. Automatica 19(6), 775-779. (217, Bainbridge, 1983)
  7. Parasuraman, R. & Manzey, D. H. (2010). Complacency and Bias in Human Use of Automation: An Attentional Integration. Human Factors 52(3), 381-410. (218, Parasuraman & Manzey, 2010)
  8. Nordqvist, G. (2026). AI Blue: How Artificial Intelligence Transforms the Blue Team in European Enterprises and Public Authorities. The Transformed Architecture, Book 8. (302, Nordqvist, 2026)
  9. Amazon Web Services (2025). Summary of the Amazon DynamoDB Service Disruption in the Northern Virginia (US-EAST-1) Region. AWS post-event summary, 19-20 October 2025. (75, AWS, 2025)
  10. Harvey, N. & DeBellis, D. (2025). Announcing the 2025 DORA report: State of AI-assisted Software Development. Google Cloud Blog, 23 September 2025. (117, Harvey & DeBellis, 2025)
  11. International Energy Agency (2025). Energy and AI. World Energy Outlook Special Report, April 2025. (120, IEA, 2025)
  12. EBA, EIOPA and ESMA (2025). European Supervisory Authorities designate critical ICT third-party providers under the Digital Operational Resilience Act. 18 November 2025. (7, EBA, 2025)
  13. Nordqvist, G. (2026). AI Purple: How Red and Blue Learn Together When AI Joins the Loop in European Enterprises and Public Authorities. The Transformed Architecture, Book 9. (304, Nordqvist, 2026)
  14. Xu, J. et al. (2025). OpenRCA: Can Large Language Models Locate the Root Cause of Software Failures? ICLR 2025. (128, Xu et al., 2025)
  15. Jha, S. et al. (2025). ITBench: Evaluating AI Agents across Diverse Real-World IT Automation Tasks. arXiv:2502.05352. (225, Jha et al., 2025)
  16. Murphy, N. R., Looney, J. & Kacirek, M. (2017). The Evolution of Automation at Google. Chapter 7 in Site Reliability Engineering. O'Reilly Media. (252, Murphy et al., 2017)
  17. Cook, R. I. (2000). How Complex Systems Fail. Cognitive Technologies Laboratory, University of Chicago. (260, Cook, 2000)
  18. European Parliament and Council of the European Union. Regulation (EU) 2026/1744 (Digital Omnibus on AI). Official Journal of the European Union, 24 July 2026. (11, European Union, 2026)
  19. Kim, E., Garg, A., Peng, K. & Garg, N. (2025). Correlated Errors in Large Language Models. ICML 2025; arXiv:2506.07962. (103, Kim et al., 2025)
  20. Needham, J. et al. (2025). Large Language Models Often Know When They Are Being Evaluated. arXiv:2505.23836. (105, Needham et al., 2025)
  21. Becker, J., Rush, N., Barnes, E. & Rein, D. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. arXiv:2507.09089. (231, Becker et al., 2025)
  22. Kwa, T., West, B. et al. (2025). Measuring AI Ability to Complete Long Tasks. arXiv:2503.14499; NeurIPS 2025. (289, Kwa et al., 2025)
  23. Tetlock, P. E. (2005). Expert Political Judgment: How Good Is It? How Can We Know? Princeton University Press. (290, Tetlock, 2005)
  24. Amazon Web Services (2026). AWS DevOps Agent is now generally available. AWS What's New, 31 March 2026. (291, AWS, 2026)