From deterministic to probabilistic

1. Executive summary 

For three decades, IT delivery and operations have been built on a deterministic assumption: given the same input, the same code, on the same infrastructure, the system will produce the same output. ITIL  change records, SRE error budgets, DevSecOps pipeline gates, project management baselines and sustainability accounting all inherit this assumption. Test once, certify, promote, monitor a known set of states, repeat. 

That assumption no longer holds for an increasing share of production workloads. Generative and agentic AI systems are stochastic by construction. The transformer decoder produces a probability distribution over the next token; identical prompts can — and frequently do — yield non-identical responses. When such a system is wired through the Model Context Protocol (MCP) into ticketing systems, CI/CD pipelines,  knowledge bases, cloud control planes and production data, the probabilistic core now drives deterministic side effects in regulated environments. 

This briefing is a technical assessment, written for practitioners who already own SLOs, change advisory boards, DevSecOps pipelines, FinOps and GreenOps dashboards, or programme plans, and who now have to retrofit them for non-deterministic, tool-using agents. It is not a defence of agentic AI, nor a call to abandon ITIL, DORA or the Site Reliability Engineering book. It is an argument that the frameworks must be re-grounded — from binary pass/fail to distributional, from point-in-time approval to continuous evaluation, from human-paced change to agent-paced change — and that the measurement systems we rely on must be rebuilt to match. 

2. The shift from deterministic to probabilistic systems 

2.1 What "deterministic" used to mean in practice 

Classical IT operations rested on five practical guarantees that legacy frameworks quietly assumed:

• Reproducibility: the same build artefact, on the same configuration, behaves identically.

• Bounded state space: the set of "valid" responses from a service is enumerable and testable.

• Causal traceability: a failure can be localised to a function, a config value or a dependency.

• Stable interfaces: APIs change on release cycles measured in weeks, not seconds.

• Human-paced change: changes are authored, reviewed and released by people on a human cadence. 

Every classical control — regression tests, CAB approvals, runbooks, MTTR targets, security gating in the pipeline — is a downstream consequence of these five guarantees.

2.2 What changes with generative and agentic AI 

A large language model is a probabilistic next-token generator. With temperature greater than zero,  identical inputs produce different outputs. Even with temperature set to zero, floating-point nonassociativity on GPUs, batching effects, mixture-of-experts routing, KV-cache reuse and silent provider side model updates make true bitwise reproducibility a routine illusion in production. The Black Hills  Information Security analysis of MCP explicitly notes the consequence: practitioners are now "connecting  a probabilistic generative language technology to deterministic tools to take direct actions." 

Each of the five guarantees above weakens or inverts: 

2.3 Why this is not just "another wave of automation" 

Earlier waves — scripting, configuration management, infrastructure-as-code, RPA — added speed but preserved determinism. A Terraform plan, however complex, is still a deterministic function of inputs. An agentic workflow is not. The agent chooses which tool to call, when to call it, with what arguments, in what order, based on a probabilistic interpretation of natural-language intent and live context. The  ClickHouse analysis of AI-SRE behaviour observed that a single incident investigation can trigger between  6 and 27 database queries as the agent iterates on hypotheses; the trajectory is not pre-declared. This is a categorical shift, not a quantitative one.

3. The agentic AI and MCP operating surface 

3.1 Agentic AI in one paragraph for operators 

An agentic AI system is an LLM (or ensemble of LLMs) given (a) a goal, (b) memory, (c) a set of tools it may invoke, and (d) the autonomy to plan, act, observe and replan in a loop until the goal is reached or a stop condition trips. The defining property is that the system selects its own action sequence at runtime. For an operator, this means the production trace is no longer a fixed call graph; it is a trajectory through an action space that was not specified at design time. 

3.2 The Model Context Protocol (MCP) — what practitioners actually need to know 

MCP is an open standard introduced by Anthropic in November 2024 and donated to the Linux  Foundation's Agentic AI Foundation in December 2025. It uses JSON-RPC 2.0 as its message format and is inspired in design by the Language Server Protocol. The current authoritative specification version at the time of writing is 2025-11-25. 

Architecturally, MCP defines three roles: 

• Host: the AI application a user interacts with (for example Claude Desktop, an IDE, a custom enterprise agent). 

• Client: a connector inside the host that maintains a dedicated, stateful session to a single MCP  server. 

• Server: a service that exposes tools, resources and prompts (for example a Slack server, a Postgres server, an internal-ticketing server). 

The protocol's significance for practitioners is structural: MCP turns every connected enterprise system into an addressable action surface for an LLM. The March 2025 specification introduced Streamable HTTP  transport and an OAuth 2.1-based authorisation framework, moving MCP from a local desktop standard to a remote, cloud-deployable one. By December 2025, public reporting from Anthropic cited over 97  million monthly SDK downloads and more than 10,000 active MCP servers in production. Adoption now spans Anthropic, OpenAI, Google DeepMind, Microsoft and AWS. 

