1. Introduction: Autonomous capability requires an autonomous operating model
Organisations that explore agentic AI usually start with the technology. They look at benchmarks, model choices, tool integration and early productivity wins. What receives far less attention is the operating model that has to sit around these agents. Once an AI system can initiate actions, coordinate with other systems or execute multi-step tasks without step-by-step instructions, the traditional way of organising work starts to strain.
This is not simply a question of plugging automation into existing processes. Agentic systems behave differently. They operate at a different pace, rely on different signals and introduce new kinds of failure modes. They require supervision in some places, autonomy in others and structured feedback loops in between. Without an operating model that matches this behaviour, you end up with pockets of impressive technology running inside an organisation that is not designed to support it.
Enterprise architects know this pattern. Whenever a new capability arrives, the organisation has to adapt around it. With agentic AI, that adaptation is not only technical. It touches roles, control points, escalation paths and the broader flow of decision making. If those elements stay tied to pre-AI assumptions, the benefits of autonomy never materialise.
The goal of this article is to outline practical roles, decision rights and process changes that make autonomy dependable.
In the rest of this article, “agentic AI” does not refer to every chatbot or autocomplete feature. It refers to systems that can pursue a goal over multiple steps, decide which actions to take, call tools or other systems and adapt their behaviour based on feedback. Some agents will do this in a narrow domain, others across several systems, but the common trait is that they act with a degree of independence once a goal is set. It is at that point that the operating model needs to adjust.
2. Why traditional operating models break with agentic systems
Most operating models in large organisations rest on a few quiet assumptions. People are the primary actors. Systems are predictable. Workflows move in a mostly linear path from one team to the next. Risk is assessed in cycles: monthly steering, quarterly audits, annual reviews. Those assumptions held reasonably well in an environment of transactional systems and human-driven processes.
Agentic systems violate most of those assumptions at once. They are not just faster versions of existing applications. They initiate actions without waiting for a human click, call external tools, coordinate with other agents and adjust their behaviour based on feedback. They sit closer to the decision layer than to the UI. That creates a gap between the way work is currently organised and the way work is actually executed once agents are introduced.
The first mismatch is about who is acting. In a traditional model, every important change is tied to a person or a clearly scripted system. Approvals, handoffs and responsibilities follow that pattern. When an agent can decide to send a refund, rebook a flight or raise a customer limit within set boundaries, the operating model has to answer a new question: who is responsible for the pattern of those decisions over time. If that answer is vague, accountability gets pushed around whenever something goes wrong.
There is also a mismatch in tempo. Governance and oversight today are usually built as periodic activities. We review a sample of transactions, inspect a few incidents, sign off on controls and move on. Agents operate continuously. They may execute thousands of low-impact actions that are individually harmless but collectively meaningful. A quarterly review that samples a tiny fraction of those actions will not catch drift, bias or unintended side effects in time. The operating model needs monitoring and supervision that run at the same pace as the agents themselves.
Failure looks different as well. Traditional IT failures are often local. A system goes down. A batch job fails. An integration stops working. Agentic failures are more likely to be systematic. One flawed prompt, one mis-specified goal or one incomplete policy can propagate through many agents and many processes at once. You get correlated failures rather than isolated ones. An operating model built around single-system incidents does not cope well with that pattern.
There is a knowledge problem too. Many processes were designed around tacit knowledge. Exceptions are resolved by people who remember how similar cases were handled in the past. As agents start handling more of the routine cases, humans see fewer examples and their expertise erodes. The operating model quietly loses a buffer of judgment that was never documented but always present. Without explicit supervision roles and learning loops, this erosion only becomes visible when a complex case appears and nobody remembers how to handle it.
To avoid this slow loss of expertise, difficult cases should be treated as learning material rather than one-off firefights. When a supervisor or domain expert resolves a complex exception, that resolution can feed back into the system: as a new rule, an updated retrieval source, an adjusted constraint or an example for future evaluation. Over time, this creates a visible record of how judgment has been applied instead of relying on individual memory that may not be there when it is needed.
Finally, traditional operating models assume that control lives in documents and training. Policies sit in PDFs. Procedures sit in SharePoint and onboarding decks. People are expected to internalise them and apply them correctly. Agents do not read policy documents. They respond to code, configuration and data. If the operating model does not include a clear path from policy intent to executable constraints, you end up with an impressive set of governance artefacts that have no real influence on agent behaviour.
None of this means that existing structures are useless. It means they are incomplete for agentic systems. The organisation needs a layer that sits between high-level governance and the low-level execution of agents: explicit roles, decision rights, supervision patterns and technical controls that reflect how these systems actually behave. The rest of this article is about that layer.
3. The core principles of an agentic operating model
Once you accept that agentic systems operate differently, the next step is to define the principles that should guide how the organisation adapts. These principles are not theoretical. They translate directly into how roles are shaped, how decision rights shift and how processes are redesigned. They also help teams avoid two common traps: overestimating how much autonomy you can safely give an agent, and underestimating the organisational work required to support it.
Principle 1: clear responsibility chains
Every agent has a chain of responsibility behind it. Someone designs it, someone deploys it, someone supervises it and someone is accountable for the outcomes. When this chain is unclear, issues get passed around without resolution. When it is explicit, escalation paths become predictable and oversight becomes much easier. This clarity matters even more when agents work across multiple systems or domains, because the impact of their actions does not sit neatly inside one team.
In practice, this chain usually spans several groups. Model and system designers shape what the agent can do. Integrators decide where it is placed in a process. Supervisors oversee day-to-day behaviour. Risk and compliance functions define boundaries. Senior leaders set incentives and risk appetite. If any link in that chain is missing or ambiguous, responsibility will slide to the path of least resistance, usually the team with the least context and the least authority to fix underlying causes.
Principle 2: graded autonomy instead of binary choices
Organisations often treat autonomy as a switch. Either the agent is allowed to work on its own or it is not. In practice, autonomy works better when it is graded. Some tasks require human approval. Others only need monitoring. Some can be fully delegated. The appropriate level depends on the risk profile, the reversibility of the action and the level of confidence in the data. Designing these levels ahead of time gives teams a consistent way to scale autonomy rather than relying on intuition.
A useful way to decide the right level is to look at a few simple factors: the potential harm if something goes wrong, how easy it is to reverse an action, how stable and trustworthy the underlying data is and how much regulatory or reputational exposure is involved. Tasks with low harm, high reversibility and good data are strong candidates for more autonomy. Tasks with the opposite profile are better suited to supervision or full human control, at least initially.
Principle 3: governance expressed as executable constraints
Policies written in documents rarely influence agent behaviour. Agents respond to rules encoded in systems, not intentions expressed in prose. An agentic operating model therefore needs a straightforward path from governance intent to executable constraints. This is where policy engineering becomes essential. When rules are expressed as code, they become testable, observable and enforceable. They also become easier to maintain as business conditions change.
Principle 4: high observability of agent behaviour
If agents act continuously, the organisation needs continuous visibility. Observability here means more than logging. It includes structured timelines of actions, visibility into tool usage, explanations of why decisions were made and signals that highlight drift or anomalies. Without that visibility, supervision becomes guesswork and the organisation loses the ability to evaluate whether autonomy is delivering what it promised.
Principle 5: resilience by design, not by reaction
Agentic systems create new types of failures. A small configuration mistake can propagate through multiple processes. A flawed decision rule can produce a pattern of bad outcomes quickly. Resilience has to become a design principle, not something addressed after incidents occur. This includes thinking through fallback modes, kill paths, isolation boundaries and how to contain correlated failures. When these mechanisms are built in, autonomy becomes safer to scale.
These principles give structure to the rest of the operating model. They describe the conditions under which agents can operate safely and the organisational scaffolding required to make that possible. With these principles established, we can shift to the roles that make this model real in practice.
4. New roles for the agentic enterprise
Introducing agentic systems changes who does what in the organisation. Some responsibilities shift upward into supervision and policy design. Others shift toward monitoring and evaluation. A few are entirely new. These roles are not optional; they are the minimum set needed to keep agentic systems aligned with business intent, risk appetite and day-to-day operations.
In early pilots, you often see the same two or three people being pinged whenever an agent behaves oddly or a decision feels uncomfortable. Formalising roles is how you stop that pattern from turning into a permanent bottleneck.
4.1. The agent supervisor
The agent supervisor is accountable for how agents behave in a specific domain. This person is not writing prompts or developing models. Their job is to watch the pattern of actions over time, maintain the boundaries within which the agent operates and intervene when behaviour moves outside expected parameters. They understand the domain deeply enough to judge whether the agent’s actions are reasonable and have enough technical fluency to work with engineering teams when adjustments are needed.
They look at signals such as intervention rate, escalation volume, completion patterns and the distribution of exceptions. They handle the operational side of autonomy: when to pause an agent, when to retrain it, when to tighten a constraint and when to widen it. In practice, they become the organisational owner of the agent’s day-to-day behaviour.
4.2. The policy engineer
Policies written in documents do not guide an agent’s behaviour. They guide a human’s interpretation of that behaviour. A policy engineer closes that gap by translating governance intent into executable rules. These rules determine what the agent can and cannot do, which actions require approval and how to validate inputs or outputs.
The role sits at the intersection of governance, engineering and domain expertise. It requires the ability to interpret risk controls, work with domain specialists and express those rules in a way that can be enforced by the orchestration layer. When policies are treated as code, they become testable, transparent and easier to update without touching the agents themselves. This separation of concerns matters for scale. As agent portfolios grow, maintaining governance intent through documentation will not be sustainable.
4.3. The AI auditor
Agents produce a stream of actions, decisions and intermediate steps. Without structured oversight, it becomes difficult to understand why an agent made a particular choice or whether a pattern of choices is acceptable. The AI auditor provides that oversight. They review action logs, anomaly reports and escalation histories. They look for drift, bias, unexplained clusters of behaviour and anything that suggests control gaps.
Unlike traditional audit functions that rely on sampling and retrospective investigation, this role uses continuous signals. The aim is to detect issues early and ensure there is enough evidence to reconstruct decisions when needed. As agentic systems become more capable, this role becomes a safeguard for transparency, accountability and regulatory compliance.
4.4. The knowledge architect
Agentic systems depend on the quality, consistency and structure of the knowledge they access. If the underlying information is fragmented or inconsistent, agents will act on incomplete or conflicting signals. The knowledge architect takes responsibility for shaping the semantic layer that agents rely on. This includes designing data structures, curating key sources, maintaining retrieval pipelines and ensuring that knowledge is up to date.
They play a similar role to data architects but with a focus on operational context. Their work determines how well agents understand the organisation, how grounded their decisions are and how confidently autonomy can be scaled. When knowledge governance is weak, autonomy becomes brittle.
In smaller organisations, these roles will often be combined. One person might supervise agents, write policies and review logs. Another might cover both knowledge architecture and AgentOps. That is not a problem in itself. The important part is that the responsibilities are explicit and that someone has the time and authority to carry them out, rather than assuming that “the AI team” will somehow absorb the work informally.
5. Decision rights and governance patterns
Introducing agents into a process forces a basic question: who decides what, and under which conditions. Traditional decision-rights frameworks assume a human actor with a clear reporting line and a known scope of authority. Agentic systems do not fit neatly into that structure. They act within boundaries, but those boundaries need to be stated explicitly. They also change the shape of decisions. Some decisions become smaller and more frequent. Others become aggregated patterns rather than individual approvals.
A practical way to approach this is to define decision rights at three levels: tasks that must be approved by a human, tasks that may be performed autonomously but require monitoring and tasks that can be delegated entirely. This gives teams a structured starting point instead of relying on instinct or comfort level.
Human in the loop
Some actions require explicit approval. These are usually high-impact or difficult to reverse. They might involve financial exposure, regulatory implications or sensitive customer interactions. When an agent proposes such an action, it should pause and request approval from a supervisor. The operating model needs to specify who reviews these requests, how quickly they are expected to respond and what evidence or context is required to make the decision.
Human on the loop
Other actions do not need approval but should be visible. These are the actions where individual mistakes are low-risk but the aggregation of many mistakes could become a problem. In this mode, the agent proceeds on its own, while the supervisor monitors trends, exceptions and anomalies. If the supervisor notices drift or unexpected patterns, they can intervene. This mode places more responsibility on monitoring quality and signal design than on case-by-case decision making.
Human above the loop
Some actions can be delegated entirely, provided strong constraints and fallback paths exist. This mode is appropriate for well-understood, reversible tasks with clear boundaries. The supervisor focuses on outcomes rather than individual actions. They review performance periodically, ensure constraints are up to date and handle exceptions when the agent escalates. This mode scales autonomy without losing oversight.
These patterns become meaningful when the organisation assigns them consistently. If every team invents its own version, autonomy becomes unpredictable. The operating model should define how to classify decisions into these categories, how to adjust them over time and how to move tasks from one mode to another as confidence grows.
Clear decision rights also create healthier accountability. If an agent can approve refunds up to a certain amount, that boundary needs to be written as a policy and validated in code. If a financial limit, a compliance rule or a domain-specific condition requires escalation, that rule should be enforced by the orchestration layer, not by memory or habit. Accountability then shifts from interpreting policy to maintaining policy. This is easier to govern and easier to audit.
Defining these patterns early prevents a common failure mode. Without explicit decision rights, teams either hold back autonomy because they cannot agree who is responsible or they delegate too much because no one is explicitly accountable. Both outcomes slow down adoption. A structured approach gives everyone a shared language for autonomy and a predictable way to expand it safely.
6. Process redesign: before and after agentic adoption
Introducing new roles and decision-rights frameworks is only useful if they translate into different ways of working. Most enterprise processes today were built around human bandwidth, human judgment and human availability. They include handoffs, approvals and control steps that made sense when people were the only ones doing the work. Once agents participate in those same processes, the shape of the work changes. Some steps shrink, others disappear and a few new ones appear where they were never needed before.
A practical way to understand the shift is to compare a familiar process in its traditional form with its agentic version. The point is not to create a perfect future-state diagram. The point is to see how the operating model adjusts when agents carry part of the workflow.
Example 1: customer refund management
Before
Refunds are usually handled by customer service agents following a mix of policy and experience. A customer submits a request, a human checks eligibility, verifies transaction details, applies the correct rule and issues the refund. Exceptions rely on tacit knowledge. Complex cases are escalated. Oversight happens through sampling and quality reviews.
After
An agent handles the initial assessment by checking eligibility rules and transaction data. Straightforward cases are processed automatically within defined limits. The agent supervisor reviews aggregated patterns and intervenes if refund volumes deviate from expectations or if specific categories generate unusual activity. The policy engineer maintains the rules that govern eligibility and approval thresholds. The AI auditor reviews logs for systematic issues such as bias or repetitive exceptions.
The work does not become fully automated. It becomes more structured. Humans step in for ambiguity, policy gaps and exceptions, while the agent handles the repetitive parts with consistent application of rules.
Example 2: travel itinerary corrections
Before
When a customer notices an error in an itinerary, a human agent reviews the booking, identifies the discrepancy, checks availability and coordinates with suppliers if needed. Many steps are manual. Agents switch between systems and rely on their own experience to decide the next move.
After
An agent validates the discrepancy, checks availability and prepares one or more correction options. It explains its reasoning and surfaces the impact of each option. The human in the loop reviews and confirms the correction for high-impact cases, while low-impact adjustments proceed automatically. Supervision focuses on exception handling and pattern recognition. If the agent begins offering options that are technically correct but operationally inconvenient, the supervisor adjusts constraints or updates the retrieval logic that feeds the agent.
Example 3: IT incident triage
Before
Incidents enter the queue. Analysts read descriptions, classify severity, collect diagnostics and route the case to the correct resolver team. The process depends heavily on analyst skill and institutional memory.
After
An agent performs the first layer of triage by reading incident descriptions, pulling logs, checking recent alerts and suggesting a likely category. For common issues, the agent proposes or executes remediation actions. The human analyst oversees the system, reviews conflicting signals, looks for correlations between incidents and ensures that automated remediation does not mask deeper issues. Over time, the analyst becomes more of a supervisor who tunes the rules and less of a dispatcher.
Across these examples, the pattern repeats. The work shifts in three directions. Routine checks, validations and classifications move to agents. Supervision, tuning and pattern monitoring shift to humans. Control logic migrates from documents to code. Processes become more elastic because the organisation can handle more volume without relying proportionally on human capacity. They also become more traceable because agentic participation requires explicit checkpoints and clearer definitions of responsibility.
None of this suggests that processes become simpler. They become more layered. The predictable parts become faster and more consistent. The unpredictable parts require clearer thinking and better tools. This is why process redesign is not an optional step. It is the work required to turn agentic capability into operational reliability.
7. The capability map for agentic operations
An operating model only works when the organisation has the capabilities to support it. Traditional capability maps assume that systems follow predefined workflows and that people fill in the gaps when exceptions occur. Agentic systems do not follow that pattern. They require capabilities that sit between governance, engineering and operations. Without those capabilities, autonomy remains fragile and difficult to scale.
A capability map for agentic operations helps enterprise architects clarify what needs to exist before agents can operate safely. It also helps teams see where the gaps are, which capabilities should be developed first and how they connect to existing structures.
Several capabilities stand out as foundational.
Agent supervision
This capability provides continuous oversight of agent actions. It combines monitoring, intervention, escalation and behavioural tuning. It needs tools that make agent actions observable and people who understand both the domain and the operational context. Without this capability, autonomy is either over-restricted or left unchecked.
Policy engineering
Governance becomes operational only when policies are translated into rules that systems can enforce. This capability includes authoring, testing, validating and updating those rules. It also includes the ability to express business constraints in a precise and unambiguous form. When policy engineering is missing, organisations rely on documentation that agents cannot interpret.
AgentOps and evaluation
Agents need testing environments, behavioural evaluations, scenario simulations and performance tracking. This capability ensures that agents are validated before deployment and monitored after deployment. It gives teams confidence that changes in behaviour are identified early, not discovered through incidents. This does not only mean tracking uptime and latency. It includes behavioural tests that run through realistic scenarios, checks for regressions when prompts or models change and targeted evaluations for bias, robustness and failure patterns. A basic suite of these tests, run before deployment and after every significant change, gives teams a far clearer view of how agents behave than ad hoc spot checks ever could.
Agentic knowledge and memory management
Agents depend on the information they retrieve. If knowledge is inconsistent or poorly structured, autonomy breaks down. This capability ensures that retrieval sources are governed, content is grounded and semantic structures are maintained. It also covers the lifecycle of knowledge: creation, curation, update and retirement.
Safety and assurance
Autonomy requires safety mechanisms that can interrupt actions, apply fallback paths and isolate failures. This capability manages kill-switches, break-glass procedures, exception routing and post-incident analysis. It connects traditional risk management with agent-specific controls.
Simulation and testing
Agents behave differently when conditions shift. This capability allows teams to test agents in controlled environments, explore edge cases and evaluate how well they respond to unexpected scenarios. Without this, autonomy becomes a form of blind trust rather than engineered reliability.
These capabilities do not replace existing ones. They extend them. Enterprise architects should connect them to current capability maps by identifying where each fits: some are part of digital governance, others belong in operations, and a few may sit between engineering and risk. The important point is not where the box lives on the map. The important point is that it exists and that someone is accountable for it.
A clear capability map helps organisations avoid a common pattern where individual teams experiment with agents but no one builds the shared infrastructure needed to scale. Capabilities make autonomy repeatable. They also help leadership understand that the path to agentic operations is not a sprint. It is a deliberate expansion of organisational capacity.
8. Scaling safely: guardrails, fail-safes and escalation models
Once agents move beyond small experiments, safety becomes a design problem, not a checklist. The question is no longer whether a single workflow behaves correctly. The question is how the whole ecosystem behaves when agents interact with each other, with external systems and with changing conditions. Guardrails, fail-safes and escalation models are the mechanisms that keep that ecosystem within acceptable bounds.
Guardrails define what agents are allowed to do. They set the limits of the action space, the conditions under which actions are permitted and the thresholds that trigger escalation. At a technical level, these guardrails are implemented as policies, constraints and access rules. At an operating model level, they represent the organisation’s view of acceptable risk. When guardrails are vague, autonomy grows in unpredictable directions. When they are precise and executable, agents can move quickly without constantly renegotiating boundaries.
Fail-safes answer a different question: what happens when something goes wrong. With agentic systems, it is not enough to assume that individual mistakes will be caught later. The design must assume that mistakes will sometimes be systematic. That means building mechanisms to interrupt agent activity, roll back changes, isolate faults and degrade gracefully instead of failing abruptly. In practice, this can include disabling specific capabilities, switching agents into read-only modes, redirecting flows to human operators or temporarily narrowing the scope of autonomy.
Escalation models connect the technical mechanisms to human response. They define how alerts are raised, who is notified, how quickly they should act and what authority they have to intervene. For agentic systems, escalation cannot be based only on system uptime or error rates. It also needs to pay attention to behavioural signals: unusual patterns of actions, repeated interventions from supervisors, deviations in key metrics or a concentration of activity in specific segments. These are often the early signs that autonomy is drifting away from intended behaviour.
A useful way to think about these elements is as layers of defence. Guardrails prevent most unwanted actions. Fail-safes limit the damage when prevention is not enough. Escalation models ensure that humans can step in with clear authority when automated responses are insufficient. None of these layers works on its own. Together, they turn autonomy from a one-way delegation into a controlled collaboration.
Scaling safely is not about eliminating risk. It is about shaping it. A small team can watch a single agent closely and react to issues as they arise. Once there are dozens of agents acting across core processes, that approach no longer holds. The operating model requires guardrails that are consistent, fail-safes that are well tested and escalation paths that are understood by everyone involved. Otherwise, the organisation is relying on luck where it should be relying on design.
9. Organisational maturity for agentic operations
Not every organisation needs the same level of agentic capability on day one. Trying to jump straight from isolated experiments to fully autonomous operations is usually how projects stall. A more realistic approach is to treat agentic operations as a maturity journey. Each stage adds new roles, controls and capabilities. Each stage also assumes that the previous one is working reliably.
A simple maturity model can help you position where you are today and what to tackle next.
Level 1: experiments
At this stage, agents live in proofs of concept and sandboxes. Individual teams test what is possible, often with narrow use cases and limited access to production systems. There are few formal roles. Oversight is mostly ad hoc. The main risk is that early success is misread as readiness for broad deployment.
Level 2: isolated agents in production
Here, one or two agents support part of a process in a controlled way. They might assist with classification, summarisation or simple task automation. Decision rights are handled locally. Supervision is informal and usually added on top of existing roles. Policy is still expressed mostly as documentation. The organisation has some value, but there is no consistent way to extend it to new domains.
Level 3: supervised autonomy
Agents now participate in several processes. Decision rights are more clearly defined through human-in-the-loop and human-on-the-loop patterns. Supervisors are identifiable, even if they wear multiple hats. Basic monitoring exists. The organisation starts to see repeatable value, but scaling further would put too much strain on the people who supervise and maintain the agents.
Level 4: coordinated multi-agent operations
Agent portfolios expand. New roles such as agent supervisors, policy engineers and AI auditors are explicit. Guardrails and fail-safes are implemented as code, not just as guidance. AgentOps capabilities emerge: evaluation pipelines, test environments, behavioural metrics and shared observability. Processes are redesigned to reflect the new division of work between humans and agents.
Level 5: agentic enterprise with continuous assurance
At this level, agentic operations are treated as a core capability. Autonomy is used where it makes sense and constrained where it does not. Policies, constraints and monitoring are integrated into the broader governance system. Capabilities like simulation, safety and knowledge management are mature. The organisation can introduce new agents without major structural changes because the operating model already knows how to absorb them.
This kind of maturity model is not about labels. It is a tool for conversation. Enterprise architects can use it with leadership to explain why certain investments are needed before autonomy can scale, or why a particular risk tolerance does not align with the current level of supervision and control. It also helps avoid a common misalignment: treating agentic deployment as a series of technical projects while ignoring the organisational capacity required to run them.
10. Conclusion: designing how humans and agents work together
Agentic AI changes more than system diagrams. It changes how work is organised, who holds responsibility and how control is exercised in day-to-day operations. If those changes are left to emerge on their own, the result is usually uneven. Some teams move quickly, others hold back and no one is entirely sure who is accountable when something goes wrong.
The alternative is to treat the operating model as a first-class design object. That means defining clear principles, naming the roles that keep autonomy aligned, specifying decision rights, redesigning key processes and building the capabilities required to supervise and improve agent behaviour over time. It also means accepting that autonomy is not a one-time switch, but a spectrum that can be shaped deliberately.
For enterprise architects, this is familiar territory in a new form. You already connect strategy, technology and organisation for other capabilities. Agentic systems simply bring that work closer to the decision layer. The question is no longer just which systems to build, but how humans and agents share responsibility inside those systems.
A good starting point is modest. Pick a single process, define an agentic role for it, appoint a supervisor, codify a few guardrails and observe what happens. Use that experience to refine your principles, update your capability map and improve your escalation paths. Repeat in the next domain with slightly more autonomy. Over time, these small, deliberate steps add up to something substantial: an operating model where agentic AI is not an experiment at the edge, but a dependable part of how the organisation works.