Enterprise AI is moving from answering questions to taking action.
The first wave of business AI helped users summarise records, draft emails, search knowledge and generate reports. The next wave is agentic.
AI agents are being designed to monitor business conditions, make recommendations, initiate workflows and complete tasks across CRM, finance, procurement, manufacturing, inventory and customer service.
This creates a significant opportunity.
It also creates a new category of risk.
An AI assistant can provide an imperfect answer and ask a human to review it. An AI agent operating within an agentic ERP environment may place a purchase order, promise a delivery date, allocate inventory or change a production schedule before anyone notices that the underlying data was incomplete.
The quality of agentic AI therefore depends on more than the model.
It depends on the data architecture beneath the agent.
An intelligent agent acting on fragmented, delayed or conflicting records does not remove operational problems. It automates them.
From insight to action
Traditional analytics helps a user decide what to do.
Agentic AI is expected to do more of the work itself.
For example, an enterprise agent might:
- Identify a likely stock shortage
- Review open demand and available supply
- Recommend a replenishment quantity
- Select an approved supplier
- Create a purchase requisition
- Route it for approval
- Notify the planner
- Update the expected availability date
This workflow may sound simple. It depends on many data points:
- Current inventory
- Allocated inventory
- Quality-held inventory
- Open sales orders
- Forecast demand
- Open purchase orders
- Supplier lead times
- Minimum order quantities
- Production requirements
- Warehouse capacity
- Approval limits
- Cash constraints
If these records live across several systems, the agent must assemble a reliable operating picture before acting.
The intelligence of the model cannot compensate for missing or stale business context.
The difference between finding data and trusting data
Many AI projects begin with the assumption that the agent can connect to every system.
Technically, that may be possible.
An agent can call APIs, query data warehouses, retrieve documents and invoke workflows across applications.
Access, however, is not the same as trust.
The agent still needs to determine:
- Which system owns each record?
- How current is the information?
- Are identifiers consistent?
- Has a transaction been duplicated?
- Is the status authoritative?
- Is the data complete?
- Are business rules applied equally across systems?
- What should happen when two values conflict?
A human employee may recognise that an inventory report is updated overnight and call the warehouse for confirmation.
An AI agent may treat the report as current unless the architecture explicitly provides that context.
This is why enterprise AI is not only an integration challenge.
It is a data-governance and operational-design challenge.
Fragmented systems create fragmented context
Consider an agent responding to a customer asking whether an order can ship on Friday.
The CRM shows the customer, opportunity and promised date.
The ERP shows the sales order and inventory quantity.
The manufacturing system shows that production is complete.
The quality system shows that the batch is awaiting final release.
The warehouse system shows the physical stock in a dispatch location.
The transport platform shows carrier capacity.
Which system contains the answer?
None of them individually.
The answer exists in the relationships between the records.
The product is physically present but not approved. The order is open but cannot yet be allocated. Production is complete but the stock is not shippable.
An agent working only from the CRM may promise Friday.
An agent working only from the ERP may see enough stock and reach the same conclusion.
An agent with quality context may recognise that the promise depends on release timing.
The more systems involved, the more difficult it becomes for the agent to understand the current operational state.
AI does not fix a broken source of truth
Organisations sometimes treat AI as a way to overcome fragmented systems.
The expectation is that the agent will sit above the applications, retrieve the relevant information and provide one intelligent interface.
This can improve usability. It does not automatically resolve conflicting data.
If three systems contain different customer addresses, the agent still needs a rule for choosing one.
If inventory is synchronised every hour, the agent still works with a potential delay.
If purchase-order status is represented differently across two applications, the agent still needs mapping logic.
If a quality hold has not yet reached the ERP, the agent may act on the wrong availability.
AI can hide complexity from the user while leaving the complexity intact underneath.
That can make the problem more dangerous because the answer appears confident and consolidated.
The user sees one interface and assumes the data is unified, even when the agent is assembling it from several sources with different update cycles.
Agentic systems amplify data quality
Automation has always magnified process design.
A manual error may affect one transaction. An automated rule can repeat the same error hundreds of times.
Agentic AI increases this effect because the agent may evaluate context and initiate multiple connected actions.
Suppose an agent concludes that demand will exceed supply.
It may raise purchase orders, reschedule production, reallocate inventory and notify customers.
If the shortage was caused by outdated inventory data, the business may overbuy material, disrupt the production plan and send unnecessary delay notices.
The problem is not that the agent lacked intelligence.
It acted logically on an incorrect version of reality.
This leads to an important principle:
The more authority an AI agent receives, the stronger the organisation’s data model and operational controls must become.
One data model gives the agent more complete context
When CRM, ERP and operational processes share one platform, the agent can work from connected records rather than synchronised copies.
A customer order can be related directly to:
- The customer account
- The quoted configuration
- Inventory availability
- Production demand
- Purchase requirements
- Quality status
- Shipment activity
- Invoice and payment status
- Service history
The agent does not need to infer the relationship through different identifiers across several applications.
This supports more reliable action.
For example, an agent assessing an order delay can see that:
- The customer is strategically important
- The order contains two product lines
- One line is available
- The other is awaiting quality release
- An alternative batch is available at another warehouse
- Transfer cost is lower than the cost of missing the commitment
- The account manager has approval authority up to a defined amount
The agent can then recommend or initiate a response based on the whole business context.
This is the foundation of AI orchestration on Salesforce: allowing agents to act across customer and operational records held on the same platform.
Customer 360 is not enough for operational agents
Salesforce made Customer 360 a central enterprise concept.
For sales, marketing and service use cases, a connected customer view is essential.
Agentic ERP requires something broader.
An agent handling operational decisions needs Operations 360 as well as Customer 360.
It must understand:
- What the customer wants
- What the organisation has promised
- What inventory is physically and commercially available
- What production can make
- What suppliers can deliver
- What quality has approved
- What finance permits
- What fulfilment can execute
A customer record without operational context may help an agent communicate. It may not help the agent fulfil.
This distinction matters as AI moves into order management, planning, procurement and supply chain.
The agent must connect the customer-facing request with the operational ability to satisfy it.
Practical agentic ERP use cases
The strongest enterprise-agent use cases are not generic chat experiences.
They are focused workflows where the agent has clear data, business rules, permissions and escalation paths.
Inventory shortage management
An agent can monitor projected supply and demand, identify likely shortages and assess possible responses.
It may compare:
- Available stock
- Quality-held stock
- Transferable inventory
- Open purchase orders
- Work-order completion dates
- Alternative items
- Customer priority
- Margin and service impact
The agent can recommend a transfer, expedite a purchase order or revise production priorities.
This only works reliably when those records are current and connected.
Purchase-order orchestration
An agent can review replenishment requirements, supplier terms, lead times, minimum quantities and historical performance.
It can prepare a purchase order, apply approval rules and notify the buyer of exceptions.
If supplier data and inventory data live in separate systems with inconsistent item codes, the agent must first resolve the data problem before it can optimise the purchase.
Manufacturing rescheduling
An agent can identify a disrupted production order and evaluate the effect on downstream demand.
It may consider material availability, labour, work-centre capacity, tooling, maintenance and customer commitments.
It can propose a revised schedule or move work to an alternative resource.
The agent needs live manufacturing and order data. A daily extract is unlikely to be sufficient for a fast-moving shop floor.
Quality and release management
An agent can monitor batches waiting for inspection, identify overdue tests and alert the appropriate quality team.
It may summarise the records required for release or route exceptions for approval.
However, the agent should not treat physically completed stock as available when quality has not released it.
Quality status must be part of the same operational context used for planning and fulfilment.
Order fulfilment
An agent can determine the best way to fulfil a customer order across multiple locations.
It may balance stock availability, shipping cost, customer priority, quality status and promised date.
The recommendation becomes more reliable when order, inventory, warehouse and customer data share one model.
Customer-service resolution
A service agent can explain an order delay, identify the operational cause and propose alternatives.
Instead of telling the customer that the order is “being processed”, it can see that one item is awaiting final inspection and another can ship immediately.
This creates a more useful customer experience because the response reflects the actual operating condition.
The need for permissions and boundaries
Connected data alone is not enough.
Agentic systems also require strong controls over what the agent can see and do.
The organisation should define:
- Which records the agent can access
- Which fields it can update
- Which actions require approval
- Which value thresholds apply
- Which exceptions must be escalated
- Which decisions must remain human
- How every action is logged
- How actions can be reviewed or reversed
An inventory agent may be allowed to recommend a purchase order but not approve one above £10,000.
A service agent may offer replacement stock within a defined policy but require approval for a refund.
A production agent may reschedule work within one facility but not move regulated production between sites.
The objective is not unlimited autonomy.
It is controlled autonomy within clear operational boundaries.
A shared platform can simplify these controls because records, users, permissions, approvals and workflows use the same security framework.
Why real-time matters
The phrase “real-time data” is often used loosely.
For agentic AI, the relevant question is whether the data is current enough for the action being taken.
A one-hour delay may be acceptable for weekly trend analysis.
It may be unacceptable for stock allocation during a high-volume fulfilment period.
A nightly warehouse update may support reporting. It will not reliably support an agent promising same-day delivery.
A delayed quality update may cause an agent to allocate held stock.
The required level of currency depends on the decision.
Organisations should classify agent actions by operational sensitivity and determine the maximum acceptable data delay for each.
The higher the consequence of the action, the more important it is for the agent to act on the transaction record itself rather than an analytical copy.
The implementation order matters
Companies are often tempted to begin with an ambitious autonomous-agent programme.
A better sequence is:
- Define the operational problem.
- Identify the decisions the agent must make.
- Map the data required for those decisions.
- Confirm the source, ownership and currency of each record.
- Remove unnecessary duplication and reconciliation.
- Define permissions, thresholds and approvals.
- Introduce recommendations before full automation.
- Measure outcomes and exceptions.
- Expand autonomy gradually.
This approach exposes data and process weaknesses before the agent is given authority to act.
It also keeps the project focused on measurable business outcomes rather than the novelty of the technology.
AI readiness is operational readiness
An organisation may have excellent models, strong prompts and sophisticated agent frameworks while remaining unprepared for agentic operations.
The limiting factor is often not AI capability.
It is whether the business can provide the agent with a reliable answer to questions such as:
- What inventory is genuinely available?
- Which customer commitment has priority?
- Which supplier lead time is current?
- Which batch is approved?
- Which production order is at risk?
- Which action is permitted?
- Who must approve the exception?
If employees currently answer these questions by combining several applications and personal judgement, an AI agent will face the same ambiguity.
The agent may process the ambiguity faster, but it will not remove it.
Build the operating context before the autonomous workflow
Agentic AI has the potential to change how enterprises plan, buy, produce, fulfil and serve customers.
But the most valuable agents will not be those with the most elaborate conversational interfaces.
They will be those with the clearest operational context.
That context comes from connected records, defined ownership, current status, explicit business rules and controlled permissions.
A fragmented architecture forces the agent to spend its effort assembling and interpreting the business state.
A unified architecture allows the agent to focus on the decision.
This is why data architecture should be treated as part of the AI strategy, not as a separate technical concern.
An agent is only as reliable as the version of the business it can see.
When customer and operational records share one platform, the agent can understand demand, supply, production, quality, fulfilment and financial constraints together.
That is the difference between an AI assistant that talks about the business and an agent that can safely help run it.