3.3 Why MCP changes the threat and reliability model 

MCP, as a standard, defines transport and capability discovery; it does not mandate role-based access control, rate limiting, audit logging, sandboxing, or output validation. Those obligations fall to the server implementer. The result is that an enterprise that connects an LLM to thirty MCP servers has, in effect,  granted a probabilistic agent thirty new privileged code paths, many built from reference examples that are explicitly not production-grade. This is the substrate the OWASP Top 10 for LLM Applications (2025)  and the OWASP Top 10 for Agentic Applications (2026) were written for.

3.4 Tool sprawl and the context-window economy 

A practical operational issue, separate from security, is that loading every MCP tool definition into the model's context window is expensive and degrades quality. Anthropic's own engineering guidance on code execution with MCP reports a representative reduction from approximately 150,000 tokens to 2,000  tokens — a 98.7 percent saving — by loading tool definitions on demand through filesystem-style discovery. For practitioners, this means: tool catalogue design is now a reliability and cost concern, not a  UX concern. 

4. ITIL in a probabilistic world 

ITIL remains a useful vocabulary — service value chain, practices, guiding principles — but several of its  34 practices were authored against deterministic assumptions and need explicit reinterpretation. 

4.1 Change enablement 

Standard changes presume that the change is pre-authorised because its risk profile is well characterised.  An agent that composes a multi-step remediation by chaining MCP tools is, in the classical sense,  authoring a new change on every execution. Two practical responses are emerging: 

• Policy-as-code authorisation: the CAB approves classes of agent actions ("may scale stateless workloads up to 2× within region X during business hours"), not specific changes. The agent's trajectory is validated against this policy at runtime. 

• Risk-tiered autonomy: low-risk action classes execute autonomously with post-hoc attestation;  medium-risk classes execute with synchronous human approval; high-risk classes are agent proposed, human-authored. 

4.2 Incident and problem management 

The classical incident lifecycle assumes a finite, knowable cause. Agentic incidents include new failure modes that have no analogue in the ITIL incident model: hallucination cascades inside planning loops,  indirect prompt injection from a retrieved document, tool-confusion where two MCP servers expose lookalike tools, and silent provider-side model updates that change behaviour without any local change record. Problem management practice must be extended to cover model and prompt regression as a first class problem category, with its own known-error database. 

4.3 Service configuration management 

The CMDB scope must expand. Configuration Items for an agentic service include, at minimum: the model identifier and provider, the model version (where exposed), the system prompt revision, the tool schema for every MCP server reachable from this service, the retrieval index version, the evaluation suite version, and the policy bundle. Treating these as untracked operational details is the single most common gap observed in early enterprise deployments. 

4.4 Service level management 

Availability and latency remain measurable. "Correctness" does not, in any deterministic sense. SLOs for agentic services must be defined in distributional terms — for example, a 95th-percentile target for task completion as judged by a stable evaluator, with explicit drift-detection clauses. This is discussed in  Section 7. 

5. Site reliability engineering beyond the four golden signals 

The four golden signals — latency, traffic, errors, saturation — were defined for request/response services with a well-formed error semantic. They remain necessary but are no longer sufficient for systems whose primary failure modes are silent and content-based. 

5.1 New signals practitioners are adding 

• Trajectory length and shape: number of tool calls per task, depth of the planning loop, repetition of identical sub-trajectories. A sudden change is often the first sign of a regression.

• Tool-call distribution drift: statistical divergence (for example KL-divergence) between today's distribution of called tools and last week's, conditional on task type. 

• Grounding rate: the fraction of outputs supported by retrievable evidence, where retrieval is in scope. 

• Refusal and escalation rate: the rate at which the agent declines to act or asks for human input — a leading indicator of both safety posture and over-cautious regressions. 

• Token economics: tokens-per-task and dollars-per-task as reliability signals, because a runaway loop is observable in cost before it is observable in latency. 

5.2 Error budgets reformulated 

Error budget consumption can no longer be computed solely from HTTP error rates. A response that returns 200 OK with a hallucinated answer is, from the user's perspective, a failure. Practitioners are reformulating error budgets as compound objectives: a small budget for hard errors (timeouts, 5xx, tool failures) plus a separate, typically larger, budget for soft failures (groundedness violations, policy-bundle violations, evaluator-detected incorrectness on a sampled stream). 

5.3 Observability for agents 

