Why agents won’t replace PunchOut — and why neither side is asking them to.

In Part 1 we established that agentic commerce in B2C, while genuinely improving the consumer experience, faces structural barriers that make it evolutionary rather than revolutionary. The B2B story is more complex and the barriers are higher.

Technology vendors are making bold claims. Analysts describe a shift from “human decisions to autonomous agent execution.” Whitepapers promise touchless source-to-pay processes and fully autonomous procurement. These claims rest on three assumptions: that agents can interpret enterprise procurement policy, select suppliers autonomously, and execute compliant transactions without human involvement.

None of those assumptions hold up well under scrutiny, and the reasons reveal something important about where agentic B2B is actually headed.

The Demand Question: What Buyers and Suppliers Are Actually Saying

Before examining whether a PunchOut-replacing agent is technically feasible, it’s worth asking an intentionally provocative question: does anyone actually want one? 

Based on conversations with enterprise and mid-market suppliers over the past 12 months, the answer today is: not really. Suppliers in particular are skeptical, though as we’ll discuss, the reasons why matter more than the sentiment itself.

Every supplier we’ve spoken to has said the same thing: while they are curious, they have strong reservations about exposing their catalogs to uncontrolled agents. This isn’t a technology problem. It’s a business model problem. Suppliers have invested heavily in their eCommerce experiences precisely because that’s where they control the customer relationship, the pricing, the entitlements, and the brand. They’re already reluctant to support hosted catalogs because of the cost, effort, and loss of CX control. They’re selective about which marketplaces they participate in for the same reason; exposing catalog data to an autonomous buyer agent creates exactly the same dynamic and the same reluctance.

There’s a parallel concern underneath this: suppliers are acutely aware that a buyer’s agent, equipped with valid credentials, could just as easily be crawling and comparison-shopping their site as executing a legitimate purchase. It’s a reasonable fear that any supplier with competitive pricing should have.

On the buyer side, procurement platforms are actively integrating AI into vendor selection, onboarding, and approvals. But buyer-to-supplier purchase automation via agents? It’s not a current priority and importantly, buyers aren’t asking their suppliers to support it either.

This matters because most of the agentic B2B narrative established by technology vendors and industry media assumes a pull from both sides. Right now, we’re not seeing it.

A Quick Grounding: What PunchOut Actually Does

To understand what an agent would need to replace, it helps to be precise about what PunchOut actually is and where it sits in the broader procurement flow.

PunchOut is a human-centered workflow. A buyer launches into a supplier’s catalog directly from their procurement platform, builds a cart, and transfers it back, resulting in a correctly formatted, validated purchase order ready for approval. It’s the human-interactive step in a three-part flow: PunchOut creates the PO, PO integration delivers the approved PO to the supplier, and Invoice integration closes the loop. The latter two are already fully automated. PunchOut is the one step where a human is still in the loop, and the one step where agents could theoretically play a role.

That’s the right framing for the question. Not “will agents replace procurement?” but “can an agent do what a human buyer does in PunchOut, at enterprise scale, with the same level of control?”

The Execution Problem: What an Agent Actually Has to Do

This is where the gap between a vendor demo and a production deployment becomes clear.

Consider a real example that illustrates it well: a seasoned procurement buyer, after watching a demo of an “agent executing a purchase,” was convinced PunchOut was obsolete. What the demo didn’t show was that the agent was a conversational front-end backed by RPA (Robotic Process Automation) sitting on top of a procurement platform. RPA can be effective for repetitive, structured tasks, but is not designed to handle ambiguity or changes to the interfaces it is automating, making it brittle. Combining RPA with AI can help, but it is still error prone, and couldn’t be trusted to fully automate enterprise procurement purchasing.

For an agent to genuinely replicate PunchOut, it needs to:

• Authenticate securely with the supplier’s catalog using an auditable identity, ideally tied to a real user, that satisfies the buyer’s access control requirements
• Surface the right sub-catalog based on access entitlements specific to that buyer-supplier relationship
• Execute product search against the approved catalog based on the user’s intent
• Manage a persistent cart across multiple sessions, since buyers rarely complete a purchase in one sitting
• Transfer the cart back to the procurement platform in the correct format, with all required field mappings and UOM/currency transformations applied

