Natural language chat that navigates inside the ERP

Problem

Reaching a specific screen in an ERP with years of modules piled on top is blind navigation: nested menus, search criteria and an order that only daily users have memorised. "Open that customer's latest order" is a three-second sentence that, done by hand, is several clicks plus knowing in advance where to look.

Solution

There are three pieces, kept apart on purpose. A C# add-on inside the ERP exposing a local HTTP bridge that understands only a closed repertoire of verifiable commands. An intermediate server publishing those commands as MCP tools. And a conversational agent living outside SAP that interprets what the user types and decides which command to issue.

The split is not accidental. The part that decides is the part that can be wrong, so the part that executes is deliberately dumb: it interprets nothing. A command that is not in the repertoire gets rejected rather than approximated.

That also bounds the possible damage. The agent never talks to the database or to the SDK. It can only ask for things the add-on already knows how to do and that were reviewed one by one.

Architecture

Why it is built this way

Natural language stays outside the ERP. Only closed commands travel inwards, and that boundary is the one thing that makes the setup defensible.

The command repertoire is finite. Anything undefined is rejected; it is never approximated to the nearest match.

The bridge listens on localhost only. No network port is open and the ERP is never exposed to anything from outside the machine.

I used LangGraph for the agent because the decision flow stays a graph you can read and debug. Chaining prompts works until it fails, and then you cannot tell where.

Streamlit is only the interface. The chat is presentation and should not have shaped the design of the other two pieces.

Result

A request written in plain language opens the matching screen inside SAP Business One, and the ERP only ever executes commands from a closed repertoire.