Three architectural facts make conventional observability stacks inadequate for AI-SRE work. First, an AI  agent investigating an incident issues many more queries than a human — the ClickHouse experiment recorded 6 to 27 per incident — so observability backends optimised for human query rates collapse under agent load. Second, agent reasoning requires long-horizon historical context; legacy 7-to-14-day log retention removes the memory the agent needs to recognise recurring patterns. Third, traces must capture the prompt, the retrieved context, the tool calls and their arguments, and the model response,  not merely the call graph. OpenTelemetry has begun standardising semantic conventions for GenAI spans;  adopting them early is now a defensible default. 

5.4 Toil, and the new toil 

Agentic AI eliminates significant classes of legacy toil — alert triage, log grep, runbook execution — with industry-reported automation of 70–80 percent of routine tasks in mature deployments. It introduces new toil: evaluation-set curation, prompt versioning, drift triage, tool-schema maintenance, policy-bundle review. The aggregate toil budget for a mature SRE team has not fallen as much as the marketing suggests;  it has shifted up the stack. 

6. DevSecOps for probabilistic, tool-using systems 

6.1 The pipeline gate assumption is broken 

Classical DevSecOps places gates in the CI/CD pipeline: SAST, DAST, SCA, IaC scanning, container scanning, policy checks. Each gate assumes that what is scanned is what will run. For an agentic service, what runs is the combination of the model, the prompt, the retrieved context, the tool catalogue and the user input  — none of which is fully knowable at pipeline time. A clean pipeline does not imply a safe runtime. 

6.2 OWASP risk landscape practitioners must internalise 

The OWASP Top 10 for Large Language Model Applications (2025) ranks prompt injection (LLM01) as the leading risk, followed by sensitive information disclosure, supply chain, data and model poisoning,  improper output handling, excessive agency, system prompt leakage, vector and embedding weaknesses, misinformation, and unbounded consumption. The OWASP Top 10 for Agentic Applications (2026),  released in December 2025, adds risks specific to autonomous, tool-using systems — including memory poisoning, tool misuse, identity spoofing across agents, and unbounded autonomy. 

Five of these warrant operational treatment by every DevSecOps team: 

• Indirect prompt injection: malicious instructions embedded in retrieved documents, web pages or tool outputs. The user never types them; the agent reads them and acts. 

• Tool poisoning and lookalike tools: two MCP servers expose tools with similar names and overlapping descriptions; the model selects the wrong one. 

• Excessive agency: the agent holds an OAuth token broader than its current task. The deterministic security mantra of least privilege now applies per-invocation, not per-service.

• Supply-chain risk: compromised models, datasets, plugins or community MCP servers. The blast radius of a poisoned dependency is larger than for a traditional library because it can act, not just be called. 

• Memory poisoning: malicious content written into agent long-term memory in one session is recalled and acted on in another. 

6.3 Controls that work in practice 

• Treat every MCP tool boundary as a trust boundary. Validate inputs, scope tokens to the action,  isolate filesystem and network access, and rate-limit aggressively. 

• Use structured tool outputs and strict output schemas, not free-text returns. A typed contract collapses an entire class of prompt-injection vectors. 

• Shift evaluation left and right. Run prompt-injection, jailbreak and tool-misuse evaluations in CI for every prompt or model-version change, and run a continuous adversarial probe against production. 

• Adopt code-execution mode for MCP where the security model permits, since it reduces context exposure and lets the agent compose tool calls in a sandbox rather than emit them directly. 

• Version prompts, system messages and tool schemas in source control. Treat a prompt change as a code change for review, approval and rollback purposes. 

• Map controls to a published framework (OWASP LLM Top 10, OWASP Agentic Top 10, MITRE ATLAS, NIST AI RMF) rather than inventing a private taxonomy. Cross-organisational audit is becoming the norm. 

7. Why the old metrics mislead, and what to use instead 

7.1 The DORA metrics in an agentic world 

The four DORA metrics — deployment frequency, lead time for changes, change failure rate and failed deployment recovery time, plus the fifth metric, reliability — were derived from research on software delivery teams composed of humans. They remain valid for code authored by humans (and by humans with-Copilot). They become ambiguous when an agent commits, reviews and merges. The 2024 DORA  report itself recorded an unusual decoupling: for the first time the medium-performance cluster posted a lower change failure rate than the high-performance cluster, breaking the long-standing co-movement of throughput and stability metrics. 

Three practical adaptations: 

• Attribute deployments. Tag each deployment with author class (human, human-with-assist,  agent-proposed-human-approved, agent-autonomous). Headline rates without attribution are no longer comparable across teams or quarters.

• Add a rework-rate denominator. Agent-authored changes that revert within hours should be visible as instability, not absorbed into deployment-frequency vanity numbers. 

