Yotam Ater
A supplier email lands: the ship date on PO 48213 moved out two weeks. An agent can read the email, locate the PO and update your ERP, and the whole thing takes ~4 seconds. The model is comfortably capable of that part. What you actually need to know before allowing the update is whether your data, and the systems around it, give the agent enough context and control to act safely. It's a simple question to ask. This post is about everything a real answer has to cover.
When I talk to teams evaluating agentic systems, the conversation usually starts with the model. Is it smart enough? Does it hallucinate? Which vendor should we bet on? Fair questions, and I understand why they come up first, but in most deployments the model is not the binding constraint. A current model will read a rambling supplier email more reliably than a tired human at 7:30 AM. The harder question is whether your data can support a system that takes action, rather than one that returns an answer for a person to evaluate.
Why is the bar higher than for a chatbot? Because a chatbot never touches your system of record. A person reads its answer, decides what to do about it, and then goes and does the work themselves. In an agentic workflow the doing is in scope. So the question becomes: what does the agent need before you can trust it with the doing?
So here is an exercise I like: let the agent try to take that one action, and watch where it gets stuck. Inevitably, it will get stuck in one or more of four places, and none of them is "go clean all your data first."
1. Ground truth the agent can trust
Continuing our PO example from above: the agent parses the email and goes to update the ETA. It finds the PO, and it finds two date fields. promised_date was last touched at PO creation, four months ago. eta_manual is a custom field an ops lead added back in 2019, and it's the one the planners actually read. Nothing in the schema says so. Every human on the team just knows.
So what does "dirty data" actually mean here? Not an enterprise-wide quality score. For one workflow the agent touches maybe a dozen fields across two systems (a ballpark estimate, but a decent approximation), and readiness means those dozen fields have known semantics: which one is authoritative, who else writes it, how fresh it is. Mapping a dozen fields is bounded work. It still has to actually happen: you go over each field with the people who write it and the people who read it, and you keep the map current as the schema and the team drift underneath it. In a live deployment that maintenance is the system's job: a workflow that reconciles the 3PL feed against the ERP every morning will notice drift long before a human does, provided somebody built it to look.
2. Tribal knowledge
Field resolved. Now the actual decision: the date moved fourteen days. Is that routine or a problem? It depends on things the schema can't tell you. If the delayed units are covered by stock in another warehouse, routine. If a key account's order rides on them, escalation. Everyone on your ops team knows Retailer X has an OTIF penalty clause and gets special handling. No system knows that rule. It lives in the heads of the people who handle the exception today, next to hundreds like it: this supplier tends to short by 5 to 8 percent, that customer accepts partials, this warehouse needs an extra day for relabeling.
Making that judgment explicit is requirement two, and again the scope is the workflow, not the enterprise. You don't need the company brain in a database. You need the working judgment behind this one process: what the best ops person checks first, which thresholds trigger escalation, which accounts are special and why. Extracting it is structured elicitation work: walking real exceptions from the last quarter with your best operators, writing the knowledge down, and then reconciling it where it contradicts itself (it will). A careful first pass gets you roughly ninety percent. The remainder surfaces once the agent runs and starts asking questions, which means you also need a mechanism that captures those answers as knowledge the workflow can use, not as Slack messages that evaporate. Writing it down is work any competent team can do once. Keeping it current as it accumulates and contradicts itself is the part that never stays done, and that is what we build at Emerix.
3. Guardrails
The agent now knows what to change and has decided this particular change is routine. Before it gets anywhere near the ERP, it operates inside guardrails: 1) scoped credentials: the agent acts under its own identity, with the minimum permissions this workflow needs, 2) an approval gate: every change the agent drafts passes through a gate that decides whether it commits now or waits for a person. The gate starts out rule based (change types, amounts, the accounts you define as sensitive), and with enough decisions on record it can become a learned one: a classifier that routes changes the way your approvers actually route them, 3) idempotent writes with rollback: running the same change twice does nothing, and any change can be walked back.
Alongside the guardrails sits the audit log: the draft, the evidence, the gate's decision, the approval if there was one, the write itself. Every action stays reviewable, which is what an auditor will ask you for. It is also what the gate learns from, because a gate that never sees its own outcomes never gets better at deciding. None of this is new to your team. They apply informal versions of these rules every day. The work is getting those rules out of people's heads and into the system.
4. Feedback loop
The change is committed. Was it correct? If you can't answer that a week later, what you have is not an agent, it's a very fast intern nobody reviews. The fourth requirement is the feedback signal: metrics that correlate with whether or not the agent performed well. Approval and rejection rates at the gate. Whether the shipment actually arrived near the new date. Overrides, where a human reverses the agent's update two days later. That last one is gold, by the way: every override is a labeled example of the system being wrong, handed to you for free.
Practically this means the workflow logs its actions in a form you can join against outcomes, and that overrides get captured instead of evaporating into a spreadsheet. If requirement three gave you the audit log, requirement four is mostly free: you're already writing the data, now you close the loop on it.
Putting it all together
So we worked hard to hand the agent everything it needs to act safely: field semantics it can trust, the tribal knowledge behind the decision, guardrails around the write, feedback on how it did. Here is the reward. The PO 48213 email arrives, the agent resolves it end to end, and the person who used to do all of this by hand, fifteen to twenty minutes on a good day and a few hours on a bad one, reads the agent's reasoning and clicks approve. One click, with the agent doing all of the work.
That's the whole anatomy. None of it required a master data program or a two-year integration roadmap, because every requirement was scoped to one workflow, one exception type, one write path. The parts themselves are easy to understand. Running them in production is where the actual work lives, keeping semantic maps current while systems drift underneath them, reconciling knowledge as it accumulates, holding gates and rollbacks to a standard an auditor will accept, and making sure feedback actually reaches the next decision. One question was deliberately left open here. How do you know, at scale and on probabilistic output, that the agent acted correctly? That question is evaluation, and it deserves a post of its own.
Yotam Ater is Co-Founder and CTO of Emerix, where he leads the development of our system of action for supply chain execution. Previously, he led computer vision and algorithms teams at Samsung Israel R&D Center after more than a decade building advanced sensing systems for defense and aerospace. He writes about agentic AI, systems of action, and enterprise execution.