The demo always ends at the insight. The agent reads purchase order data, identifies an anomaly, and surfaces a recommendation. The room nods. Then someone asks: “and then what? Does it update the record?” The room goes quiet. That is the moment the real project begins.
Write-back is where enterprise agent projects fail or succeed. It is where the architectural decisions that were skipped in the prototype phase become unavoidable.
The Write-Back Problem Nobody Solves in the Demo
Agent demos are built around the safe half of the loop: read ERP data, generate insight, summarize in a readable format. The model performs well at that. The read operations are idempotent. Mistakes are visible and correctable. Nobody’s payroll is affected.
Production is different. The agent needs to write back: update a purchase order status, close a ticket, reclassify a transaction, trigger an approval workflow, create a supplier record. These operations are not idempotent. Wrong entity resolution creates duplicate records. Incomplete transactions leave the ERP in an inconsistent state. Duplicate writes corrupt data that downstream systems depend on. And unlike a hallucinated RAG response that a user can discard, a bad ERP write requires a human to find it, understand it, and manually correct it.
Three failure modes account for most write-back incidents:
Wrong entity resolution. The agent receives “update the order for Carlos Lima” and finds two records that match the name, one for an employee and one for an external contact. Without a disambiguation step, it picks one. It picks the wrong one 40% of the time, which is 40% of the time too often when the operation is irreversible.
Incomplete transaction. The ERP workflow requires three steps: create record, attach document, trigger approval routing. The agent completes steps one and two. An API timeout interrupts step three. The ERP is now in an inconsistent state: a record exists, a document is attached, but the approval workflow was never triggered. The next person to look at the record cannot tell whether the process was completed or abandoned.
No rollback plan. The agent initiates a multi-step workflow. Step four fails. There is no defined rollback procedure for steps one through three. Manual correction takes four hours. The agent project is paused pending governance review.
These are not LLM problems. They are software architecture problems. They have software architecture solutions.
Entity Resolution Before Write-Back
The cardinal rule of ERP write-back: never write to a record using a name string. Always resolve to a canonical identifier first.
Entity resolution is a dedicated lookup layer between the agent and the ERP. It receives natural language input, queries the ERP’s own identity model, returns the canonical identifier for the target record, and provides a confidence score and disambiguation information.
The architecture: the agent produces a structured intent object (“update purchase order for supplier X, change status to approved, amount Y”). The entity resolution layer receives that object, queries the ERP for records matching supplier X, returns zero or more candidates with confidence scores. If one candidate exceeds the confidence threshold, the identifier is passed to the write-back layer. If no candidate exceeds the threshold, the agent halts and surfaces the ambiguity for human resolution.
The confidence threshold is not arbitrary. It is calibrated against your specific ERP data quality. ERPs with clean master data tolerate a higher threshold. ERPs with years of legacy data, duplicate records, and inconsistent naming conventions require a lower threshold and more frequent human resolution gates. The entity resolution layer reveals your ERP data quality before it affects production operations.
For TOTVS Protheus, SAP, or Oracle: entity resolution must respect the ERP’s own identity model. Protheus uses its own entity identifier schema. Imposing an external identity model on top of it introduces a mapping layer that becomes a maintenance liability. Query the ERP’s own entity identifiers through its own API.
The Human-in-the-Loop Architecture for ERP Actions
Every ERP action an agent can take should be classified before the agent runs, not after it fails.
The classification framework:
| Action type | Reversibility | Approval requirement |
|---|---|---|
| Read | N/A | None |
| Low-risk write | Reversible, low business impact | Log and execute |
| High-risk write | Reversible, significant business impact | Human approval before execution |
| Irreversible | Cannot be undone | Dual approval with full audit log |
This classification is a software configuration, not a model instruction. The agent does not decide which category an action falls into at runtime. The categories are defined at design time, mapped to action types, and enforced by the orchestration layer.
Approval channels that work in practice: a Slack message with approve and reject buttons, an email with a signed approval token, or an internal portal queue with notification. The approval interface should show the approver exactly what the agent intends to do, in plain language, with the business context that motivated the action. “Approve closing PO-2891 (supplier: ABC Manufacturing, amount: CHF 45,000, reason: delivery confirmed by warehouse system on 2026-04-12)” is approvable. “Agent proposes write operation to ERP record ID 2891” is not.
One design principle from the 12-Factor Agents framework: human approval is a system component, not an exception path. Build the approval workflow before the first agent action touches production data. If the approval workflow does not exist when the agent reaches a high-risk action, it will either skip the approval (producing the incident) or halt with no escalation path (producing the support ticket).
ERP transactions are often non-atomic. If an agent initiates a multi-step workflow, the rollback plan must be defined and tested before the first step executes. Not “we will figure out rollback if something goes wrong.” Defined rollback procedures, mapped to each action type, tested against a staging environment. The first time the rollback procedure is needed is not the right time to write it.
The MCP Server Pattern for ERP Integration
Exposing ERP capabilities as MCP servers transforms each capability into a governed interface: typed input schema, authenticated access, rate limiting, and an audit log for every invocation.
The pattern: each ERP capability, “create purchase order,” “update supplier record,” “close ticket,” becomes a separate MCP tool with a defined input schema, defined permissions, and defined audit behavior. Agents access ERP capabilities through these tools. Direct database calls, direct REST API calls without governance, and ad hoc integrations that bypass the permission layer are not permitted.
Benefits at the governance layer: permissions for ERP write operations are configured once at the MCP layer and inherited by every agent that uses those tools. New capabilities are added to the MCP server and become available to all authorized agents simultaneously. Deprecated capabilities are removed once and disappear everywhere.
For TOTVS Protheus specifically: no official MCP server from TOTVS exists as of the most recent research [verify current status before deployment]. Custom implementation using Protheus REST APIs is required. This is engineering work, not a configuration task.
One security consideration that cannot be deferred: a 2026 RCE vulnerability class in MCP protocol design confirmed that MCP servers are software and require the same security practices as any other production component. Whitelisting, current patches, and audit logging at the gateway level. An MCP server connecting to a production ERP is a high-value attack surface.
The Staged Rollout That Prevents Disaster
No enterprise agent project should go from pilot to full write-back autonomy in a single step. The staged rollout exists because each stage surfaces problems before the consequences are production-scale.
Phase 1: read-only. The agent reads ERP data, surfaces recommendations, and stops. No write capability. Run for four to eight weeks. Validate entity resolution accuracy, surface data quality issues in master data, confirm recommendations are directionally correct. The data quality findings from phase 1 typically reorder the work of phases 2 through 4.
Phase 2: supervised write. The agent proposes actions. A human reviews and approves each one before execution. Run until approval rate stabilizes, typically above 95 percent without modification. Rejected proposals are diagnostic material for improving entity resolution.
Phase 3: autonomous write with monitoring. Pre-approved action types execute without human review. All executions logged. Anomaly detection flags deviations for human review.
Phase 4: high-volume automation. Only for action types with proven accuracy and low reversibility risk across phases 1 through 3.
Skip a phase, accelerate toward the data corruption incident that pauses the program for two quarters.
The Business Case for Getting This Right
ERP vendors are shipping their own AI layers: TOTVS LYNN (announced February 2026), SAP Joule, Oracle’s integrated assistants. These are generic solutions. They are not built around your specific processes, your data quality characteristics, or your regulatory constraints.
Custom agents with deep process knowledge and a governed integration layer outperform vendor copilots for specialized workflows. The integration infrastructure, entity resolution service, and action audit trail are reusable across every subsequent agent project. The second project costs a fraction of the first.
The teams moving fastest on ERP agent integration are the ones who invested in governance early enough to have a stable foundation when the business demanded scale.
For enterprise teams evaluating agent integration with core business systems, the AI Opportunity Sprint maps the integration architecture before any code is written.