• Track AI-specific delivery metrics in parallel: evaluation-suite pass rate at merge, prompt-change  frequency, model-version pin currency, eval-coverage of the prompt-and-tool surface. 

7.2 Availability is necessary, not sufficient 

A 99.95 percent availability target tells you nothing about whether the system gave correct answers. For agentic services, an availability SLO must be paired with at least one quality SLO measured by a stable,  version-pinned evaluator running against a sampled stream of production traffic, with drift detection on both the input distribution and the evaluator's own outputs. 

7.3 MTTR for agentic incidents 

MTTR is meaningful when a fix is a code change or a config change. For incidents whose root cause is a silent model update, a poisoned retrieval document, or a prompt-injection campaign, time-to-detect is the dominant component and is often measured in days or weeks. Practitioners report MTTR alongside time-to-detect, time-to-attribute and time-to-evaluator-coverage to avoid hiding the true cost behind a fast revert. 

7.4 A practitioner-grade metric set

8. Sustainable IT and sustainable AI 

8.1 The macro picture 

The International Energy Agency's Energy and AI report (April 2025) and its November 2025 update, Key Questions on Energy and AI, set the scale of the challenge. Global data-centre electricity consumption was approximately 415 TWh in 2024, about 1.5 percent of global electricity. Data-centre electricity demand grew 17 percent in 2025, with AI-focused data centres growing roughly 50 percent. The IEA's central projection takes data-centre electricity demand to about 945 TWh by 2030 — close to a doubling — with  AI-focused facilities tripling. Capital expenditure by the five largest US technology companies on data centre build-out exceeded USD 400 billion in 2025. 

Two facts cut against the simplistic "AI is an energy disaster" framing. First, the IEA finds that the energy per AI task is improving at a rate unprecedented in energy history, with an order-of-magnitude annual improvement per task in recent years. Second, the IEA central scenario projects data-centre emissions reaching roughly 1 percent of global CO2 emissions by 2030 (1.4 percent in a faster-growth scenario) — material, but not dominant. The correct framing is that AI workloads are simultaneously becoming dramatically more efficient and dramatically more numerous, with agentic workloads being a leading driver of the increase. 

8.2 Why classical Green IT metrics are insufficient 

Power Usage Effectiveness (PUE) measures facility overhead, not workload efficiency. A PUE of 1.1 looks excellent and tells you nothing about whether the workload itself is well-architected. For agentic systems,  three additional metrics matter: 

• Energy per successful task. A failed agent loop that consumes 20,000 tokens and returns nothing  is invisible to PUE and visible here. 

• Embodied carbon per inference. Accelerator manufacturing is a material component of lifecycle emissions; concentration of inference on newer, more efficient hardware reduces the per-task footprint. 

• Carbon-aware scheduling rate. The fraction of non-latency-critical inference (batch evaluation,  fine-tuning, embedding refresh) that is shifted in time or space to lower-carbon grid windows.

8.3 Concrete engineering levers 

• Right-size the model. Default to the smallest model that passes the evaluation suite; reserve frontier models for the tasks that demonstrably require them. 

• Cache aggressively. Prompt caching, retrieval caching and response caching each reduce both cost and energy by avoiding redundant computation. 

• Adopt code-execution-mode MCP to reduce per-task context, which directly reduces tokens-per task and therefore energy-per-task. 

• Budget agent autonomy.Cap maximum tool calls and maximum total tokens per task. Unbounded loops are an energy issue before they are a reliability issue. 

• Treat evaluation runs as a sustainability cost centre. Continuous evaluation can rival production inference in energy terms; schedule it carbon-aware where latency permits. 

8.4 Reporting obligations practitioners should track 

The European Union's delegated act on data-centre sustainability requires reporting against defined KPIs on a recurring basis, and the EU Energy Efficiency Directive applies to data centres above a defined size threshold. Microsoft's 2025 environmental sustainability report disclosed a 168 percent increase in electricity consumption since 2020 and a 23.4 percent rise in total emissions, attributing the growth principally to AI and cloud expansion. Comparable disclosures from other hyperscalers are now part of the standard due-diligence pack for procurement and ESG teams. Sustainability is no longer a separate workstream from architecture review. 

9. Project and programme management 

9.1 The plan is no longer the artefact 

Classical project management — whether waterfall, PRINCE2, PMBOK or scaled-agile — produces a plan whose value rests on the predictability of the work. Agentic AI projects routinely violate that predictability in three specific ways: (1) capability frontiers move on the order of months, invalidating point-in-time architectural assumptions; (2) the cost-per-task curve declines so quickly that economic feasibility studies expire faster than they can be approved; (3) regulatory exposure shifts as new guidance is published, often mid-delivery. 

9.2 Practical adaptations 

