Building a procurement system AI agents can work in

Why autonomous procurement depends on where the agent sits, and four things to check before you buy one.

What you need to know

• Where an AI agent sits decides what it can do. Beside your systems, it can advise. Inside one system that holds the records, the workflows and the approvals, it can finish the work.
• Everyone is building agents. Almost no one in procurement is running one. Gartner puts it at 68% building versus 1% to 5% using, and says most of those are workflows with a language model on top. The problem is not the model. It is the system around it.
• Four things to check before you buy: does the agent use your permissions, does it pause for a human, where do its changes wait before they are applied, and does the log show what it was refused.

Why procurement AI agents stall: everything they need sits in three different places

Ask any of my procurement friends what they run on and the list is familiar. A system of record: the ERP, the contract repository, the supplier master. A system of action: intake, workflows, approvals, the tool people actually open. And now an AI agent: a copilot, a bot that drafts, summarizes, and actions.

The pitch for the agent is always the same. It will read your data, do the work, and ask you when it needs a decision. However in production, that same agent reads from one system, acts in a second, and asks permission through a third. Each hop from one system to another is a copy, a sync, or an API call with its own permissions and its own failure modes. This isn't an autonomous agent, it is a very fast intern with three badges, none of which open every door.

What is interesting is that Gartner reports that 68% of organizations building AI solutions are building agents. In procurement, Gartner counts adoption at 1% to 5% and warns buyers about "agent washing": "At best, agents are semiautonomous; often they are only LLM-augmented workflows." The distance between 68% and 5% is not a shortage of agents. It is the absence of one system, with the record, the work and the agent inside it, that the agent can be trusted to operate.

Agents layered onto existing systems do deliver something: faster reading, quicker drafts, fewer clicks. What they struggle to deliver is work that finishes on its own, because the systems underneath were built for people to drive. That gap is the difference between an agent that helps a person finish the work and an agent that finishes it: a draft that still needs someone to send it, versus a sourcing event that runs to completion under the rules the company already set. Closing the gap is where most of the effort now goes, and most of that effort is aimed at the wrong thing. Teams keep buying a better model when the model was never the limit. The limit is that the agent cannot see every record it needs, act under its user's permissions, and get a decision from a person, all inside one system. No model fixes that, you have to build the system differently.

An AI agent is only as good as the procurement system it lives in

An agent can do exactly three things: see, act, and ask. What it can see is set by the data it can reach. What it can act on is set by the permissions it holds. Whether anyone trusts the result is set by how the ask and approval steps work. When seeing happens in one system, acting in a second, and asking in a third, the agent cannot finish anything by itself. It can read a contract, but it cannot change the record. It can draft a change, but it cannot get it approved where the approver works. Every step ends with a person carrying the result across to the next tool. That is not an autonomous system, it is a chatbot with integrations.

You can tell what a procurement AI agent can do by where it sits. An agent in its own window beside the work is advisory. An agent built into one system can act there, and only there: it can move a contract through its stages, but it cannot start the sourcing event that lives next door. The work in this case still lives with the person.

When we started on Ranger, the autonomous procurement platform from Levelpath, the question we kept coming back to was: what would procurement software have to look like for an agent to be a first-class user of it? The answer was not another feature. It had to be a whole new system, where a person and an agent work under the same rules even though they use it in completely different ways.

The hard part of autonomous procurement: one system, two kinds of users

You and I navigate software by looking. We open a list, click a record, read a status, press a button. An agent navigates by calling tools: search this, read that, update this field, start that workflow. We are looking at the same records with the same set of rules, it just happens to be in a completely different way.

The easy answer is to give the agent a master key. Let it log in as itself with access to everything, let it make changes through a back door instead of the normal approval path, and let it keep its own record of what it did instead of writing to the company's log. That is how many agents are bolted on today, and it looks great in a demo. It is also how you end up with an agent that can read contracts its user is not allowed to see, or change a supplier's bank details with no one's name on the change.

That master key is what the engineer sees. From the buyer's side, the same shortcut shows up as a mismatch. The AI sits in one place, the data and the work sit in another, and people copy and paste between them to keep the agent informed. The consequence is pretty predictable: nobody trusts the agent on its own, so a person watches most of its steps, and the business pays for the AI and for the person watching it. That is not an agent problem, it is a building problem. And a building problem needs a building rule.

The constraint we set for Ranger was simple to say and expensive to build: anything an agent can do must be governed by exactly the rules a person is governed by. Same permissions, same approvals, and the same audit trail. When an agent needs an exception, the system has to change, not the rule.

Four things to look out for in a procurement AI agent

These are the four places a procurement AI agent gets into trouble inside a system that was not built for it. Each one is easy to spot once you know what to ask, and each one shaped a decision we made.

