An Agent Should Not Write Directly to the ERP or WMS
By Equipo Quantum Developers
Summarize:
Operating thesis
An agent may decide that a receipt needs correction, but it should not construct a WMS-specific call and execute it with a broad credential. Between decision and system of record belongs a governed, idempotent, verifiable intent that a specialized adapter translates and reconciles. That boundary protects the ERP and the agent from semantic changes, retries, and uncertain state.
Microsoft describes an anti-corruption layer as a façade or adapter translating between models so one system’s semantics do not contaminate another. Here its job is not to hide the ERP. It preserves ERP rules while the agent speaks in terms of business object and outcome.
The intent architecture
Separate five responsibilities:
- Agent: interprets evidence and proposes a bounded intent.
- Policy: validates eligibility, permission, boundaries, and approval.
- Intent record: assigns durable identity, version, and state.
- ERP/WMS adapter: translates, checks preconditions, and executes with least privilege.
- Reconciler: queries the system of record and confirms, compensates, or escalates.
The agent never receives a credential able to write freely. It does not decide table names, transactions, or internal codes. Its output is a closed business command—reserve inventory, propose adjustment, create draft order, or hold shipment—with a schema and version.
Artifact: the integration contract
| Field | Purpose |
|---|---|
| intent_id | global, immutable identity |
| idempotency_key | identifies the same intent across retries |
| business_object | type, ID, and expected version |
| operation | permitted verb from the catalog |
| requested_state | requested business change |
| preconditions | expected state, balance, version, or authorization |
| evidence_refs | documents and events supporting the decision |
| policy_version | rule authorizing the request |
| approval_ref | independent approval where required |
| actor | agent and executing technical principal |
| expires_at | point after which action is forbidden |
| compensation | operation or runbook for an unwanted result |
| correlation_id | link to traces, logs, and outcome |
| outcome | state confirmed by the system of record |
Version the contract. An adapter rejects unknown fields or an unsupported version rather than guessing. Preconditions prevent a decision based on old inventory from applying to new state.
Idempotency with business meaning
Networks fail at the worst point: after sending and before receiving the response. AWS explains in Making retries safe with idempotent APIs how a client-provided identifier can recognize repeated requests, and it discusses late arrivals and changed parameters under the same intent.
The key should not be a naïve hash of fields. Two equal-value adjustments can be distinct legitimate operations. A retried intent_id must return the prior result; a new intent receives a new identity. The adapter stores key, semantic fingerprint, state, and response. If the same key arrives with different data, reject and alert.
Idempotency does not make every operation safe. It lets the system distinguish “retry this intent” from “create another.”
State machine and uncertain outcome
The intent moves through explicit states:
proposed → authorized → dispatched → confirmed, with branches for rejected, expired, uncertain, compensating, and compensated.
Dispatched is not confirmed. If the connection disappears, the reconciler queries by external reference, object, and version. It retries only when the authoritative system demonstrates that no action occurred. If the result cannot be known, the case remains uncertain and leaves the general automation path.
The final event carries native ID, new version, timestamp, and state read after the write. A successful HTTP response without verification may not prove the business outcome.
Compensation is not Ctrl+Z
Distributed processes do not always have atomic rollback. Microsoft’s Compensating Transaction pattern describes recording how to undo completed steps when a multi-system operation fails, while recognizing that compensation is domain-specific and may not run in reverse order.
Canceling a reservation, issuing a credit, or creating a correcting movement are new actions with their own authorization and evidence. Some consequences cannot be reversed: a shipment left or a third party saw an order. Mark them noncompensable and escalate before the irreversible point.
Illustrative example: a receiving discrepancy
An agent compares an order, notice, and physical count, then proposes a receipt adjustment. The intent record freezes object and version. Policy permits proposal only; a supervisor approves. The adapter reads the WMS and finds the count changed after the evidence was captured. The precondition fails and the intent returns to review rather than overwriting.
In another case, the WMS accepts the adjustment but its response is lost. The reconciler finds the native reference and marks confirmation without retrying. If the related ERP entry later fails, the flow does not delete warehouse history. It begins the defined compensation or escalates, retaining both outcomes. This example is illustrative and does not prescribe universal rules.
Permission and the double boundary
The adapter uses an operation- or domain-specific identity with least privilege. Policy authorizes the intent; ERP/WMS authorizes execution again through native controls. Approval in the control plane never replaces system-of-record limits.
Master-data changes, payments, releases, and cancellations deserve a route separate from reversible adjustments. The contract may require human approval, dual control, or manual execution. An agent must not recast an exception as a generic operation to avoid the gate.
Observability and daily reconciliation
Measure intents by state, age, retries, idempotency conflicts, failed preconditions, uncertain outcomes, and open compensations. Segment by system and operation. A small set of uncertain cases can matter more than thousands of confirmations.
In Quantum Automation Center, execution states, timelines, artifacts, logs, permissions, and approvals can expose intent end to end. ERP or WMS remains authoritative for result; Quantum preserves the relationship between decision, authorization, and action.
The strongest counterargument
The layer adds latency, components, and operating work. For a small integration it may duplicate native validation and create another place to fail. Maintaining adapters across versions also has a cost.
That objection is valid. Use the minimum layer necessary. If the native API already provides idempotency, granular authorization, audit, and preconditions, the adapter may be thin. Separation still prevents broad credentials and preserves intent, but it need not reimplement existing features.
When not to use this approach
Do not build the full contract for read-only queries or low-impact reversible writes when the system already exposes an idempotent, audited API with suitable permissions. Do not use it to disguise a fragile integration with additional queues.
It is necessary when an action changes inventory, accounting, orders, or commitments and may be retried. The question is not whether the agent “knows the ERP.” It is whether each intent can execute once, be proven later, and be corrected without inventing state.
Sources
Article topics