• Plan for optionality, not certainty. Decompose the work so that model choice, prompt strategy and tool-catalogue scope are decision points held open as long as possible, with reversible commitments.

• Replace scope-baseline change control with policy-baseline change control. Define what the  agentic system must not do, and let the implementation evolve inside that boundary. 

• Make evaluation a deliverable. The evaluation suite is the project's executable acceptance criterion. It must be in scope, estimated and owned, not retrofitted after go-live. 

• Plan for model-version churn. Provider-side updates are a project risk. Mitigate with version pinning where the contract permits, eval-on-update, and shadow traffic. 

• Stage autonomy. Default the first production milestone to human-in-the-loop. Move to human on-the-loop, then to autonomous, only when error-budget consumption stays within targets across a defined window. 

9.3 Earned-value, velocity and the agent paradox 

Earned-value management and story-point velocity both presume that work units consumed correlate with progress. When an agent generates a hundred pull requests in a day, eighty of which are quickly reverted, the velocity number is meaningless without a quality denominator. Programme dashboards should pair every throughput metric with a paired stability or quality metric, drawn from the same time window, and surface the ratio. The 2024 DORA observation — the medium cluster outperforming the high cluster on change failure rate — is the warning shot. 

10. Professional certifications: Why PMP, PMI-ACP, CSM and their peers now need reinterpretation 

The certifications that credential the global project-management profession — PMI's PMP and PMI-ACP, Scrum Alliance's CSM, Scrum.org's PSM, PRINCE2, the SAFe family — were all written for a delivery world dominated by human authorship, human review and human-paced change. Their bodies of knowledge encode assumptions about teams, scope, estimation, velocity and value flow that are reasonable for software written by people and decreasingly reasonable for software composed at runtime by probabilistic, tool-using agents. None of these certifications is wrong; several are actively updating. But practitioners holding them need to know which parts of their training still hold, which parts need adaptation, and which parts are silently misleading. 

10.1 The shared assumption that no longer holds 

Across PMP, PMI-ACP, CSM, PSM, PRINCE2 and SAFe, the foundational assumption is that the unit of work  — a story, a feature, a deliverable, a work package — is authored, estimated and reviewed by humans within a team that owns it end to end. Velocity, story points, earned value, burn-down and burn-up charts,  capacity planning, definition of done, definition of ready and the entire ceremony stack rest on this assumption. When the team includes one or more agentic AI "contributors" that can generate, modify and submit work units at machine cadence — and that produce probabilistic outputs whose correctness is statistical rather than binary — the underlying mathematics of these instruments breaks down. A burn down line that descends because an agent merged forty pull requests overnight, half of which will revert within a week, is not measuring the same thing it used to measure. 

10.2 PMP and the PMBOK Guide 

PMI has been responsive. The PMBOK Guide moved from a prescriptive, process-centric Sixth Edition (49  processes across ten knowledge areas) to a principles-based Seventh Edition (twelve principles, eight performance domains) in 2021, and to an Eighth Edition published in late 2025 that retains the principles and-domains structure, reintroduces approximately forty processes as non-prescriptive guidance, and adds explicit appendices on artificial intelligence, PMOs and procurement. Sustainability is elevated to a distinct concept. This is a meaningful direction, but practitioners should be candid about what the Eighth  Edition does not yet provide: 

• It treats AI primarily as a tool used by the project manager (for scheduling, risk forecasting,  document drafting) rather than as a probabilistic, tool-using participant whose outputs need governance equivalent to a vendor or a junior team member. 

• It does not yet codify policy-as-code as the successor to scope-baseline change control for projects whose deliverable is itself a non-deterministic system. 

• It does not yet provide guidance on evaluation suites as project deliverables, on model and prompt version pinning, or on the operational handover of a probabilistic service to a steady-state team. 

For PMP-credentialed practitioners, the practical implication is that the credential demonstrates competence in the governance vocabulary, not in the operating model required for agentic delivery. The vocabulary must be carried forward; the operating model must be augmented from outside the syllabus. 

10.3 PMI-ACP and the agile family 

PMI-ACP was updated in late 2024 with a revised Exam Content Outline organised around four domains  — Mindset (28 percent), Leadership (25 percent), Product (19 percent), and Delivery (28 percent). The eligibility requirements were also tightened: a secondary diploma, twenty-four months of agile experience in the last five years, and twenty-eight hours of agile training. Renewal remains thirty PDUs every three years. This is a useful modernisation, but PMI-ACP still encodes a team-centric, human-authored view of agile delivery. Scrum, Kanban, Lean, XP and TDD — the methods the certification spans — were designed for human teams. They contain no native concept for an agent that joins a sprint, generates code overnight against a backlog item, opens its own pull requests, and revises its own approach based on CI  feedback. The mindset and leadership domains still apply; the product and delivery domains need explicit augmentation for AI-assisted and agentic delivery.

