At a manufacturing company, a new agent is introduced to help with order recovery. It can read order status, inspect available inventory, review production capacity, check transport updates, and prepare a recommendation when a customer promise is at risk.
The demonstration is impressive. The agent finds a delayed coil, identifies two alternative production slots, drafts a customer message, and suggests a transport change. The project team celebrates a successful pilot.
Then the pilot enters daily operations.
The planner asks whether they are still accountable for the recommendation. The production manager wants to know why a sequence changed without a conversation. Customer service is uncertain whether the draft message is an approved commitment. The IT team owns the integration but not the business decision. The data team owns the model but cannot explain the commercial context. The project manager who coordinated the pilot has moved on to the next project.
The agent has been deployed. The operating model has not.
This is where many promising AI initiatives become uncomfortable. The system does not merely produce another report. It begins to influence who notices a problem, who prepares a response, who approves an action, who carries the risk, and who is expected to learn when the outcome is different from the plan.
Those responsibilities cannot be left to the software interface. They must be designed deliberately.
FAQ targets
By the end of this chapter, you must have answers to these questions:
- What does the operating model for an agentic enterprise mean for manufacturing leaders?
- How can organisations apply this idea in manufacturing?
- What role do people and governance play?
- How can success be measured?
The central argument
Agentic transformation is an operating-model redesign. It changes the relationship between journeys, decisions, teams, funding, capabilities, authority, and learning.
An agent is not an isolated employee replacement. It is a participant in a system of work. It may retrieve information, compare options, prepare an action, call a tool, monitor an outcome, or escalate an exception. Every one of those behaviours creates a question about ownership.
Who owns the decision? Who owns the data? Who owns the policy? Who owns the agent’s behaviour? Who owns the customer or operational outcome? Who funds improvement after the initial launch? Who has the authority to stop the capability?
If the answers are scattered across functional boundaries, the organisation may have a collection of agents but no agentic enterprise.
The practical test is whether the capability helps a specific person make a better choice inside a real decision window. That requires a named owner, visible constraints, feasible alternatives, clear authority, a persistent team, and a record of what happened afterwards.
The most important design decision is therefore not which model to use. It is which operating structure will remain responsible after the excitement of the project has passed.
A fresh perspective: the operating model is social architecture
Technology architecture describes how systems connect. Operating-model architecture describes how people, teams, systems, policies, and funding connect around value.
An agentic enterprise needs both.
The first architecture makes it possible for an agent to read an order, retrieve a schedule, or submit a work request. The second determines whether the action is meaningful, authorised, understood, and improved over time.
This is why an organisation can have excellent data, modern cloud services, and capable models yet still struggle to scale AI. The missing component is often social architecture: persistent ownership, decision rights, incentives, skills, governance, and a way to fund learning after the pilot.
The question to carry through this article is:
What must be designed around the decision so that people and agents can work together without losing accountability?
Why org charts fail journeys
Most manufacturing organisations are structured by functions: sales, customer service, planning, production, quality, maintenance, procurement, logistics, finance, IT, and HR. Functional expertise is necessary. But customer and operational value usually travels across those boundaries.
Order-to-cash is not owned by one department. Reliability is not owned by maintenance alone. Supplier resilience is not owned by procurement alone. A major project is not owned by the PMO alone.
When an agent is added to a cross-functional journey, the existing boundaries become visible. The agent may need to move between systems and responsibilities faster than the organisation’s approval paths allow. It may identify a problem in one function whose solution creates a cost or risk in another.
For example, an order-recovery agent may recommend using a stock coil for a late customer shipment. Planning sees an attractive service recovery. Production sees the loss of material reserved for a different campaign. Sales sees a chance to protect a strategic account. Finance sees a margin decision. Quality sees a specification question. Logistics sees a transport deadline.
The agent has not created the trade-off. It has exposed the fact that the trade-off did not have a clear owner.
Journey-based teams address this weakness. They do not replace functional departments. They create persistent cross-functional ownership around an outcome that no single department can deliver alone.
Persistent journey teams
A project team exists to deliver a defined change. A journey team exists to improve an enduring flow of value.
That difference is crucial for agentic work. Agents change as the context, policies, models, user expectations, and outcomes change. A temporary project can launch the first version. It cannot be the long-term owner of a capability that must learn every week.
A persistent order-to-cash team might include representatives from commercial operations, planning, production, quality, logistics, finance, data, technology, and customer service. It does not require every member to work full-time on the journey. It does require the team to have a stable mission, clear authority, measurable outcomes, and a continuing backlog.
The team’s responsibility could include:
- defining the important decisions along the journey;
- prioritising where agent support should be introduced;
- maintaining policies and approval boundaries;
- reviewing agent recommendations and overrides;
- measuring customer, cost, quality, and working-capital outcomes;
- improving context and data stewardship;
- coordinating changes across systems;
- ensuring that people are trained and heard;
- retiring capabilities that no longer create value.
The team should not become another committee that meets to review dashboards. Its work should be connected to real decisions, real exceptions, and real outcomes.
The Agentic Operating Model Canvas
The framework for this article is the Agentic Operating Model Canvas. It provides a practical way to design an agentic capability before the organisation becomes trapped in technology-first assumptions.
1. Journey
Which enduring flow of value are we improving?
Examples include order-to-cash, plant reliability, quality release, supplier resilience, maintenance planning, or programme delivery. The journey should have a customer or operational outcome, not merely a system boundary.
2. Decisions
Which recurring decisions create delay, avoidable variation, risk, or value leakage?
List decisions rather than generic activities. “Manage orders” is too broad. “Decide whether to split, expedite, reschedule, substitute, or renegotiate an at-risk order” is specific enough to design around.
3. Team
Who persistently owns the journey and its decisions?
Identify the business owner, domain experts, product or capability lead, data steward, agent owner, technology partners, risk owner, and frontline representatives. Avoid assigning ownership to “the project team” when the project ends.
4. Agents
What should the agent sense, interpret, recommend, prepare, execute, monitor, or escalate?
Different decisions may need different agents or different levels of autonomy. The canvas should define the agent’s scope rather than treating “the AI” as a single actor.
5. Authority
What can the agent do, under which conditions, with whose approval?
Define tools, thresholds, restricted actions, escalation, time limits, and separation of duties. Authority must be explicit enough for both people and systems to understand.
6. Funding
How will the capability be funded after the pilot?
Persistent journeys need a product-style funding model that supports operations, reliability, improvement, evaluation, and retirement. A one-time project budget is rarely sufficient.
7. Measures
How will the team know that the journey is improving?
Measures may include service, cost, quality, safety, speed, working capital, employee experience, decision latency, recommendation usefulness, override patterns, and outcome stability.
8. Learning
How will the team learn from outcomes, exceptions, disagreements, and near misses?
Learning requires decision records, feedback loops, retrospectives, model evaluation, policy review, and a safe way for practitioners to challenge the system.
9. Risk owner
Who has the authority and accountability to accept, reduce, transfer, or stop the risk?
The risk owner should be named before deployment. If a risk belongs to everyone, it often belongs to no one.
The canvas is not a form to complete once. It is a living agreement between the business, technology, risk, and workforce.
Decision ownership in a human-agent system
Agentic systems make accountability more important, not less.
Consider five different roles that are often confused:
- The decision owner defines what a good decision means and accepts accountability for the business outcome.
- The domain steward explains the operational context, constraints, exceptions, and language of the work.
- The agent owner is responsible for the agent’s behaviour, tools, configuration, evaluation, and lifecycle.
- The policy owner defines authority, controls, thresholds, and escalation requirements.
- The outcome owner ensures that the result is measured and that learning reaches the team.
One person may hold more than one role in a small use case. The important point is that the roles are explicit.
When an agent prepares a customer recovery plan, the agent owner should not automatically become the decision owner. Technology can make a recommendation possible; it does not decide what the organisation is willing to trade.
Similarly, the decision owner should not be expected to understand every model or integration detail. The operating model must connect specialist responsibilities without hiding accountability behind them.
Skills for the agentic enterprise
The required skills are broader than prompt writing.
Frontline users need practical AI literacy: how the capability works at a high level, what it can see, what it cannot see, how to challenge it, and how to escalate a failure. They need confidence that an override is a legitimate operating action when the context demands it.
Business analysts need to become decision analysts. They must define objectives, alternatives, constraints, decision windows, authority, and outcomes. They must be able to translate between operational language and system behaviour.
Data stewards need to understand meaning and context, not only data quality scores. A perfectly populated field with the wrong business definition can still produce a poor decision.
Product and capability leads need to manage a living service rather than a finished project. They must prioritise learning, reliability, adoption, policy, and retirement.
Risk and compliance teams need to engage early enough to shape useful boundaries rather than arriving only at the final approval gate. Their role is to make controlled value possible.
Managers need to learn how to lead mixed human-agent teams. This includes setting expectations, handling disagreement, interpreting performance, and making sure that automation creates better work rather than silent pressure.
The enterprise should create visible skill paths. People should be able to grow from process expertise into decision design, agent supervision, data stewardship, evaluation, product ownership, or governance. Otherwise, the organisation may build systems faster than it builds the confidence to use them.
Funding beyond the IT project
An agentic capability is not complete when the first release goes live. It requires monitoring, evaluation, retraining, policy updates, integration maintenance, user support, incident response, and continuous improvement.
This challenges traditional project funding. A project budget may pay for the initial build, but who pays for the capability when:
- a policy changes;
- a customer segment behaves differently;
- a model drifts;
- a new plant joins the journey;
- a safety review requires a control change;
- a frontline team identifies a missing context field;
- a low-value action should be retired?
Persistent journey teams need persistent funding. Funding should follow the value stream and decision portfolio, not remain locked inside a sequence of temporary initiatives.
This does not mean that every experiment receives an unlimited budget. It means that funding decisions recognise the full lifecycle: discovery, build, operation, evaluation, improvement, scale, and retirement.
A useful portfolio may contain three categories:
1. Exploratory work to understand whether a decision is suitable for agent support.
2. Product work to operate and improve capabilities that are already creating value.
3. Platform work to provide reusable identity, policy, observability, evaluation, and integration services.
Leaders should be able to see what each category is expected to deliver and what evidence will justify continuation.
Performance measures that do not distort behaviour
The wrong measures can damage an agentic operating model quickly.
If a team is rewarded for the number of agents deployed, it may automate low-value tasks to show progress. If it is rewarded for recommendation acceptance, people may accept poor recommendations to avoid appearing resistant. If it is rewarded for cost reduction alone, it may increase customer, quality, safety, or workforce risk.
Measures should reflect the journey’s actual purpose.
For an order-to-cash team, this may include on-time-in-full performance, promise reliability, recovery lead time, inventory use, expedite cost, customer communication quality, and the number of avoidable exceptions.
For a plant reliability team, it may include unplanned downtime, maintenance risk, spare-part availability, mean time to recover, safe work execution, and the quality of failure learning.
For an agent itself, useful measures include:
- recommendation usefulness;
- decision-window timeliness;
- explanation quality;
- override reasons;
- outcome quality after acceptance;
- false escalation rate;
- tool-call reliability;
- policy violations prevented;
- successful recovery from failure;
- user confidence and workload impact.
The operating model should reward responsible learning, not artificial autonomy.
Governance that enables rather than paralyses
Governance is often described as a set of restrictions. In an agentic enterprise, it is also a way to make authority legible.
People need to know what an agent may do. Agents need machine-enforceable policies. Leaders need evidence that controls work. Risk teams need traceability. Customers and employees need protection of confidential and personal information.
A practical governance system should include:
- an inventory of agents and their owners;
- documented purposes and decision scopes;
- approved tools and data boundaries;
- identity and access controls;
- policy and prompt versioning where relevant;
- approval and escalation paths;
- monitoring and alerting;
- incident and near-miss review;
- outcome evaluation;
- human override and shutdown procedures;
- periodic review for continued value and risk.
Governance should be proportional to consequence. A draft internal summary does not need the same approval chain as a quality release or customer commitment. But every capability needs a clear owner and a safe way to stop.
Architecture for the operating model
The architecture should make ownership and control visible across the technical stack.
At the journey level, map decisions to the products, teams, agents, systems, and outcomes that support them. This prevents a single agent from becoming a hidden dependency across many processes.
An agent registry should show purpose, owner, version, permissions, tools, policies, data sources, evaluation status, and retirement conditions. A workflow layer should route human approvals and exceptions. A policy plane should enforce authority independently of the model’s generated response.
Data stewardship should be assigned to the meaning of information. Someone must own the definition of promise date, available inventory, approved substitute, critical customer, safe operating window, or completed work.
The capability portfolio should connect funding to journeys and outcomes. Observability should connect system activity to decision records, actions, failures, and results.
The goal is not a perfect central architecture. It is a coherent system in which the organisation can answer:
- Which journey does this capability serve?
- Which decision does it support?
- Which team owns it?
- Which authority does it have?
- How do we know it is helping?
- What happens when it fails?
Four operating-model examples
Order-to-cash team
This team owns the customer journey from quote or order through fulfilment, delivery, invoice, and payment. Agents may support order validation, fulfilment planning, delivery monitoring, invoice preparation, payment watching, and reconciliation.
The team must still define where commercial judgement, quality approval, customer communication, and financial authority remain human. Its success cannot be measured by the number of agents. It must be measured by service reliability, recovery quality, cost, and customer trust.
Plant reliability team
This team combines operations, maintenance, engineering, spare-parts, safety, and data expertise. Agents may identify emerging conditions, prioritise work, assemble evidence, and prepare maintenance actions.
The team owns the reliability outcome and the learning from interventions. It must ensure that the agent does not encourage production continuity at the expense of safe work boundaries.
Programme platform team
Complex capital projects need a persistent capability for dependency analysis, risk sensing, scenario preparation, change control, and benefits tracking. The team should remain beyond one project if the organisation expects to reuse what it learns.
Its role is not to automate project managers away. It is to reduce the time spent assembling status and increase the time available for resolving dependencies and making trade-offs.
Supplier resilience team
This team connects procurement, planning, quality, logistics, finance, and operations. Agents may monitor confirmations, identify exposure, compare alternatives, prepare supplier actions, and escalate material risk.
The team needs authority rules for substitutions, expedite decisions, supplier communications, and inventory trade-offs. The outcome is not simply lower purchase price. It is a more resilient supply position at acceptable cost and quality.
Transitioning from projects to products
The transition does not happen by renaming a project manager as a product owner. It requires a different rhythm of work.
Projects often focus on scope, milestones, budget, and launch. Persistent products and journeys focus on outcomes, adoption, reliability, learning, and changing needs.
During the transition, keep a clear handover between exploration and operation. Before a pilot receives ongoing funding, confirm its owner, user group, support model, measures, policies, incident path, and improvement backlog. If these are absent, the pilot may be successful only because a small group of enthusiasts is carrying invisible work.
Create a regular journey review. Bring together operations, technology, risk, and frontline users to examine decisions, outcomes, overrides, failures, and opportunities. This is not a status meeting. It is a working forum for improving the operating capability.
Retirement should also be normal. An agent may become unnecessary because a process changed, a policy changed, or a simpler rule now performs better. A healthy product operating model knows when to stop investing.
A practical transition sequence
First, identify the journey
Choose a flow of value that matters to customers, operators, or enterprise performance. Make the boundaries and outcome explicit.
Second, map the decisions
List the recurring choices, decision owners, constraints, alternatives, and consequences. Identify where people currently rely on memory, spreadsheets, calls, and workarounds.
Third, establish the persistent team
Name the business owner, domain stewards, capability lead, agent owner, risk owner, and frontline representatives. Give the team a continuing mission and access to the decisions it must improve.
Fourth, define the first authority boundary
Decide what the agent may observe, recommend, prepare, approve, or execute. Define the human override and shutdown route before launch.
Fifth, fund learning and operations
Set aside resources for monitoring, evaluation, data stewardship, user support, policy review, and improvement—not only initial construction.
Sixth, measure outcomes
Compare human decisions, agent recommendations, actions, and actual results. Capture disagreement as learning. Adjust the operating model when the evidence shows that ownership or context is wrong.
Seventh, scale carefully
Reuse common platform capabilities while preserving journey-specific objectives and constraints. Expand authority only when the team can demonstrate dependable outcomes and safe recovery.
Questions for leaders
- Which enduring journey are we trying to improve?
- Which decisions within that journey create the greatest value leakage?
- Who owns the outcome after the project team disappears?
- Which role owns the agent’s behaviour and lifecycle?
- What authority can be delegated safely?
- How will we fund operation and learning after launch?
- Which skills must frontline teams develop?
- How will legitimate overrides be protected and learned from?
- Which measures could accidentally reward unsafe automation?
- What would make this capability worth retiring?
Conclusion: agents change the enterprise before they change the org chart
An agentic enterprise is not defined by how many agents it has. It is defined by how deliberately it organises around decisions, journeys, authority, and learning.
The first agent may be introduced through an IT project. The capability becomes real only when a persistent team owns it, users understand it, funding continues, policies are maintained, outcomes are measured, and improvement becomes ordinary work.
This is the deeper operating-model shift. The enterprise moves from temporary delivery to enduring decision capability. Teams become responsible not only for implementing a system but for improving the quality of choices that travel through a journey. Agents become bounded participants. Leaders become stewards of authority, skills, and trust.
The work begins with one journey, one set of decisions, one accountable team, and one honest learning loop. If the team disappears when the project ends, the learning disappears with it.
Disclaimer
Industry situations in this chapter are composite illustrations unless explicitly attributed to a public source. They are not claims about any particular company, plant, vendor, or incident. Implementations must be validated against local safety, quality, cybersecurity, regulatory, contractual, labour, privacy, and data-governance requirements. Agentic capabilities should be introduced within clearly defined human authority, workforce consultation, operational controls, and tested recovery procedures.
#AgenticEnterprise #OperatingModel #ManufacturingAI #AIAccountability #HumanAgentCollaboration #DecisionIntelligence #AITransformation #IndustrialAI #ManufacturingLeadership #ResponsibleAI
