A manufacturer receives a supplier notice that critical components will arrive two weeks late. Planning data suggests a substitute part, a finance forecast shows a margin problem and a sales contract limits delivery delays. An agent can explain these signals together, but a useful enterprise solution must distinguish analysis from commitment. Recommending a substitution is not the same as reserving inventory, revising a purchase order or changing the general ledger. Each action belongs to a controlled business process.
A demand-planning assistant can recommend substituting a delayed component, but reserving stock, changing a purchase order and posting to the ledger require distinct transaction controls. Dynamics 365 finance and supply-chain capabilities can support analysis, while authoritative services own commitments. The architecture work covered by Microsoft AB-100 includes separating evidence and recommendations from approved execution, particularly when one proposed action crosses multiple ERP processes.
Anchor every suggestion in the right ERP state
An inventory forecast, a posted invoice and a pending approval are different kinds of information. A forecasting service may estimate next month’s demand; the ERP transaction ledger records commitments already made. An agent comparing them needs a timestamped, permitted view of each source and must avoid presenting an estimate as a confirmed stock allocation. A generated explanation should make clear whether the statement is about current actuals, a proposed plan or a future scenario.
Many ERP questions involve effective dates, currencies, units and organizational boundaries. A price of 120 could be in a local currency, include taxes or refer to a different subsidiary. Model outputs should preserve the source unit and reference record, and transaction tools should validate them explicitly. A model that converts or rounds a number without an approved rule can create errors too subtle to catch by visual review of its prose.
The source-governance principles in grounding and knowledge sources are particularly important here. Structured business records usually need direct, authorization-controlled lookups rather than a text vector index that may lag behind transactional state. Retrieval can provide policy explanation, while the ERP API remains responsible for the authoritative balance or inventory quantity.
Separate a demand-planning insight from execution authority
A demand-planning assistant can help an analyst investigate changes between forecast periods. It may compare product families, inspect historical demand and summarize contributing factors. That is a decision-support workload with a relatively clear human reviewer. Automating the next step—changing production orders or supplier commitments—introduces financial, operational and safety consequences that require different controls and verification.
Suppose a model recommends shifting 500 units from one distribution center to another. The supply-chain system must verify current allocations, transportation constraints, open sales orders and inventory reservations. Even if the suggestion is plausible, the business workflow should produce a reviewable transfer proposal before posting it. If the proposed quantity exceeds a threshold or touches restricted materials, the relevant human approver must be identified from policy rather than selected by the model.
A narrow task agent may handle exception detection, and a separate approved action service may apply the final decision. That is a more reliable architecture than allowing a conversational assistant to both interpret demand and directly mutate every inventory field. Agentic-first architecture explains responsibility boundaries; here they are shaped by material movement and the ERP’s integrity rules.
Treat finance controls as business logic, not prompt guidance
Finance processes have explicit stages: create, review, approve, post, reconcile and close. Those stages should remain enforceable even when an agent prepares the paperwork. A receivables assistant may identify a likely duplicate invoice and draft a reconciliation note, but it should not both post the journal and approve its own correction. The separation of duties is a system property. It cannot depend on the model remembering an instruction to ask permission.
Tool design should encode allowed operations and required status changes. “Propose write-off” and “post write-off” are different capabilities with different privileges. Every external mutation should have a unique operation reference and a way to detect whether it completed. If a timeout follows a submission, retry only after reconciling the ERP state. A duplicate payment or journal posting is more damaging than a delayed answer in a customer-support conversation.
Use monetary controls that reflect policy: currency, tolerance, legal entity, fiscal period and the reviewer’s authority. A model-generated note can help an approver understand why a discrepancy occurred, but the amount and posting destination should be validated through deterministic services. This is the practical reason to keep powerful business tools behind a narrow execution layer rather than exposing every API field to an autonomous agent.
Coordinate multi-agent work without splitting accountability
A manufacturer may have agents for procurement exceptions, inventory availability and finance impact. They can produce useful independent assessments, yet someone must own the final tradeoff. A coordinator should transfer only the evidence and task context necessary for each specialist. The inventory agent does not need unrestricted access to customer payment information; the finance agent does not need to inspect all employee messages to calculate supplier exposure.
A handoff message should carry a transaction identifier, request scope, source versions, permitted actions and a result status. It should not consist solely of a free-text statement that “another agent approved this.” The target service must verify the authoritative approval record before acting. If a worker provides conflicting data, the coordinator should stop or escalate instead of choosing the most fluent result.
When a procurement recommendation passes between specialists, multi-agent solution design should carry a source record identifier, a decision status and one clear owner for retries. In processes with interdependent postings, even successful responses from every worker are insufficient: the organization must verify action ordering and exception recovery across the order, finance forecast and sales commitment.
Design a cross-app exception rather than a generic chatbot
For a delayed component, the exception workflow might first retrieve the affected production orders, then identify customer commitments, assess alternative suppliers, calculate margin and present options. Each stage can use the service or model best suited to its task. The final output should be a decision package: authoritative references, viable alternatives, a cost and delivery impact, and which approvals are needed before any state change.
Not every step requires generation. Computing available inventory, validating an exchange rate and checking a supplier’s approved status are deterministic operations. Generative models can summarize competing evidence, interpret supplier communications and draft explanations. Keep these roles separate so that a weak model conclusion does not overwrite a correct ledger calculation. If a required service is unavailable, report the missing input and stop the affected decision path.
Contrast this with customer-service and sales agents: the customer workflow optimizes timely, accurate interaction and controlled concessions, while the ERP workflow protects posted records, inventory commitments and period integrity. Both can use Copilot Studio or Foundry capabilities, but their release gates must reflect different failure consequences.
Build audit evidence and data boundaries into every action
Finance and supply-chain systems often contain information with commercial sensitivity, legal-entity boundaries and retention obligations. An agent should receive only the records required for its assigned task. Multi-entity reporting must respect the caller’s organizational scope and distinguish consolidated views from individual entity ledgers. Do not export unrestricted ERP data to a shared index merely to simplify natural-language retrieval.
For each recommendation and mutation, preserve a safe record of source identity, version or effective date, approver, change request and resulting business status. Avoid retaining complete financial attachments in general-purpose telemetry. Investigators should be able to reconstruct whether an error arose in extraction, model reasoning, an unauthorized tool attempt or a downstream posting service. That allows a failure to be corrected at the right boundary.
For an ERP agent, AI governance and security must be enforced through supplier-level permissions, approved purchase-order actions, journal-entry controls and traceable audit evidence. Prompt instructions can help explain a policy, but only transaction services can establish that an update was authorized. When source systems disagree, the process needs a deliberate stop or reconciliation path.
Measure financial and operational outcomes together
A deployment might reduce analyst preparation time while increasing the rate of incorrect inventory adjustments. That is not a net operational win. Monitor forecast-exception resolution time, quantity of approved recommendations, reversal rate, duplicate-operation prevention, cost per correctly resolved exception and the percentage of decisions with inspectable evidence. Human review time belongs in the denominator of any claimed productivity improvement.
Release tests should exercise partial failure, delayed data synchronization, a closed accounting period, supplier substitution and a rejected approval. A model may make the correct recommendation but call the wrong legal entity or use yesterday’s price list. Cross-application agent testing provides methods for validating complete workflows against these conditions. Track the deployed prompts, model versions and tools that participated in each measured outcome.
AB-100 architectural judgment is the ability to match agent capabilities to real business decision rights. Finance and supply-chain agents can make complex information more usable, but they must preserve transaction integrity, source authority and separation of duties. The highest-quality solution may automate analysis quickly while keeping posting and supplier commitments behind deliberate, verifiable human approval.