10.4 CSM, PSM and the Scrum certifications 

Certified ScrumMaster (Scrum Alliance) and Professional Scrum Master (Scrum.org) credential mastery of the Scrum framework as defined by the Scrum Guide. The Scrum Guide (2020 revision) is silent on AI participation because, in 2020, it did not need to address it. Three Scrum mechanics warrant immediate  practitioner reinterpretation: 

• The Developer role. The Scrum Guide defines Developers as the people in the Scrum Team committed to creating any aspect of a usable Increment each Sprint. The role is human. When an agent generates a meaningful share of the Increment, the team must decide whether the agent is a tool used by a Developer, a Developer in its own right (problematic under the Guide), or something the team has not yet named. The honest answer for most teams today is the first, but only if a named human Developer takes accountability for review, evaluation and merge. 

• Velocity and story points. These are calibrated to human cognitive load and human cycle time.  Counting agent-authored stories at the same point value as human-authored stories breaks the calibration. Counting them at zero pretends the work did not happen. Most mature teams are introducing an attribution dimension — author class, review burden, revert rate — alongside the point total. 

• Definition of Done. For agentic output, the Definition of Done must include evaluation-suite pass at merge, prompt and tool-schema version pinning, and an attestation that the change is reproducible under the recorded model version. Without these, "Done" is a label, not a guarantee. 

10.5 PRINCE2 and the predictive frameworks 

PRINCE2 (and PRINCE2 Agile), with their stage boundaries, business cases, tolerances and management products, still serve well for procurement, governance and audit interfaces. Their weakness, in this context, is that they were written around the assumption that a stage plan, once approved, describes the work that will be done. Agentic delivery violates that assumption routinely. Practitioners using PRINCE2  should treat the business case as a living artefact reviewed at each stage boundary against the current cost-per-task and capability curves, treat tolerances in token and dollar terms as well as scope and time,  and treat the model and prompt baseline as a management product in its own right. 

10.6 SAFe and the scaled frameworks 

SAFe, LeSS, Disciplined Agile and the other scaled frameworks coordinate multiple teams against shared cadence and shared architecture. Their PI planning ceremonies, ART structures and value-stream mappings were designed for hundreds of humans, not hundreds of humans plus thousands of agents acting concurrently across shared codebases. The frameworks need three pragmatic additions: an agent inventory and capability register comparable to the team inventory; a cross-team policy bundle that constrains what agents may do without team-level approval; and shared evaluation infrastructure, because uncoordinated per-team evaluation produces correctness regressions at integration points that no team owns. 

10.7 What practitioners should treat as obsolete, adapted, or still valid

10.8 What every certified practitioner should add to their toolkit 

Independently of which credential a practitioner holds, six additions are now baseline competence rather  than specialisation: 

• Literacy in MCP and the agentic operating surface at the level required to discuss tool-catalogue scope, authorisation boundaries and evaluation coverage with engineers. 

• Familiarity with at least one published AI risk taxonomy (OWASP Top 10 for LLM Applications,  OWASP Top 10 for Agentic Applications, NIST AI RMF, MITRE ATLAS) and the ability to map project  risks to it. 

• Comfort with evaluation as a deliverable: scoping it, estimating it, owning it, and reviewing its coverage at gate reviews. 

• A working model of cost and energy per task alongside the traditional cost and schedule baselines. 

• An autonomy-staging plan for every project that introduces agentic components — human-in the-loop, then human-on-the-loop, then autonomous, gated by error-budget and evaluator-pass rate thresholds. 

• Vendor and regulatory literacy: the ability to read a model-provider contract for version-pin clauses, indemnity, and notice of model updates, and to map deliverables against applicable regulation (EU AI Act, sector-specific guidance). 

10.9 A note on the credentialing system itself 

Certification bodies move on multi-year cycles. PMBOK editions appear roughly every four to five years.  The Scrum Guide is updated on a similar cadence. The capability frontier of generative and agentic AI is currently moving on a quarterly cadence, and MCP itself — released in November 2024 and donated to the Linux Foundation in December 2025 — moved from a niche desktop protocol to a multi-vendor industry standard inside twelve months. The gap between the certifying cadence and the technology cadence is structural and will not close. The implication for practitioners is that credentials remain valuable as evidence of disciplined foundations, but cannot be the upper bound of professional competence in this period. Continuous, evidence-based learning — through PDUs, internal evaluation work, post-incident reviews, and direct engagement with the agentic systems being built — is the only sustainable response. 

11. A reference operating model for practitioners 