1. The agent that sees more than you do

Watch for a service account, a shared login, or an agent that pulls everything and filters the results afterward. The symptom is an agent that can summarize a contract its user was never allowed to open.

In Ranger, the agent starts every session as the person who opened it. It knows who you are, which groups you belong to, and which records you are assigned to. A role is only the first of three checks. The second is whether the user is assigned to the specific record. The third is whether a group or collaborator relationship grants access. An agent passes all three or it does not act. We also built a permission debugger that answers "can this user do this action on this record, and why" for any pair, and it gives the same answer whether the actor is a person or an agent.

Ask: Does the agent act under my user's permissions, or its own? Then ask to see the agent try to read a record the user cannot.

2. The agent that never asks

Watch for a vendor who cannot show you the setting that says which agent actions wait for a human. If the answer is a slide in a deck being presented, there is no setting. The symptom is an agent whose autonomy is whatever the model decided that day.

In Ranger, every tool an agent can call is tagged with a risk class: read, write, spawn (delegating to another agent), or external (calling something outside Ranger). For each class, the policy is one of three modes: run automatically, pause for approval, or deny. That policy is set per agent, and admins can see it next to every tool.

In practice, in Ranger reads happen instantly, writes pause the session and show an Approve / Reject card, and the agent cannot even select a tool the policy denies. Each write is approved on its own; approving one does not pre-approve the next. If an agent delegates to a sub-agent, the child inherits the stricter of the two policies. It can never be more permissive than its parent. The model does not decide how autonomous it gets to be. The policy does, per action type, and it is written down where an admin can read it.

Ask: Which agent actions wait for a human, and who decides? Ask to see this in the product settings.

3. The record that changed while nobody was watching

Watch for a supplier field that is different today than it was yesterday, with no proposal, no reviewer, and no name attached. A supplier updates its bank details through the portal. A connector pulls a changed address from the ERP. An agent extracts a new payment term from a contract. In most systems these three paths land in three different places, and the record changes while no one is watching.

In Ranger all three produce the same thing: a change request. It holds one or more proposed field values, flagged material or not, with a lifecycle a reviewer walks through item by item. A supplier record never silently moves. The agent proposes; a person applies. Today this covers supplier records, with other record types to follow.

Ask: When the agent proposes a change to a record, where does the proposal live before it is applied, and who applies it?

4. The log that only shows what worked

Watch for an audit log with no record of attempts that were refused, and no way to read back what an agent actually did in a session. The symptom here is a compliance team that can see every success and none of the near misses.

In Ranger, every create, update, delete and status change writes to an append-only audit log that cannot be edited. That includes actions an agent took. It also includes actions that were attempted and denied by a permission check, an entry few systems write and the one a compliance team most wants to see.

On top of the action log, agent sessions themselves are reviewed. A judge model grades each session on whether it achieved what the user asked and whether the user seemed satisfied, and flagged sessions land in a queue where an admin reads the full transcript and records whether they agree. The system does not just log what the agent did. It keeps a record of whether the agent was any good.

Ask: Is every agent action in the audit log, including the ones that were denied? And can I read the agent's full session afterward, and is anyone grading it?

The four questions to ask any procurement AI vendor

1. Does the agent act under my user's permissions, or its own? Ask to see the agent try to read a record the user cannot.
2. Which agent actions wait for a human, and who decides? Ask to see the setting, not the slide.
3. When the agent proposes a change to a record, where does the proposal live before it is applied?
4. Is every agent action in the audit log, including the ones that were denied? Can I read the agent's full session afterward, and is anyone grading it?

If a vendor's answer to any of these four questions is a workaround, the agent is sitting beside the system, not inside it.

Autonomy is a property of the procurement system, not the agent

Everyone is asking how much a procurement AI agent can do, and that is the wrong thing to measure. The better question is how much the system underneath it was built to let it do safely, with the same rules, the same approvals, and the same record of events that apply to the people working next to it.

Gartner retired "autonomous procurement" from this year's Hype Cycle, on the grounds that no single technology could deliver it. We agree. It was never going to be a feature. It takes a system built for the agent from the start.

‍

^{Sources. Gartner, AI Agents Will Be Your Top Users — Here’s How to Prepare for Them, Brent Stewart et al., 6 October 2025. Gartner, Hype Cycle for Procurement and Sourcing Solutions, 2026, Lynne Phelan et al., 10 June 2026.GARTNER and HYPE CYCLE are registered trademarks of Gartner, Inc. and/or its affiliates in the U.S. and internationally and are used herein with permission. All rights reserved. Gartner does not endorse any vendor, product or service depicted in its research publications.}