Grounding an agent in your business: context, guardrails, and staying in control

When somebody joins a supply chain team, nobody hands them the keys to the whole enterprise on day one. They get a narrow slice of the work, a person to escalate to, and the context that never made it into the system. They learn which suppliers are on credit hold and which retailer will charge you back for a short ship. They learn which one will call first, and which rule is a rule versus a habit nobody wrote down. Six weeks later the team trusts their calls, because everyone knows what the new hire was given and how far their authority runs. That is grounding. It is the difference between a capable stranger and a capable colleague.

The same distinction decides whether an agent is useful in an enterprise supply chain. Most conversations about agentic AI stall on whether the model is good enough to be trusted. The better question is narrower and easier to answer. What does this agent know about how you run, and who decides how far it can go on its own?

Why a capable agent still gets it wrong

A general-purpose model knows a great deal about supply chains in general and nothing about yours. It does not know that your Tuesday cutoff is really Monday at 4pm because of how the 3PL batches. It does not know that one supplier's confirmations arrive as a PDF with the quantities repeated in the email body. It doesn't know that the two disagree about a third of the time, or that when they do, the email is right.

That is a context problem, and a better model will not solve it. An agent acting without that context acts confidently and incorrectly, which is worse than not acting at all. Scripted automation tried to encode context as rules, one branch at a time, and snapped at the first case nobody anticipated. We covered that in why brittle scripts break.

Where that context lives matters too. Roughly 40 to 60% of daily execution work never touches the system of record. It happens in email, supplier portals, PDFs, and shared inboxes. An agent grounded only in ERP tables is grounded in the minority of the job. That gap is a meaningful part of the 2% revenue leak.

What grounding actually means

Grounding is what feeds the detect, reason, and act loop we walked through in inside an autonomous workflow. It comes in three layers.

1. Your data, including the unstructured half. Orders, inventory, and supplier master data from your systems of record. Plus the email threads, confirmations, BOLs, and portals where exceptions actually live.
2. Your rules, including the unwritten ones. Service commitments, allocation priorities, approval thresholds, and the customers who get a call before an automated notice. Most of this lives in people's heads, and getting it out is the real work of the first weeks.
3. Your exceptions, as cases rather than branches. Not "if quantity mismatch then flag," but a worked set of how your team has resolved mismatches, what they weighed, and what they escalated. That is what lets a workflow reason about a case it has never seen.

None of this requires cleaning up your data or replacing a system first. Start with the workflow where the leak is largest, prove it, and scale from there.

Guardrails are a job description

"Guardrail" suggests a barrier that catches a failure after it starts. A better frame is a job description: what a workflow is responsible for, what it may touch, and what it must hand to a person.

A workflow's job description has four parts:

• Scope. The part of your process, the order types, suppliers, and regions it covers. A workflow disputing a chargeback reads the PO, ASN, and proof of delivery as evidence. If the dispute turns up a problem with the PO itself, changing it is not its call, so the case goes to whoever owns the order.
• Permissions. Read and write access defined per system and per field, never a blanket integration user.
• Escalation. The conditions under which the workflow stops and hands to a named person, with its reasoning attached.
• Audit. Every action, the inputs behind it, and the alternatives it considered. Every write back to your system carries a citation to the email, PDF, or portal record it came from. Anyone can read it, including someone who was not in the room.

The audit trail turns control from a claim into something you can verify, and it is what your security review will ask for. Emerix operates under SOC 2 Type II, which speaks to how those controls run over time, not how they looked on one audit day.

Staying in control is a setting you choose

How much a workflow does on its own is a decision made per workflow, and it should move. Reconciling quantities against a confirmation email can reasonably run unattended once accuracy is proven. Deciding which customer gets short shipped in an allocation crunch probably never should. Different risks deserve different settings, a range we laid out in the spectrum of autonomy.

The pattern that works is to start in recommend mode. The workflow detects and reasons, and a person approves the action. Compare its recommendations to what your team would have done. When the gap closes and stays closed, move the dial. If something changes upstream, move it back.

Staying in control does not mean a person checks every item forever. It means scope, permissions, escalation, and autonomy are yours to set and change. And the log tells you honestly what happened while you were not looking.

The agent's authority is explicit and narrow by design, not bounded by a promise about its behavior.

Nobody hands a new hire the keys to the whole enterprise on day one, and nobody reads over their shoulder in year two. Ask a vendor how their agent gets smarter and you will hear a story about models. Ask instead what it knows about your business, who wrote its job description, and where you can read what it did last Tuesday. Those three answers tell you whether you are looking at something you can actually run.

Alison Crawford is Director of Product Marketing at Emerix, the system of action for supply chain execution. She has spent her career in supply chain software, with prior roles at RELEX Solutions, Aera Technology, o9 Solutions, and Kinaxis, and was recognized in the 2023 Women in Supply Chain Awards. She writes about the distance between what supply chain software promises and what it actually executes. Connect with Alison on LinkedIn.

Frequently asked questions

What does it mean to ground an AI agent in a business?
Grounding means giving an agent the specific data, rules, and resolved exceptions of one business, so it reasons from how that company actually operates. It is the difference between an agent that knows about supply chains and one that knows about yours.

Do we have to clean up our data before an agent can act on it?
No. Much of the execution work an agent needs to read is unstructured to begin with, in email, PDFs, and portals. Grounding is scoped to the workflow you start with, not your whole data estate.

What stops an agent from taking an action we did not authorize?
Several things work together:

• Permissions scoped per system and per field.
• Escalation conditions that route a case to a named person.
• A complete audit log of every action and the inputs behind it.