The integration layer point is exactly where I’d focus too. An LLM can decide what it thinks should happen, but it shouldn’t be the component that gets to decide whether that action is allowed to mutate ERP state.
The idempotent transaction wrapper is a strong pattern because it creates a deterministic boundary: agent output → validation → authorization → transactional execution → audit trail. I’d also make the “draft vs commit” distinction explicit for every consequential operation. Let the agent generate a proposed transaction, but require the middleware to establish that the request is valid, authorized, and safe to execute.
That separation makes model upgrades much less risky too the model can change without changing the rules that protect the system of record.
The integration layer point is exactly where I’d focus too. An LLM can decide what it thinks should happen, but it shouldn’t be the component that gets to decide whether that action is allowed to mutate ERP state.
The idempotent transaction wrapper is a strong pattern because it creates a deterministic boundary: agent output → validation → authorization → transactional execution → audit trail. I’d also make the “draft vs commit” distinction explicit for every consequential operation. Let the agent generate a proposed transaction, but require the middleware to establish that the request is valid, authorized, and safe to execute.
That separation makes model upgrades much less risky too the model can change without changing the rules that protect the system of record.