The following synthesises the preceding sections — including the reinterpretation of professional certifications in Section 10 — into a model that practitioners can map to their own contexts. It is deliberately framework-neutral and intentionally minimal. Each control plane and each loop assumes the certification-level vocabulary (PMP, PMI-ACP, CSM, PSM, PRINCE2, SAFe, ITIL 4) as a starting point and overlays the additions that agentic, MCP-connected systems demand. 

11.1 Five control planes 

• Capability plane. Models, prompts, tools, retrieval indexes, evaluation suites, policy bundles.  Versioned, signed, attestable. Treated as code under source control, with review, approval and rollback paths equivalent to any other production artefact. 

• Delivery plane. Pipelines that build, evaluate and promote artefacts from the capability plane,  with author-attributed DORA metrics, evaluation-suite gates, and paired throughput-and-stability dashboards. Definition of Done extended to include evaluation pass, model and prompt pinning,  and reproducibility attestation. 

• Runtime plane. Hosts, clients, MCP servers, traffic, tokens, telemetry. The plane where determinism is impossible and observability is everything. Trajectory, tool-call distribution, grounding rate, refusal rate and token economics are first-class signals alongside the four golden signals. 

• Assurance plane. Continuous evaluation, adversarial probing, drift detection, policy attestation,  sustainability and cost accounting. Maps every control to a published framework (OWASP LLM Top  10, OWASP Agentic Top 10, NIST AI RMF, MITRE ATLAS) rather than to a local taxonomy. 

• Governance plane. The interface between the technical operating model and the certificatio anchored disciplines of the wider organisation. Business cases, stage boundaries, PI plans, CAB  authorisations, audit evidence, regulatory mapping and vendor contracts live here. The plane that translates probabilistic operations into the deterministic vocabulary that procurement, audit,  finance and regulators still require. 

11.2 Three loops 

• Fast loop (seconds–minutes): runtime guardrails, output validation, policy-as-code enforcement,  anomaly detection on trajectory, autonomous remediation within pre-authorised action classes.

• Medium loop (hours–days): evaluation suites, drift reports, security probing, error-budget burn review, change-class authorisation review, revert-rate and rework-rate triage on agent-authored work.

• Slow loop (weeks–quarters): capability roadmap, vendor contract review, regulatory mapping, sustainability disclosure, project-portfolio re-baselining, autonomy-staging reviews, certification syllabus gap reviews against current practice. 

11.3 Eight non-negotiables 

• Treat the prompt and the tool schema as code. 

• Treat the model identifier and version as a configuration item. 

• Treat every MCP boundary as a trust boundary. 

• Pair every throughput metric with a quality metric and attribute by author class.

• Pair every availability SLO with a correctness SLO measured by a version-pinned evaluator. 

• Budget agent autonomy in tokens, tool calls and dollars before any production exposure. 

• Extend the Definition of Done to require evaluation pass, version pinning and reproducibility attestation. 

• Stage autonomy deliberately — human-in-the-loop, human-on-the-loop, autonomous — gated by  error-budget and evaluator-pass-rate thresholds. 

11.4 Roles and the human accountability map 

Across all five planes, a named human remains accountable for each class of decision. The accountability map below is the minimum a regulator, auditor or post-incident reviewer should be able to read off the operating model without ambiguity: 

• Capability ownership: a named owner per model, prompt, tool catalogue, retrieval index,  evaluation suite and policy bundle. 

• Change authorisation: a named approver per action class, not per individual change, with policy as-code attestation captured at runtime. 

• Incident command: a named incident commander whose authority extends to revoking autonomy, rolling back capability versions and recalling agent sessions. 

• Evaluation custody: a named custodian for the evaluation suite, with the same seniority and independence expected of an internal audit function. 

• Vendor and regulatory liaison: a named owner for each model provider contract and each regulatory mapping, responsible for tracking notice clauses, model-update events and compliance evidence.

12. Conclusion 

The frameworks that built modern IT — ITIL, DORA, the SRE book, DevSecOps, classical project management, Green IT — and the certifications that credentialed the practitioners who deployed them  — PMP, PMI-ACP, CSM, PSM, PRINCE2, SAFe — were not wrong. They were calibrated for a world whose primary surface was deterministic, whose work units were authored and reviewed by humans, and whose change cadence was set by human review. Agentic AI, accelerated by the rapid adoption of MCP as the connective tissue between LLMs and enterprise systems, has changed that surface in less than two years.  The same practitioners who built the deterministic discipline now have to rebuild it on probabilistic foundations, without throwing away the parts that still work. 

