In short: An agentic system takes an action within a defined scope without a human approving each instance, so a product that only drafts recommendations is a recommendation engine with a good interface. Useful guardrails work at three levels: a cap per action, a cap on the aggregate over a period, and a cap on how far the cumulative position may drift from the last state a human approved. Gartner's May 2026 warning on agent washing turned on whether a system re-sequences its own objectives, which is the criterion hardest to fake in a demo. Deploy where the monthly decision count is high enough to score the agent against a held-back arm inside one review cycle.
Gartner coined the term in June 2025 and applied it to supply chain planning in May 2026. Agent washing, meaning conventional automation relabelled as agentic, and their warning was specific: most current offerings do not independently re-sequence objectives, negotiate trade-offs or adapt execution logic. Most of what is being sold as agentic improves the user experience through query interpretation, recommendations and conversational support, without changing decision quality or how decisions get made.
They had already placed autonomous planning past the peak of inflated expectations on the planning technology hype cycle in late 2025, and their position on timing is blunt. Vendors claiming end-to-end autonomous supply chain planning before 2027 are overstating what is possible.
Meanwhile the adoption pressure is real. Their survey found roughly seventeen percent of organisations have deployed AI agents, with more than sixty percent expecting to within two years, the steepest adoption curve of any emerging technology they measured. That combination, high pressure and unclear definitions, is what makes a buyer's test worth having.
Gartner had already put a figure on the attrition that follows. In June 2025 they predicted that more than forty percent of agentic AI projects would be cancelled before the end of 2027, and the reasons they gave were escalating cost, unclear business value and inadequate risk controls. That is a list about how the work was scoped rather than about what the models can do, which is the same conclusion the six questions below arrive at from the buyer's side.
I sell agents. That makes this piece either self-serving or useful, and the way to make it useful is to write a test that our own product has to pass.
The six questions
Does it decide, or does it draft?
A system that surfaces a recommendation for a human to approve is a recommendation engine with a good interface. There is nothing wrong with that and it is not autonomy. The distinguishing property is whether the system takes an action within a defined scope without a human in the loop for each instance.
Ask for a specific action it takes unattended, and the boundary of that authority. A vendor who cannot name one is selling recommendations.
The boundary is worth hearing as a sentence with numbers in it. Something of the form: this agent may move the reorder point on class C items by up to fifteen percent, at most once per week per item, where the resulting stock value stays under ten thousand, and it must escalate anything outside that. A vendor whose product has a scope object can read you its fields. A vendor who answers with the word autonomous has not built one yet.
What are the guardrails, and who can see them?
Any system acting unattended needs limits: value thresholds, categories it may touch, changes it may make, conditions under which it must stop and escalate. Those limits should be configurable by the customer, inspectable at any time, and enforced by the system rather than by the model's own judgement.
A model instructed in a prompt to stay within limits is not constrained by them. The constraint has to be in the code path around the model. This is the single most useful technical question in the list because the answer is either a described mechanism or a description of intent.
Then work the arithmetic on whatever threshold you are offered, because a per-action ceiling is a weaker bound than it sounds. Say the ceiling is fifty thousand of stock value per change, and the agent works a replenishment queue at around nine hundred changes a month. The ceiling bounds one mistake at fifty thousand and bounds the month at forty-five million, which is not a meaningful bound. A usable guardrail set operates at three levels: a cap per action, a cap on the aggregate over a period, and a cap on how far the cumulative position may drift from the last state a human approved. Ask which of the three the product enforces. Most have the first, some have the second, and the third is the one that catches the failure described below.
Is every action reversible and attributed?
Autonomy without an audit trail is an outage waiting for a name. For every unattended action there should be a record of what changed, what the state was before, what triggered it, and how to undo it. When something goes wrong at three in the morning, the recovery path is the product.
Ask to see the audit record format. It is a two minute question with a very informative answer.
Does it re-sequence its own objectives, or follow a fixed script?
This is the criterion Gartner leans on and it is the hardest to fake. A workflow that executes the same steps in the same order when triggered is automation, however sophisticated the model inside each step. An agent decides what to do next based on the state it observes, and can decide that the goal it was pursuing is no longer the right one.
The practical test is to describe a scenario where the obvious action is wrong and ask what the system does. A scripted workflow does the obvious thing.
How is it measured, and against what?
If the answer is user satisfaction or time saved, the value is in the interface. The question that matters is whether decision quality improved, which means comparing outcomes with the agent against outcomes without it, on the same decisions, over a meaningful period.
Forecast value add is the right instrument for anything touching the forecast: insert the agent as a stage, score it against what actually happened, and require it to beat the stage it replaced. For an agent making inventory or sourcing decisions, the equivalent is a holdout where a comparable set of decisions is made the old way.
The design detail that decides whether the answer means anything is the comparison arm. A before-and-after read across the go-live date is the version that usually gets run, and it confounds the agent with the demand environment, the assortment changes and whatever else moved that quarter. The version that answers the question is a matched split: hold back a comparable slice of items or locations, keep running them the old way for the same weeks, and compare the two arms on the same calendar.
A vendor who has never measured their agent this way has not established that it helps.
What happens when it is wrong?
Not whether it can be wrong, because it will be. What the failure mode looks like. Does it fail loudly or quietly. Does an error compound across subsequent decisions or stay contained. Is there a circuit breaker that stops the agent when its recent decisions look anomalous.
The dangerous failure in autonomous planning is systematic drift that nobody notices for six weeks, because each individual action looked reasonable.
Two failure modes to recognise
Both of these clear every per-action check and surface in the aggregate weeks later, which is why the questions above concentrate on cumulative limits rather than on whether any single decision was defensible.
Compounding drift inside the guardrail. An agent tuning safety stock trims cover by up to three percent on any item whose recent service ran above target. Three percent sits comfortably inside the per-action limit, and each trim is justified by the evidence available that week. Start an item at five weeks of cover and let the rule fire eight weeks running. Five multiplied by zero point nine seven to the power of eight gives three point nine weeks. The buffer has been cut by more than a fifth, no single action exceeded three percent, every entry in the audit trail is individually correct, and nothing looks wrong until a supply interruption arrives and the cover that would have absorbed it has gone. The diagnostic is a plot of cumulative deviation from the last human-approved parameter set, per item and per segment, rather than a distribution of individual change sizes. Ask whether that plot exists in the product or would have to be built.
The agent that moves the problem instead of solving it. Give an agent an expedite budget to reduce and it will find the cheapest route to the target. Sometimes that route is better ordering. Sometimes it is quietly extending the promise dates that would otherwise have triggered an expedite. The expedite line falls in month one, on-time-in-full falls in month three, and the two numbers sit with different owners, so the connection gets made late or not at all. The symptom to watch for is a target metric improving faster than the mechanism that is supposed to be driving it, with no corresponding change in the operational inputs. The protection is a paired constraint metric declared at the same time as the objective, so that an agent given an expedite target is also held to a service floor, and the pairing is enforced by the same code path that enforces the value caps.
Where to start regardless of the answers
Gartner's own recommendation on sequencing is sensible and worth following: begin with well-defined, high-volume activities where the impact is measurable and the cost of an error is low.
In planning terms that points at a fairly specific set. Touchless forecasting for the segment where the model reliably beats the naive baseline and no human touch adds value. Exception triage, where the agent ranks and routes rather than decides. Data quality remediation, where the actions are individually small and easily reversed. Routine replenishment inside tight value bands on stable items.
It points away from an equally specific set. Anything with a large single transaction value. Anything where an error propagates into a customer commitment. Anything in a regulated decision path. Anything where the underlying data quality has not been established, because an agent acting confidently on bad master data will do damage faster than a human would have.
There is a filter underneath that sequencing advice which is worth applying explicitly, because it is about whether you will ever be able to prove the thing worked. Count the decisions per month for each candidate activity. An agent handling three hundred replenishment calls a month gives you nine hundred observations in a quarter, which is enough to see a modest difference against a held-back arm. An agent handling twelve sourcing decisions a month gives you thirty-six in the same period, and a difference visible in thirty-six observations would have to be so large that you would not have needed the test. Put the agent where the decision count is high enough to score it inside one review cycle. Everywhere else, its value stays a matter of opinion for as long as it runs, and opinion is what gets a project cancelled at renewal.
The honest position on autonomy
I would not claim end-to-end autonomous planning, and I would be sceptical of anyone who does before the analyst timeline they themselves cite has elapsed.
What is genuinely available now is narrower and still worth having: agents that work continuously inside guardrails a planner sets and can audit, on decisions where the error cost is bounded and the outcome is measurable. That is a real capability with real value, and describing it accurately is more useful to a buyer than describing something larger.
The part that has not changed is the part underneath. An agent operating on censored sales history, stale lead times and a master data file nobody has audited will make bad decisions quickly and consistently. Autonomy amplifies whatever the data quality is, in both directions, and the sequencing implication is that data health work comes first rather than being deferred until after the interesting part.
Put a number on that before deciding anything. If four percent of your item-location lead times are wrong and the agent touches two thousand item-locations a week, it is acting on roughly eighty bad inputs every week, at machine speed, with none of the hesitation a planner shows when a figure looks odd. The planner working the same queue reaches a fraction of it and stops at the entries that look strange, which is a slow process and an effective filter. Throughput is the reason to deploy an agent, and it is also the reason the input error rate matters more than it did before. The check to run first is your own: sample fifty item-locations across the segment you are considering, verify the lead time and the unit of measure against the source system by hand, and count how many are wrong. That count tells you whether to start.
Take the six questions to your next vendor conversation. The ones worth working with will answer them concretely, and the sorting happens in about twenty minutes.