What does it mean to put an AI agent inside an ERP?
An AI agent inside an ERP is a system that reads, reasons about, and acts on enterprise data autonomously. It connects a large language model to live business data through structured tool interfaces, enabling the model to answer questions, trigger workflows, and surface insights that would otherwise require manual querying.
This is the story of how we connected Claude to NetSuite using MCP servers at Kitchen Warehouse Australia, and what we learned about making AI reliable in a production enterprise environment.
Why we built it
Our engineering team manages a composable commerce platform spanning NetSuite (ERP), CommerceTools (e-commerce), Celigo (integration), and a Next.js frontend on Vercel. The data that matters most for day-to-day decisions lives inside NetSuite: inventory levels, purchase orders, sales performance, customer records.
The problem: getting answers from NetSuite requires either SuiteQL expertise or waiting for someone who has it. We wanted to give the broader team a way to ask natural language questions and get accurate, sourced answers.
How MCP servers changed the approach
MCP (Model Context Protocol) provides a standardised interface between AI models and external data sources. Instead of building custom API wrappers for every query pattern, we built MCP servers that expose NetSuite data through structured tools.
The key insight: context engineering matters more than prompt engineering. The quality of an AI agent's output depends far more on what data it can access and how that data is structured than on how cleverly you write the prompt.
What we learned
Three lessons from six months of running AI agents against production ERP data:
-
Start with read-only access. Let the model prove it understands the data before giving it write permissions. Our agents spent four months in read-only mode before we enabled any mutations.
-
Schema documentation is your most important investment. The model needs to understand what fields mean, not just what they contain. We invested heavily in documenting our NetSuite schema in a format the model could consume.
-
Error handling is the real product. When a query returns unexpected results, the agent needs to explain why, not just fail silently. We built explicit error paths for every tool.
What failed
Not everything worked. Our first attempt at inventory forecasting produced confident but incorrect projections because the model lacked access to seasonal adjustment data. We learned to be explicit about what data the model does not have, not just what it does.
What is next
We are expanding the agent's capabilities to include purchase order recommendations and anomaly detection in sales patterns. The architecture scales because MCP servers are independently deployable. Each new capability is a new server, not a modification to an existing one.