The work is concrete. Reformulate error budgets to include correctness. Treat prompts and tool schemas as code. Put the model version in the CMDB. Attribute DORA metrics to author class. Extend the Definition of Done to require evaluation pass and reproducibility attestation. Pair availability with groundedness. Budget energy and tokens per successful task. Map controls to OWASP's LLM and Agentic Top 10 rather than to local taxonomies. Stage autonomy deliberately. Plan for capability churn. Read every credential as evidence of disciplined foundations, not as the upper bound of competence in this period. 

None of this is exotic. All of it is overdue. The certifying bodies are moving — PMBOK reached its Eighth  Edition in late 2025 with an explicit AI appendix, PMI-ACP refreshed its Exam Content Outline in late 2024,  OWASP published its Top 10 for Agentic Applications in December 2025 — but they move on multi-year cycles while the underlying technology moves on quarterly ones. The gap is structural and will not close.  The organisations that internalise that fact first will not be the ones with the largest model bills or the longest list of credentials on the org chart; they will be the ones whose agentic systems remain understandable, governable and improvable a year after launch, and whose practitioners can explain — in the deterministic vocabulary their auditors and regulators still require — exactly why.

illuminem Voices is a democratic space presenting the thoughts of leading Sustainability & Energy writers, their opinions do not necessarily represent those of illuminem.

Track the real‑world impact behind the sustainability headlines. illuminem’s Data Hub™ offers transparent performance data and climate targets of companies driving the transition.

References 

All sources verifiable at the URLs listed; access dates correspond to the preparation of this briefing. 

Anthropic. "Introducing the Model Context Protocol." November 2024. https://www.anthropic.com/news/model context-protocol 

Model Context Protocol. "Specification 2025-11-25." https://modelcontextprotocol.io/specification/2025-11-25 Model Context Protocol Blog. "One Year of

MCP: November 2025 Spec Release." 25 November 2025.  https://blog.modelcontextprotocol.io/posts/2025-11-25-first-mcp-anniversary/ 

Anthropic Engineering. "Code execution with MCP: building more efficient AI agents."  https://www.anthropic.com/engineering/code-execution-with-mcp 

Wikipedia. "Model Context Protocol." https://en.wikipedia.org/wiki/Model_Context_Protocol Black Hills Information Security. "Model Context Protocol (MCP)." October 2025.  

https://www.blackhillsinfosec.com/model-context-protocol/ 

OWASP. "OWASP Top 10 for Large Language Model Applications 2025." https://owasp.org/www-project-top-10- for-large-language-model-applications/ 

OWASP GenAI Security Project. "OWASP Top 10 for Agentic Applications." December 2025.  https://genai.owasp.org/2025/12/09/owasp-top-10-for-agentic-applications-the-benchmark-for-agentic security-in-the-age-of-autonomous-ai/ 

Palo Alto Networks. "OWASP Top 10 for Agentic Applications 2026 Is Here." December 2025.  https://www.paloaltonetworks.com/blog/cloud-security/owasp-agentic-ai-security/ 

International Energy Agency. "Energy and AI." April 2025. https://www.iea.org/reports/energy-and-ai International Energy Agency. "Key Questions on Energy and AI." November 2025.  

https://www.iea.org/reports/key-questions-on-energy-and-ai/executive-summary 

International Energy Agency. News release: "Data centre electricity use surged in 2025." November 2025.  https://www.iea.org/news/data-centre-electricity-use-surged-in-2025-even-with-tightening-bottlenecks driving-a-scramble-for-solutions 

Carbon Brief. "AI: Five charts that put data-centre energy use — and emissions — into context." September 2025.  https://www.carbonbrief.org/ai-five-charts-that-put-data-centre-energy-use-and-emissions-into-context/ Brookings. "Global energy demands within the AI regulatory landscape." 2026.  https://www.brookings.edu/articles/global-energy-demands-within-the-ai-regulatory-landscape/

DORA. "DORA's software delivery performance metrics." https://dora.dev/guides/dora-metrics-four-keys/ Google Cloud DORA. "2024 State of DevOps Report" summary, DX. https://getdx.com/blog/2024-dora-report/

ClickHouse. "Your AI SRE needs better observability, not bigger models." 2026. https://clickhouse.com/blog/ai-sre observability-architecture 

DevOps.com. "Agentic AI in Observability Platforms: Empowering Autonomous SRE." December 2025.  https://devops.com/agentic-ai-in-observability-platforms-empowering-autonomous-sre/

New Relic. "SRE Agent: assistive AI for faster incident investigation." February 2026.  https://newrelic.com/blog/observability/sre-agent-agentic-ai-built-for-operational-reality European Parliament Research Service. "AI and the energy sector." 2025 briefing referencing IEA 2025.  https://www.europarl.europa.eu/RegData/etudes/BRIE/2025/775859/EPRS_BRI(2025)775859_EN.pdf