Just getting product data to power this is already a significant problem. There are three options, none of them clean: the supplier’s API (rich, but rarely available), hosted catalog (requires supplier cooperation and loads their data into an LLM they don’t control), or screen automation of the supplier’s site (fragile, and breaks every time the supplier updates their UI).

Assume you solve the data access problem. You still need to address:

• Compliance: GDPR, CCPA, and SOC2 requirements don’t disappear because an agent is doing the work. The environment running the agent needs to meet the same standards as any other enterprise system handling procurement data.
• Business rules: Every buyer-supplier relationship has unique field mappings, unit of measure conventions, and data transformations. The agent needs to know about them and apply them correctly, every time, without exception.
• Determinism: This is the constraint that vendor demos never show. Procurement transactions cannot be probabilistic. A purchase order must map the same way every time. An agent that produces the right output most of the time is not an enterprise procurement system; it’s a liability. The demo shows the build. It hides the operate.
• Cart persistence and data backup: Compliant with the buyer’s disaster recovery policies.
• Monitoring, alerting, and auditability: With enough data to support transparency and continuous improvement requirements. Unlike a managed integration environment where transaction volumes, failure rates, and order values are surfaced automatically, an agent-based system gives you the pipes without the instrumentation. In practice, that means teams learn about failures when buyers escalate, not before.
• Dev, Test, and Production discipline: An agentic solution is software in production, and it requires the same environment governance as any other enterprise system: segregated Dev, Test, and Production environments with a controlled change promotion process. Every update, whether to business rules, catalog mappings, or third-party dependencies, needs to be validated before it touches a live buyer-supplier relationship.
• Ongoing maintenance: The agent is software. It accumulates security debt and maintenance debt like any other system. AI can accelerate the build phase. It does not eliminate the need to operate what you’ve built.

This is a substantial engineering and compliance undertaking, and that’s for a single supplier relationship.

The Scalability Wall

Here’s the argument that tends to end the conversation: once you’ve built one agent for one supplier, you have to build another for the next supplier. And another. And another.

What makes this harder than it first appears is that buyer variability compounds at every level, not just across procurement platforms, but within them. Two buyers running the same procurement platform can send materially different setup requests, enforce different validation rules, and require conflicting data representations. One buyer’s Ariba integration may sit on top of a larger SAP enterprise platform with its own field requirements and tolerance thresholds that no other Ariba buyer shares. There is no template that scales cleanly across this variability.

Each buyer-supplier relationship has different requirements: different catalog structures, different authentication schemes, different business rules, different data formats. And no enterprise is going to rely on an agent that operates on probability to always do the right thing across every integration. In procurement, compliance isn’t optional. What you end up with is a portfolio of bespoke agents, each one a maintenance liability, each one running inside a controlled enterprise environment, none of them easily repeatable.

The first agent is a prototype. The tenth is an operational burden. The fiftieth is a program, one that would compete with roadmap priorities, span multiple internal teams, and expand in scope every time a buyer changes its configuration or a new trading relationship is onboarded. Any organization that pursues this path seriously would likely find itself having built a dedicated integration function whether it intended to or not. That’s not an integration strategy. That’s a department.

This is the core reason why “vibe-coding a PunchOut agent” sounds more tractable than it is.

What This Means Going Forward

The case against agents simply replacing PunchOut isn’t that agents aren’t capable, it’s that the problem isn’t primarily a technology problem. It’s a demand problem, a supplier control problem, and a scalability problem that compounds with every new trading relationship.

What enterprises actually need isn’t a DIY agent for each supplier. They need a way for agents to participate in procurement workflows that already have scalability, security, and compliance built in, without starting from scratch every time.

The three assumptions that underpin the agentic B2B narrative, that agents can interpret procurement policy, select suppliers autonomously, and execute compliant transactions, don’t fail because the technology isn’t capable. They fail because the commercial, operational, and compliance realities of enterprise procurement aren’t solved by capability alone.

That’s the gap PunchOut is positioned to fill. And it’s what Part 3 is about: not whether PunchOut survives agents, but how it evolves to make agents actually work at enterprise scale.