AI agents for operations: a manager's pilot-to-scale playbook
- 6 hours ago
- 18 min read
AI agents for operations are autonomous software systems that watch live operational signals, reason over them and take authorised actions to correct or optimise workflows without waiting for a human to notice the problem first. The practical implication is significant: rather than a dashboard that flags an SLA breach for a manager to act on, an agent detects the drift, reassigns the work, opens a ticket and logs the outcome before the breach materialises. If you are an operations manager deciding whether to pursue this, the answer is yes — but start narrow.
The immediate next steps are straightforward:
Pick one use case with a clear, measurable outcome — finance reconciliation, incident triage, or supplier document processing are strong starting points.
Secure a single canonical data source and name one stakeholder owner who holds accountability for the pilot.
Define three pilot KPIs and set an explicit approval threshold: which actions the agent executes autonomously and which require a human sign-off.
Sentient Concepts works with operations teams across finance, manufacturing, logistics and insurance to run exactly this kind of structured pilot, from use-case selection through to managed production operations. The architecture guidance in this article follows the principles published by the Azure Architecture Center, and every deployment step is framed against UK GDPR obligations and data residency requirements.
Table of Contents
What is an AI agent, and how does it differ from RPA and chatbots?
What governance and compliance controls does a UK pilot require?
Which toolkits and platforms are available for UK deployments?
Why the “build it and they will run it” assumption is the real risk
Sentient Concepts: from pilot design to production AI operations
What is an AI agent, and how does it differ from RPA and chatbots?
The term “AI agent” is used loosely, so precision matters here. An AI agent for operations is a software system with four defining properties: it monitors a data environment continuously, it reasons over what it observes against a defined goal, it has access to tools (APIs, databases, UIs, messaging systems) to act on that reasoning, and it receives feedback that updates its next decision. That feedback loop is what separates an agent from a script.
Robotic Process Automation (RPA) and traditional scripts are deterministic. They follow a fixed sequence of steps and fail the moment the environment deviates from what the script expects — a changed field name, a new UI element, a missing value. Modern operations agents, by contrast, interpret goal intent and adapt to UI shifts and API version changes rather than relying on brittle, step-by-step instructions. The maintenance overhead drops considerably as a result.
Chatbots are a different category again. A conversational agent answers questions; an operational agent takes actions. The distinction is not cosmetic. When an incident triage agent detects SLA drift in a ticketing system, it does not suggest that someone should reassign the work — it reassigns the work, writes the outcome to the audit log and escalates only if the resolution falls outside its authorised threshold.
When to favour agents over traditional automation: non-linear decisions that depend on context, continuous monitoring across multiple systems, and cross-system actions that require reasoning. When to prefer RPA or scripts: fixed, fully predictable tasks with stable inputs and outputs where the cost of an agent’s reasoning overhead is not justified.
Which AI agent types should operations teams consider?
The ten agent types below represent the most common starting points for operations teams. Each entry covers the operational problem, required data sources, typical autonomous actions and the KPIs that tell you whether the pilot is working.
Predictive maintenance agent. Monitors equipment telemetry and maintenance logs to predict failures before they occur. Data sources: IoT sensors, CMMS, ERP. Actions: raise work orders, adjust maintenance schedules, alert engineers. KPIs: mean time between failures (MTBF), unplanned downtime hours, maintenance cost per asset.
Quality control and inspection agent. Analyses production or process data for defects and deviations. Data sources: MES, vision systems, quality databases. Actions: flag batches, trigger re-inspection, write non-conformance records. KPIs: defect rate, first-pass yield, cost of quality.
Resource allocation and scheduling agent. Matches available resources to demand in real time. Data sources: ERP, capacity planning tools, demand signals. Actions: reallocate capacity, trigger purchase orders, update schedules. KPIs: resource utilisation rate, on-time-in-full (OTIF), schedule adherence. Note: for production scheduling specifically, best practice separates agent reasoning from a deterministic optimiser — the agent configures the solver and proposes plans, while planners approve writes back to the ERP.
Workforce scheduling agent. Optimises shift patterns against demand forecasts and compliance constraints. Data sources: HR systems, demand forecasts, absence records. Actions: generate schedules, flag compliance breaches, propose cover. KPIs: labour hours saved, schedule compliance rate, overtime cost.
Supply-chain optimisation agent. Monitors inventory levels, lead times and supplier performance to prevent stockouts and overstock. Data sources: WMS, ERP, supplier portals. Actions: trigger replenishment, flag supplier delays, rebalance stock. KPIs: inventory days on hand, OTIF, stockout frequency.
Safety and compliance monitoring agent. Watches operational processes for safety deviations and regulatory breaches. Data sources: sensor feeds, incident logs, compliance databases. Actions: raise alerts, log incidents, trigger escalation workflows. KPIs: near-miss rate, compliance audit pass rate, incident response time.
Process documentation and SOP agent. Captures process steps from system logs and drafts or updates standard operating procedures. Data sources: process mining tools, ticketing systems, ERP logs. Actions: draft SOPs, flag outdated procedures, route for review. KPIs: SOP currency rate, documentation time saved.
Incident detection and automated triage agent. Detects operational incidents from monitoring feeds and routes them to the right team or resolves them autonomously within defined limits. Data sources: monitoring platforms, ticketing systems, ITSM tools. Actions: open tickets, reassign work, escalate, close resolved incidents. KPIs: mean time to resolution (MTTR), SLA compliance rate, auto-resolution rate.
Procurement and supplier document processing agent. Extracts, validates and routes data from invoices, purchase orders and contracts. Data sources: email, supplier portals, ERP, document management systems. Actions: extract fields, validate against PO, route for approval or exception handling, write to ERP. KPIs: invoices processed per hour, exception rate, cost per transaction. This use case is particularly well-suited to a first pilot because the data scope is bounded and the ROI is measurable within weeks.
Automated reporting and dashboarding agent. Pulls data from multiple operational systems, assembles reports and distributes them on schedule or on trigger. Data sources: ERP, BI platforms, operational databases. Actions: query, aggregate, format, distribute. KPIs: reporting time saved, data freshness, report error rate.
A short procurement note applies to all ten: during a pilot, configure every agent so that high-stakes actions require explicit human approval. Autonomous execution of low-risk, high-frequency tasks (routing, logging, flagging) can proceed from day one; actions that write back to ERP or trigger financial commitments should remain gated until the pilot has demonstrated reliability.
How should you architect AI agents for operations?
The most common architecture mistake is building a complex, hierarchical multi-agent system on the first deployment. Azure Architecture Center guidance is explicit: match pattern complexity to workflow determinism. Sequential patterns — where each agent completes a defined step and passes its output to the next — are the right starting point for the majority of operational workflows. Hierarchical manager-agent patterns, where a coordinating agent dynamically assigns tasks to specialist workers, are appropriate only when the next step genuinely cannot be predefined.
Sequential vs hierarchical patterns
A sequential pattern works well for incident triage: detect anomaly → classify → assign → log → escalate if unresolved. Each step is deterministic given the output of the previous one. A hierarchical pattern becomes necessary when the workflow branches unpredictably — for example, a supply-chain disruption that requires simultaneous, context-dependent actions across procurement, logistics and finance, where the manager agent must reason about which specialist to invoke and in what order.
The practical architecture for most operations pilots looks like this:
Data sources (ERP, MES, IoT, ticketing, document stores) → Orchestration layer (workflow engine, agent runner) → Specialist agents (each with a single responsibility) → Action connectors (API calls, ERP write-backs, notifications) → Audit and logging layer (tamper-evident, queryable).
Keeping the audit and logging layer separate from the agent logic is not optional — it is the mechanism that makes a deployment auditable under UK GDPR and defensible in a governance review.
Pro Tip: Design each agent to do one thing well. A diagnostic agent, a scheduling agent and a reporting agent coordinated by a lightweight manager is a more resilient architecture than a single agent that diagnoses, schedules and reports. When one component fails, the others continue, and the failure is immediately localised.
Sentient Concepts applies this architecture principle across its end-to-end delivery engagements, separating agent reasoning from heavy deterministic computation — such as CP-SAT solvers for scheduling — so that agents configure and explain plans while solvers handle the computation. This separation avoids the unreliable schedules that emerge when an LLM is asked to do combinatorial optimisation directly.
For teams building their first pilot, the AI agent design patterns documentation from Azure Architecture Center is the most authoritative public reference for choosing between sequential, hierarchical and other orchestration topologies.
What business benefits and KPIs should you expect?
Most successful pilots deliver measurable reductions in manual effort and faster incident resolution within the first three months of configuration and monitoring. The scale of benefit depends heavily on the use case, data quality and the degree of autonomous action permitted.
Benefit category | Example KPIs | Indicative range |
Incident resolution speed | MTTR | Vendor figures suggest substantial reduction in incident resolution time in service operations scenarios |
Operational uptime | Unplanned downtime hours | Vendor figures suggest significant improvement in operational uptime for monitored assets |
Document processing throughput | Invoices processed per hour | Substantial reduction in manual processing effort in document-heavy workflows |
Labour hours saved | Hours per week on manual reporting, triage, scheduling | Varies by use case; measurable within pilot period |
SLA compliance | Percentage of tickets resolved within SLA | Improves as triage and routing are automated |
Cost per transaction | Cost per invoice, per work order | Reduces as agent handles routine cases autonomously |
The figures above for incident resolution and uptime are published vendor performance claims for service operations scenarios and should be treated as indicative rather than guaranteed. Your actual results will depend on data quality, integration depth and the approval thresholds you set.
On ROI timeline, the pattern that Sentient Concepts observes across engagements is consistent with the broader industry: initial measurable value typically emerges within one to three months of a well-scoped pilot going live. Fuller scale ROI — where the agent is handling a material proportion of the target workflow autonomously — arrives in the six-to-eighteen-month window, once integration depth, monitoring maturity and stakeholder confidence have all developed.
The primary cost drivers are integration work (connectors to ERP, MES, ticketing systems), custom optimiser logic, governance infrastructure (audit logging, DPIA compliance), and ongoing model inference costs. The last of these is often underestimated at the pilot stage and should be modelled explicitly before scaling.
The AI-Run Enterprise concept — which unifies process intelligence, automation and conversational AI into always-on execution platforms — represents the strategic end state many operations leaders are working towards. Pilots that deliver measurable KPI improvements are the evidence base that justifies the investment in that broader operating model.
How do you implement AI agents for operations step by step?
Start with a single, tightly scoped use case. The temptation to build a platform first and find use cases later is one of the most reliable predictors of a stalled programme. Define the use case, name the measurable outcomes (three KPIs), identify the stakeholder owner and bound the data scope before writing a line of configuration.
Implementation checklist
Use-case selection. Choose a workflow with high manual effort, measurable outcomes and a bounded data scope. Procurement document processing, incident triage and workforce scheduling are proven starting points.
Data readiness and access. Confirm data owner, schema stability, latency tolerances, PII exposure and whether a representative sample is available for testing. A readiness and data diligence assessment at this stage prevents costly rework later.
Connector inventory. Map every system the agent needs to read from or write to. Identify whether connectors exist, need building, or require API agreements with third parties.
Model selection and tool access. Choose a model appropriate to the reasoning complexity of the use case. Not every operational agent needs a frontier LLM — smaller, faster models are often sufficient for classification and routing tasks.
Approval gating. Define which actions are autonomous from day one and which require human approval. Document the thresholds explicitly.
MLOps and runbook. Define how the agent will be monitored, how drift will be detected, and what the rollback procedure is if the agent behaves unexpectedly. This is not optional — it is the operational backbone of a compliant deployment.
Monitoring and rollback plan. Set up observability before the agent goes live, not after. Log every decision, every action and every exception.
Stakeholder training and change management. The people whose workflows the agent touches need to understand what it does, what it cannot do, and how to escalate. AI change management at this stage determines whether adoption sticks.
Data readiness checklist
Before connecting an agent to a live data source, confirm the following:
Data owner is named and accountable.
Schema has been stable for at least three months, or schema changes are versioned and communicated.
Latency tolerances are documented (does the agent need real-time data or is a fifteen-minute lag acceptable?).
PII exposure is mapped and a lawful basis for processing is confirmed.
A representative sample is available for closed testing before live deployment.
Pilot success criteria
A pilot is successful when: the agent handles a defined proportion of target cases autonomously within KPI thresholds; the audit trail is complete and queryable; the runbook has been tested against at least one exception scenario; and the stakeholder owner has signed off on the results. Scaling decisions should be based on these criteria, not on enthusiasm.
For scaling, the key considerations are orchestration maturity (can the architecture handle more agents without becoming brittle?), cost control for model inference at volume, and whether the team has the internal capability to run managed operations or needs an external partner. Sentient Concepts’ managed AI operations service is designed for exactly this transition point.
What governance and compliance controls does a UK pilot require?
The principal UK constraints are GDPR obligations, data residency and contractual liability for automated actions. These are governance gates, not afterthoughts. An agent that processes personal data without a documented lawful basis, or that takes automated decisions affecting individuals without the required safeguards, exposes the organisation to regulatory risk under the UK GDPR and the Data Protection Act 2018.
Data minimisation and purpose limitation
Agents should access only the data they need to complete their defined task. Purpose limitation means that data collected for one operational purpose cannot be repurposed for a different agent function without a fresh lawful basis. In practice, this means scoping each agent’s data access at the connector level, not at the agent’s discretion.
Lawful basis and DPIAs
Where an agent processes personal data — employee records, customer identifiers, supplier contacts — a lawful basis must be documented before deployment. Where the agent makes or contributes to decisions that have a significant effect on individuals, a Data Protection Impact Assessment (DPIA) is required. The ICO’s guidance on automated decision-making is the authoritative reference for UK deployments.
Data residency and encryption
UK operations teams should confirm that data processed by agents remains within the UK or EEA unless an appropriate transfer mechanism is in place. Cloud-hosted agent infrastructure should be configured to use UK or EEA regions, and data in transit and at rest should be encrypted to current standards.
Contractual and security controls
Supplier contracts for agent platforms should include: no external telemetry without explicit consent; model-agnostic swap clauses so the organisation is not locked to a single model provider; role-based access controls; and clear liability allocation for autonomous actions. Approval thresholds for autonomous actions should be documented in the contract and in the agent’s runbook.
Statistic callout: The UK GDPR requires that where solely automated processing produces decisions with significant effects on individuals, organisations must implement suitable safeguards — including the right to human review. This applies to operational agents that make consequential decisions about employees, customers or suppliers, not just to consumer-facing systems.
For teams new to agentic AI governance, the article on how enterprises should think about agentic AI before it enters workflows covers the organisational readiness questions that precede a compliant deployment.
Which toolkits and platforms are available for UK deployments?
The technology stack for an operations agent deployment spans six categories. Each has distinct evaluation criteria, and UK-specific deployment constraints apply across all of them.
Connectors and integration platforms are the foundation. Without reliable, maintained connectors to your ERP, MES, ticketing system and document stores, the agent has no data to act on. Evaluate connector coverage (does it support your specific ERP version?), latency characteristics, and whether the connector supports write-back as well as read.
Agent builders and orchestration platforms provide the runtime environment where agents are defined, orchestrated and monitored. Microsoft Copilot Studio is one of the most widely deployed options in UK enterprises, with native integration to Microsoft 365 and Azure services. Evaluate model choice flexibility (can you swap the underlying model?), support for sequential and hierarchical orchestration patterns, and the quality of the observability tooling.
Model hosting and inference platforms determine where the reasoning happens. For UK deployments with data residency requirements, on-premises or Virtual Private Cloud (VPC) deployment is often necessary. Azure OpenAI Service with UK South region selection, and self-hosted open-weight models on Azure or AWS UK regions, are the most common configurations. Evaluate latency, cost per token at your expected volume, and whether the deployment supports private networking.
Optimisation engines (solvers) are relevant for scheduling and resource allocation agents. As noted in the architecture section, agents should configure and explain solver outputs rather than attempt combinatorial reasoning directly. CP-SAT and similar constraint solvers are mature, well-documented tools for this purpose.
Observability and audit platforms log every agent decision, action and exception in a tamper-evident, queryable format. This is the layer that makes a deployment auditable. Enterprise-grade agent solutions support on-premise installs and full audit logs as a baseline requirement for regulated industries — not as an optional add-on.
Managed AI operations services cover the ongoing monitoring, model maintenance, runbook management and incident response that keep agents performing reliably in production. For organisations without a dedicated MLOps function, a managed service is often the most cost-effective route to production stability. Sentient Concepts provides end-to-end managed operations, covering deployment, monitoring, evaluation and ongoing optimisation, with no handoff between the team that builds and the team that runs.
What are the most common implementation pitfalls?
The projects that stall share a recognisable pattern. Understanding the failure modes in advance is the most efficient form of risk management.
Over-engineering the architecture too early is the most frequent cause of delayed value. Teams that begin with a hierarchical manager-agent system before they have validated a single sequential workflow spend months on infrastructure that may never be needed. The Azure Architecture Center is explicit on this point: start sequential, introduce hierarchy only when the workflow genuinely requires it.
Building a single monolithic agent for a complex process is the opposite error. A monolithic agent that handles diagnosis, scheduling, reporting and escalation in one reasoning loop degrades in reliability as the process complexity grows. Specialist agents with single responsibilities, orchestrated as a team, scale more reliably and fail more gracefully.
Brittle connectors are the most common operational failure point after go-live. An agent that cannot reliably read from or write to its target systems is not an agent — it is an expensive alert. Invest in connector robustness before investing in agent sophistication.
No observability from day one means that when something goes wrong — and it will — the team has no data to diagnose the failure. Logging every decision and action is not a post-launch task; it is a pre-launch requirement.
Skipping the MLOps runbook is the governance equivalent of deploying without a fire exit. The runbook defines what happens when the agent drifts, when a connector fails, when a model is updated, and when a human needs to take back control. Without it, the first incident becomes a crisis.
Missing stakeholder ownership is the change-management failure that kills technically sound pilots. Every agent deployment needs a named business owner who understands the agent’s scope, approves its thresholds and is accountable for its outcomes. Without that owner, the pilot drifts and the business case evaporates.
Your 30/90/180-day checklist for a compliant pilot
This timeline gives an operations manager a prescriptive path from standing start to a pilot with measurable, auditable results.
30 days: define and prepare
Identify the target use case, name the data owner and secure a stakeholder sponsor with budget authority.
Secure read access to one canonical data source and confirm schema stability.
Define three pilot KPIs with explicit target thresholds (e.g. MTTR reduced by 30%, invoices processed per hour doubled, SLA compliance above 95%).
Set approval thresholds: document which actions the agent will execute autonomously and which require human sign-off.
Complete a data readiness check: PII mapping, lawful basis, latency tolerances, sample availability.
Confirm data residency requirements and select infrastructure accordingly.
90 days: build, test and measure
Complete the pilot build with sequential orchestration, specialist agents and a separate audit logging layer.
Run closed testing on a representative sample before any live data is processed autonomously.
Measure outcomes against the three KPIs defined at day 30.
Refine approval thresholds and monitoring rules based on test results.
Run a stakeholder tabletop exercise on autonomous actions: what happens if the agent makes an unexpected decision?
Confirm the MLOps runbook covers monitoring cadence, drift detection, rollback procedure and escalation path.
180 days: evaluate and scale
Conduct a formal cost/benefit analysis against the original KPI targets.
Decide which actions are ready for expanded autonomous execution and which remain gated.
Evaluate orchestration maturity: is the architecture ready to support additional agents without becoming brittle?
Model inference costs at the target scale and confirm they are within the operational budget.
Decide whether to build internal managed operations capability or engage a partner for ongoing runbook management and monitoring.
If scaling, review the AI operating model design to confirm roles, governance and escalation paths are defined for production.
Pilot success template: log every agent decision with a timestamp, the input data, the action taken and the outcome. Run acceptance tests against at least five representative exception scenarios before expanding autonomous scope. The minimal rollback procedure is: disable autonomous actions, revert to human-in-the-loop for the affected workflow, and notify the stakeholder owner within one hour of detection.
Key takeaways
AI agents for operations deliver measurable value when scoped narrowly, governed rigorously, and scaled only after a pilot has demonstrated reliable, auditable performance against defined KPIs.
Point | Details |
Start narrow and measurable | Pick one use case, define three KPIs and set explicit approval thresholds before building anything. |
Match architecture to complexity | Use sequential agent patterns first; introduce hierarchical manager-agent designs only when the workflow genuinely cannot be predefined. |
Governance is non-negotiable | UK GDPR, data residency, tamper-evident audit trails and DPIA where required are baseline requirements, not optional additions. |
Separate reasoning from computation | For scheduling and optimisation, agents should configure and explain solver outputs rather than perform combinatorial reasoning directly. |
Sentient Concepts for end-to-end delivery | Sentient Concepts covers strategy, data readiness, build, deployment and managed operations with no handoff between teams. |
Why the “build it and they will run it” assumption is the real risk
There is a persistent assumption in operations AI programmes that the hard part is building the agent. Get the model right, wire up the connectors, and the business value follows automatically. The evidence from deployments across finance, manufacturing and logistics suggests the opposite: the build is the easier half.
The harder half is what happens after go-live. Model drift, connector failures, schema changes in upstream systems, edge cases the pilot never encountered, and the gradual erosion of stakeholder confidence when the agent makes a decision nobody can explain — these are the forces that end programmes. They are not technical failures. They are operational failures, and they are almost always traceable to the absence of a managed operations function with clear accountability.
The organisations that extract sustained value from intelligent agents for workflow are the ones that treat the agent as a production system from day one: with runbooks, monitoring, escalation paths and a named owner. The ones that treat it as a project — with a go-live date and a handoff — tend to find that the agent works well for three months and then quietly stops being trusted.
This is why the architecture and governance sections of this article spend as much time on audit trails, approval thresholds and rollback procedures as on agent design patterns. The technical architecture is the foundation. The operational architecture is what keeps the building standing.
Sentient Concepts: from pilot design to production AI operations
Cutting the time from use-case selection to a live, measurable pilot is where most operations teams lose momentum. Sentient Concepts delivers end-to-end AI engagements that cover strategy and readiness, data and platform engineering, custom agent build, deployment and MLOps, and ongoing managed operations — with one accountable team across the entire lifecycle. There are no handoffs between a strategy consultancy, a build partner and a run team; the same people who design the pilot are the ones who keep it running.
A typical engagement moves from use-case prioritisation and data readiness assessment to a live pilot in eight to twelve weeks, with measurable KPI results and a managed runbook handover at the end. For supply-chain and manufacturing teams, the supplier document processing use case has delivered material reductions in manual processing effort and cost per transaction. For finance and operations teams, the AI strategy and roadmap service provides the use-case prioritisation and governance framework that makes a pilot fundable and defensible internally.
If you are ready to define your first agent pilot or want a short assessment of your data readiness and use-case options, contact Sentient Concepts to arrange a conversation.
Useful sources
The following primary sources are recommended for architects, legal teams and operations leaders who need to validate architecture and governance choices independently.
AI agent design patterns — Azure Architecture Center: The authoritative reference for sequential, hierarchical and other orchestration topologies. Use this for architecture decisions and for justifying pattern choices to technical reviewers.
Microsoft Copilot Studio: Microsoft’s agent builder for UK enterprise deployments, with native Azure integration. Use this for platform selection and connector evaluation.
ICO guidance on automated decision-making and profiling: The UK Information Commissioner’s Office guidance on Article 22 obligations, DPIAs and individual rights in automated decision-making. Use this for legal and compliance review of any agent that makes consequential decisions about individuals.
Gartner — AI agents: Analyst perspective on agent maturity, adoption patterns and strategic framing. Use this for internal business case development and executive briefings.
World Economic Forum — agentic AI in financial services: Covers autonomy, efficiency and inclusion implications of agentic AI in regulated financial services. Use this for governance and risk discussions in finance and insurance contexts.
FAQ
What is the difference between an AI agent and RPA?
RPA follows fixed, deterministic scripts and fails when the environment changes; an AI agent reasons over live data, adapts to changes and takes goal-directed actions across multiple systems. The key distinction is adaptability: agents interpret intent, RPA executes steps.
How long does a first AI agent pilot typically take?
A well-scoped pilot with a single use case, a clean data source and defined KPIs typically reaches a live, measurable state within a few months. Fuller scale ROI generally arrives several months after the pilot validates the approach.
Which AI agent use case is best for a first operations pilot?
Procurement and supplier document processing is a strong first pilot because the data scope is bounded, the ROI is measurable in weeks, and the approval gating is straightforward. Incident triage is equally well-suited for teams with mature ticketing infrastructure.
What UK compliance obligations apply to operations AI agents?
UK GDPR requires a documented lawful basis for processing personal data, a DPIA where agents make consequential automated decisions, and data residency controls. The ICO’s guidance on automated decision-making is the primary reference for UK deployments.
Can Sentient Concepts manage AI agents in production after the pilot?
Yes. Sentient Concepts provides managed AI operations covering monitoring, model maintenance, runbook management and incident response, with the same team accountable from pilot build through to ongoing production operations.
Recommended