What the build actually delivered.
A mid-market reverse logistics-tech company wanted their team to use AI against real operational data without handing it the keys to everything. I built an MCP server and the agent tooling around it in Python on Google Cloud. More than 50 internal users now work through it every day — looking up inventory, moving orders, checking truckloads — with every tool locked to a permission tier and every action written to an audit log. The AI got useful. It never got dangerous.
The data was there. Getting at it wasn't.
Reverse logistics runs on knowing exactly where a unit is right now — inbound, inspected, restocked, scrapped. That state lived across a handful of systems, and pulling a straight answer out of them meant knowing which screen to open and what to type. The people who knew were the bottleneck. Everyone else waited on them.
The obvious fix in 2026 is to point an AI at it. The obvious risk is what that AI can do once it's connected. An agent that can read an order can usually cancel one too, and in an operation moving real inventory, a confident wrong move is expensive. They needed the reach without the exposure.
A gate in front of every tool.
The core of it is an MCP server — the layer that lets an AI discover what it's allowed to do and do it safely. I wrapped each capability as a tool and gave it a tier. Reads run on their own. Writes run, and get logged. The handful of actions that could actually hurt — cancelling, deleting, overwriting — stop and wait for a person to sign off.
Underneath, the services doing the real work are FastAPI and Functions Framework on Google Cloud, sized for high-volume inventory workflows rather than a demo. I also stood up preproduction environments in Docker and wired the deploy pipeline so shipping a change stopped being an event. That last part is unglamorous and it's the reason the thing has kept running.
The permission-and-audit pattern at the center of this build is the one I later open-sourced as mcp-gatehouse. You can read the exact approach in code — it's the same discipline I bring to MCP server development for anyone else.
Fifty-plus people, one safe way in.
The measure that matters is adoption: more than 50 internal users rely on it daily. Not a pilot a few power users tolerate — the way the floor actually gets answers now. The questions that used to route through one or two people go straight to the agent, and the people who used to answer them got their attention back.
Because everything is tiered and logged, "what did the AI do?" has a real answer six months later instead of a shrug. That audit trail is what let them widen access without widening risk — the whole point of building the gate first. If your operation is weighing the same move, an AI agent build that starts from permissions is the version that survives contact with production.
Straight answers.
- What is an MCP server doing in a reverse logistics operation?
- It gives the company's AI a governed door into the systems that run the floor — inventory, orders, truckloads. Instead of copy-pasting data into a chatbot, staff ask in plain language and the agent reads or acts through tools I defined, each with its own permission tier.
- How do you stop an AI agent from doing something destructive?
- Every tool is tagged read, write, or destructive. Reads run freely. Writes get logged. Anything destructive stops and waits for a human to approve it — and if no approver is wired up, it fails closed rather than guessing. Every call lands in an audit log either way.
- Who owns the system when the engagement ends?
- They do. It runs on their Google Cloud project, in their repositories, under their permissions. There is no platform of mine to keep paying for and nothing that stops working if I walk away.
More on the pattern: what an MCP server is, in plain English, or the other case studies.