Blog · Integration architecture
A Field Guide for ERP Integration Architects Evaluating AI Agents
If you're the person responsible for how an ERP integrates with the rest of an organization's systems, "we support your ERP" is not a claim worth taking at face value. It's an architecture question. Here's what we think an ERP integration architect should actually ask an AI agent vendor before signing off on a deployment.
Is the reasoning engine actually ERP agnostic?
Some platforms bake ERP-specific logic straight into their core reasoning loop, which means every new integration is closer to a rewrite than a configuration change. The more durable design keeps the agent's planning and reasoning layer speaking only in canonical, system-agnostic terms (entities, roles, workflows, callable actions) and pushes every system-specific detail (field names, API shapes, authentication quirks) into a single, isolated connector layer. Ask to see where that boundary actually sits in the architecture, not just hear that it exists.
What does porting to a second system actually cost?
If the honest answer to "what changes if we add a second ERP, or a second system entirely, say a CRM, a banking core, or a logistics platform" is "we'd need to rebuild significant parts of the reasoning engine," that's a sign the abstraction isn't real. In a properly layered design, adding a system means writing one new connector and one field-mapping file per module. The reasoning engine, the business-rule layer, and every frontend built on top stay untouched, because they never knew which system they were talking to in the first place.
Where does the credential actually live?
A browser or client should never hold a real ERP credential. Look for a design where the session token a user's browser holds resolves, server-side, to the actual credential. That credential should stay encrypted at rest, provisioned and revocable by an administrator, so a leaked session token alone can't reach the ERP, and revoking access kills every live session under it immediately.
Is governance a separate trust boundary, or bolted onto the agent?
Settings, credentials, and the knowledge the agent draws on should sit behind their own admin access boundary, checked independently of what the agent itself is allowed to do, and the reasoning engine should have no code path into changing those settings. Every configuration change should be logged the same way every agent action is. If an integration architect can't get a straight answer on where that line is drawn, that's the question to keep asking before rollout.