How are new competitors entering the procurement journey?

Agents pick up a request or an event at the need and carry it into later stages.

Example

Oracle Fusion's agentic applications begin at the need and carry it through to the order. Five of the interactions examined start here. Across the 21 interactions examined, 5 start here.

These providers already sit inside the buying process. They hold the request, the workflow and the approval trail, so reaching the next stage extends what they run rather than crossing into someone else's system.

Where it must move next

For any one provider to move beyond reading the need, it would have to propose what the request should ask for rather than relay it.

What this could lead to

If more requests enter through an agent, the shape of the request is set by software before procurement reads it.

Why the stage is rated emerging

Two players propose entering the need and neither is demonstrated there. The work shown at this stage is done by procurement's own providers.

This rating considers every player active at Need.

What the evidence does not show

This counts many providers together, not one product. No single offering is shown spanning the complete journey. Of the 5 interactions that touch this stage, 2 are agents making their own choices within a set aim, 2 follow a fixed rule, and 1 are not settled either way by the sources.

Competitive collision, proposed with payments

Five of the 21 interactions begin at the need, picking up a request and carrying it into later stages.

Payments here

Proposed: the platform would shape what the request asks for before procurement sees it.

What both may contest

Turning a stated need into the request the rest of the process works from. Both sides would produce the same thing, so a buyer would use one or the other.

Agents turn a stated need into a written requirement and hand that requirement onward.

Example

Globality's Glo questions the requester, defines the requirement into a concise brief and determines which suppliers reach the buyer's view. Across the 21 interactions examined, 7 start here.

These providers already sit inside the buying process. They hold the request, the workflow and the approval trail, so reaching the next stage extends what they run rather than crossing into someone else's system.

Where it must move next

For any one provider to control specification, its requirement would have to be the one suppliers must answer.

What this could lead to

The document that tells suppliers what to bid on could be written by the provider rather than by the buyer.

Why the stage is rated forming

Procurement agents already turn a need into a written requirement, and Ramp now generates the RFx that goes to suppliers. Both produce the same document.

This rating considers every player active at Define, not only procurement agents.

What the evidence does not show

This counts many providers together, not one product. No single offering is shown spanning the complete journey. Of the 7 interactions that touch this stage, 6 are agents making their own choices within a set aim, 0 follow a fixed rule, and 1 are not settled either way by the sources.

Competitive collision, demonstrated with payments

Seven of the 21 interactions begin at Define, turning a stated need into a written requirement.

Payments here

Ramp's agents generate the RFx that goes to suppliers.

What both may contest

Writing the requirement suppliers respond to. Both sides produce that document, so a buyer needs one of them and not both.

Agents assemble the set of suppliers a buyer will look at.

Example

3D Spark takes a stated requirement and returns viable suppliers for it. Promena and Resilinc reach this stage from a requirement and from a risk check. Across the 21 interactions examined, 3 arrive here.

These providers already sit inside the buying process. They hold the request, the workflow and the approval trail, so reaching the next stage extends what they run rather than crossing into someone else's system.

Where it must move next

For any one provider to control discovery, buyers would have to stop looking outside the set it assembles.

What this could lead to

The set a buyer chooses from could be assembled by the provider, and what stays out of it is not visible.

Why the stage is rated forming

Procurement agents already assemble the supplier set, and Ramp now researches suppliers from its own vendor and payment history. Both produce the same shortlist, and three further players propose entering.

This rating considers every player active at Find, not only procurement agents.

What the evidence does not show

This counts many providers together, not one product. No single offering is shown spanning the complete journey. Of the 3 interactions that touch this stage, 2 are agents making their own choices within a set aim, 0 follow a fixed rule, and 1 are not settled either way by the sources.

Competitive collision, demonstrated with payments

Three interactions arrive at Find, assembling the supplier set a buyer will look at.

Payments here

Ramp's agents research supplier options from the vendor and transaction history the platform holds.

What both may contest

Assembling the supplier set. Both sides do it, from different data, and a buyer chooses whose set to look at.

Competitive collision, proposed with marketplaces

Three interactions arrive at Find, assembling the supplier set a buyer will look at.

Marketplaces here

Proposed: channel economics would narrow the set to suppliers listed on the marketplace.

What both may contest

Deciding which suppliers reach the buyer's consideration set. Both would determine the same set, by different means.

Agents compare supplier options and rank them for the buyer.

Example

JAGGAER carries a requirement into a supplier evaluation. Levelpath and LightSource do the same from their own starting points. Across the 21 interactions examined, 1 start here and 3 arrive here.

These providers already sit inside the buying process. They hold the request, the workflow and the approval trail, so reaching the next stage extends what they run rather than crossing into someone else's system.

Where it must move next

For any one provider to control the choice, its ranking would have to determine the winner rather than order the candidates.

What this could lead to

The ranking a buyer sees could be produced by the provider that also prepared the requirement.

Why the stage is rated forming

Procurement agents already evaluate suppliers, while Ramp now performs important parts of supplier research and comparison.

This rating considers every player active at Compare, not only procurement agents.

What the evidence does not show

This counts many providers together, not one product. No single offering is shown spanning the complete journey. Of the 4 interactions that touch this stage, 3 are agents making their own choices within a set aim, 1 follow a fixed rule, and 0 are not settled either way by the sources.

Competitive collision, demonstrated with payments

Three interactions arrive at Compare and one begins there, ranking options for the buyer.

Payments here

Ramp's agents score supplier responses before the employee selects a vendor.

What both may contest

Producing the comparison the buyer decides on. Both sides score the same responses, so the buyer relies on one.

Agents check a request against policy and carry the checked request onward.

Example

Vic.ai starts at the constraint check and carries an invoice through to payment. Corcentric and VERSO also begin their work here. Across the 21 interactions examined, 4 start here and 1 arrive here.

These providers already sit inside the buying process. They hold the request, the workflow and the approval trail, so reaching the next stage extends what they run rather than crossing into someone else's system.

Where it must move next

For any one provider to control the check, its verdict would have to stop a request that fails rather than flag it.

What this could lead to

The policy check could move from a person reading a rule to software applying one.

Why the stage is rated uncontested

No lateral player is demonstrated or proposed at the constraint check. Nothing outside procurement is contesting this stage.

This rating considers every player active at Check.

What the evidence does not show

This counts many providers together, not one product. No single offering is shown spanning the complete journey. Of the 5 interactions that touch this stage, 2 are agents making their own choices within a set aim, 1 follow a fixed rule, and 2 are not settled either way by the sources.

Agents draft, revise or price terms and pass them to an approver.

Example

Workday's contract negotiation agent revises terms and passes them to an approver. Vertice and Arkestro price and re-price within this stage. Across the 21 interactions examined, 3 start here and 3 arrive here.

These providers already sit inside the buying process. They hold the request, the workflow and the approval trail, so reaching the next stage extends what they run rather than crossing into someone else's system.

Where it must move next

For any one provider to control terms, it would need a mandate to bind its client, which nothing here establishes.

What this could lead to

Terms could start to be composed by software, with a person confirming rather than composing.

Why the stage is rated forming

Procurement agents draft and price terms, and AWS Marketplace generates the priced offer from the seller's rate card. Both compose the offer a buyer receives.

This rating considers every player active at Negotiate, not only procurement agents.

What the evidence does not show

This counts many providers together, not one product. No single offering is shown spanning the complete journey. Of the 6 interactions that touch this stage, 6 are agents making their own choices within a set aim, 0 follow a fixed rule, and 0 are not settled either way by the sources.

Competitive collision, demonstrated with marketplaces

Three interactions begin at Negotiate and three arrive there, drafting, revising or pricing terms.

Marketplaces here

AWS Marketplace generates the private offer automatically from the seller's rate card.

What both may contest

Producing the priced offer. Both sides compose it, so a buyer gets the offer from one or the other.

Agents deliver a prepared decision to the person who approves it.

Example

Stampli's Billy the Bot carries a request from the need to the approval, so the approver receives a decision that has already been assembled. Across the 21 interactions examined, 7 arrive here.

These providers already sit inside the buying process. They hold the request, the workflow and the approval trail, so reaching the next stage extends what they run rather than crossing into someone else's system.

Where it must move next

For any one provider to control approval, the prepared decision would have to become the decision.

What this could lead to

The approver could keep the decision and lose sight of how the options were narrowed.

Why the stage is rated emerging

Three lateral players act on the approval from different directions, and none of them does the procurement agent's job. The clearest case applies to two product classes only.

This rating considers every player active at Approve.

What the evidence does not show

This counts many providers together, not one product. No single offering is shown spanning the complete journey. Of the 7 interactions that touch this stage, 4 are agents making their own choices within a set aim, 2 follow a fixed rule, and 1 are not settled either way by the sources.

Shared stage with marketplaces

Seven of the 21 interactions arrive at Approve, delivering a prepared decision to the approver.

Marketplaces here

A marketplace setting decides whether the firm's approval step is reached at all.

Why this is not a contest

Different functions. The agent prepares what an approver decides on; the marketplace decides whether an approval is required. A buyer could have both, and would still have each doing its own thing.

Shared stage with contracts

Seven of the 21 interactions arrive at Approve, delivering a prepared decision to the approver.

Contracts here

A permitted client can mark the contract approval complete through the platform's interface.

Why this is not a contest

Different functions. The agent prepares the decision; the contract platform records that it was made. Nothing shows either doing the other's part.

Shared stage with systems of record

Seven of the 21 interactions arrive at Approve, delivering a prepared decision to the approver.

Systems of record here

Proposed: the ledger threshold would decide whether an approval is required at all.

Why this is not a contest

Different functions. The agent prepares an approval; the ledger would decide whether one is needed. One is a step in the decision, the other is a rule about the step.

Agents turn an approved decision into an order.

Example

Oracle Fusion and Vroozi both carry a request through to the order. Duvo reaches the order and works back to the approval. Across the 21 interactions examined, 1 start here and 2 arrive here.

These providers already sit inside the buying process. They hold the request, the workflow and the approval trail, so reaching the next stage extends what they run rather than crossing into someone else's system.

Where it must move next

For any one provider to hold this position across the journey, it would have to carry the same request from the need through to the order.

What this could lead to

Ordering could become a step the provider completes rather than one procurement performs.

Why the stage is rated emerging

Two lateral players act on what the order becomes, one issuing the instrument and one holding the agreement, and neither replaces creating the order itself.

This rating considers every player active at Order.

What the evidence does not show

This counts many providers together, not one product. No single offering is shown spanning the complete journey. Of the 3 interactions that touch this stage, 2 are agents making their own choices within a set aim, 1 follow a fixed rule, and 0 are not settled either way by the sources.

Shared stage with payments

Two interactions arrive at Order and one begins there, turning an approved decision into an order.

Payments here

Ramp creates a virtual card against the approved order; Brex can decline the transaction at authorisation.

Why this is not a contest

Different functions on different objects. The agent creates the order; the payments platform issues the instrument the order is paid with. Neither replaces the other.

Shared stage with marketplaces

Two interactions arrive at Order and one begins there.

Marketplaces here

The transaction completes on the marketplace and the agreement is created and held there.

Why this is not a contest

Different objects. The agent creates the firm's purchase order; the marketplace creates the agreement the order points at. The record splits rather than being competed for.

Agents carry an approved obligation through to payment.

Example

Vic.ai carries an invoice from the policy check through to payment. Moss runs the same span from the original request. Across the 21 interactions examined, 2 arrive here.

These providers already sit inside the buying process. They hold the request, the workflow and the approval trail, so reaching the next stage extends what they run rather than crossing into someone else's system.

Where it must move next

For any one provider to hold this position across the journey, it would have to carry the same obligation from the requirement through to payment.

What this could lead to

The provider could hold the record of what was bought and what was paid.

Why the stage is rated forming

Procurement agents carry an approved obligation through to payment, and BILL can execute the payment itself. Both run the same step.

This rating considers every player active at Pay, not only procurement agents.

What the evidence does not show

This counts many providers together, not one product. No single offering is shown spanning the complete journey. Of the 2 interactions that touch this stage, 1 are agents making their own choices within a set aim, 1 follow a fixed rule, and 0 are not settled either way by the sources.

Competitive collision, demonstrated with systems of record

Two interactions arrive at Pay, carrying an approved obligation through to payment.

Systems of record here

An authorized administrator can pay a bill despite the configured approval policy.

What both may contest

Carrying an approved obligation through to payment. Both sides execute the payment, so a buyer runs accounts payable on one of them.

The platform could shape what a request asks for before procurement sees it.

Example scenario

An employee raises a request inside the spend platform. The platform reads the vendor and transaction history it already holds and proposes what the request should ask for, so the requirement reaches procurement already narrowed.

The intake and approval workflow runs on the payments platform, so the request reaches the platform before it reaches procurement.

Where it must move next

To control demand, the platform would need the request it proposes to be the request that proceeds, which means procurement accepting requirements it did not write.

What this could lead to

The shape of a purchase could be set by software before procurement reads it.

What happens instead if it does not

Requests keep being written in a procurement system the platform never sees, and the platform receives a requirement it had no part in shaping.

Why this matters to a buyer

If demand is shaped where it is raised, the system a firm lets employees raise requests in becomes a competitive position, not an administrative choice.

Why the stage is rated emerging

Two players propose entering the need and neither is demonstrated there. The work shown at this stage is done by procurement's own providers.

This rating considers every player active at Need. The selected payments movement remains a proposition.

What must be true

• Requests are raised inside the spend platform rather than in a procurement system.
• The platform's vendor and transaction history is good enough to propose a requirement.
• Buyers accept a requirement the platform helped write.

What could prevent it

• Nothing in the evidence shows the platform acting at the need. A person still states it.
• Procurement writes the requirement in its own system and the platform never sees it.
• The business owner, not the platform, decides what is needed.

What the evidence does not show

This is a proposition derived from the player's existing position. It is not demonstrated in the current evidence.

Competitive collision, proposed with procurement agents

Five of the 21 interactions begin at the need, picking up a request and carrying it into later stages.

Payments here

Proposed: the platform would shape what the request asks for before procurement sees it.

What both may contest

Turning a stated need into the request the rest of the process works from. Both sides would produce the same thing, so a buyer would use one or the other.

The platform writes the request that goes out to suppliers.

Example

Ramp's procurement agents generate the RFx sent to suppliers, from a request that was raised inside the spend platform.

Ramp already holds the intake and approval workflow the request arrives in, so it has the request before anyone drafts a solicitation.

Where it must move next

To control what is bought, Ramp's requirement would have to become the one suppliers must answer, either because the buyer cannot easily rewrite it or because a policy rule makes it the approved form.

What this could lead to

The document that tells suppliers what to bid on could be written by a payments platform rather than by the buyer.

Why the stage is rated forming

Procurement agents already turn a need into a written requirement, and Ramp now generates the RFx that goes to suppliers. Both produce the same document.

This rating considers every player active at Define.

What the evidence does not show

The evidence does not show the requirement going out unchanged, and it does not show Ramp deciding what the firm needs.

Competitive collision, demonstrated with procurement agents

Seven of the 21 interactions begin at Define, turning a stated need into a written requirement.

Payments here

Ramp's agents generate the RFx that goes to suppliers.

What both may contest

Writing the requirement suppliers respond to. Both sides produce that document, so a buyer needs one of them and not both.

The platform researches which suppliers the buyer will look at.

Example

Ramp's procurement agents research supplier options for the request, using the vendor and transaction history the platform already holds.

Ramp sees vendor, invoice and spend information for purchases the firm has already made. That is a supplier list in everything but name.

Where it must move next

To control discovery, Ramp would need buyers to stop looking outside the set it assembles, either through a preferred-supplier rule or because the set is good enough that nobody checks.

What this could lead to

The set a buyer chooses from could be assembled by the platform that will also execute the payment.

Why the stage is rated forming

Procurement agents already assemble the supplier set, and Ramp now researches suppliers from its own vendor and payment history. Both produce the same shortlist, and three further players propose entering.

This rating considers every player active at Find.

What the evidence does not show

The evidence comes from Ramp's own announcement. The one named customer describes requests being routed from intake through to invoice approval, not the supplier research itself.

Competitive collision, demonstrated with procurement agents

Three interactions arrive at Find, assembling the supplier set a buyer will look at.

Payments here

Ramp's agents research supplier options from the vendor and transaction history the platform holds.

What both may contest

Assembling the supplier set. Both sides do it, from different data, and a buyer chooses whose set to look at.

The platform scores the proposals suppliers send back.

Example

Ramp can research suppliers, generate an RFx and score proposals. The employee still selects the winning supplier and the firm's stakeholders approve the purchase.

Ramp already sees vendor, payment, contract and spend information. That data can support supplier research, price comparison and proposal scoring.

Where it must move next

To control the supplier decision, Ramp would need its evaluation to determine the selected supplier or become binding through an approval rule. Alternatively, it can gain a different form of control by connecting the approved decision directly to payment execution.

What this could lead to

Ramp could connect supplier evaluation with transaction execution, making sourcing part of a broader finance and spend platform.

Why the stage is rated forming

Procurement agents already evaluate suppliers, while Ramp now performs important parts of supplier research and comparison.

This rating considers every player active at Compare.

What the evidence does not show

The evidence does not show one Ramp agent controlling the complete process. It also does not show Ramp selecting or approving the winning supplier.

Competitive collision, demonstrated with procurement agents

Three interactions arrive at Compare and one begins there, ranking options for the buyer.

Payments here

Ramp's agents score supplier responses before the employee selects a vendor.

What both may contest

Producing the comparison the buyer decides on. Both sides score the same responses, so the buyer relies on one.

The platform issues the card the approved purchase is made on, and can stop the transaction at the moment of payment.

Example

On approval of a purchase order request, Ramp creates a virtual card whose limit is set from the order total and updates as the order value changes. Brex declines a transaction at authorisation when it breaches a configured limit or policy.

Card issuance and spend controls are the platform's own product. The credential is an object it already owns, so attaching it to an approved order needs nothing new.

What this control could unlock

Holding the instrument gives the platform the transaction record for every purchase that runs through it, which is the same data its upstream sourcing work is built from. Control at the end of the journey is what funds the move to the beginning of it.

What this could lead to

The instrument a purchase runs through could be issued and held by a party outside procurement, and the record of it with them.

Why the stage is rated emerging

Two lateral players act on what the order becomes, one issuing the instrument and one holding the agreement, and neither replaces creating the order itself.

This rating considers every player active at Order.

What the evidence does not show

The card executes a purchase that the buyer has already selected and approved. It does not choose the supplier or authorize the purchase. No source says who issued the instrument before, so the platform's position here cannot be read as anyone's loss.

Shared stage with procurement agents

Two interactions arrive at Order and one begins there, turning an approved decision into an order.

Payments here

Ramp creates a virtual card against the approved order; Brex can decline the transaction at authorisation.

Why this is not a contest

Different functions on different objects. The agent creates the order; the payments platform issues the instrument the order is paid with. Neither replaces the other.

The marketplace could decide which suppliers a buyer considers, by changing what the channel is worth.

Example scenario

A buyer has already committed to a cloud spend figure. Buying a third-party product through the marketplace retires that commitment, so the shortlist narrows to suppliers listed there before anyone compares products.

Microsoft defines which purchases are eligible and holds the commitment balance the eligibility is measured against.

Where it must move next

To control discovery, the channel would have to become the only place a category can be bought, rather than the cheapest place to buy it.

What this could lead to

A supplier's presence on one channel could start to decide whether it is considered at all.

What happens instead if it does not

Buyers keep buying anywhere and simply pay for the choice out of a commitment already signed, so the channel changes the cost of a decision without changing the decision.

Why this matters to a buyer

A commitment signed for capacity can quietly become a constraint on supplier choice. Check what your existing commitments already imply about who you can buy from.

Why the stage is rated forming

Procurement agents already assemble the supplier set, and Ramp now researches suppliers from its own vendor and payment history. Both produce the same shortlist, and three further players propose entering.

This rating considers every player active at Find. The selected marketplaces movement remains a proposition.

What must be true

• The commitment rule starts to decide which suppliers reach a shortlist, not only what a channel costs.
• Buyers route categories beyond software through the marketplace.
• Procurement treats the marketplace catalogue as its supplier universe.

What could prevent it

• The evidence records this as a rule that changes what a channel costs, not as an operation performed at the shortlist.
• Buyers can still buy anywhere and pay for the choice out of a commitment already signed.
• Sourcing teams keep supplier discovery in their own system.

What the evidence does not show

This is a proposition derived from the player's existing position. It is not demonstrated in the current evidence.

Competitive collision, proposed with procurement agents

Three interactions arrive at Find, assembling the supplier set a buyer will look at.

Marketplaces here

Proposed: channel economics would narrow the set to suppliers listed on the marketplace.

What both may contest

Deciding which suppliers reach the buyer's consideration set. Both would determine the same set, by different means.

The marketplace produces the priced offer without either side speaking to the other.

Example

A buyer states requirements in AWS Marketplace and the platform evaluates them against the seller's pre-configured rate card, then generates the private offer. Requests outside the seller's criteria go to a salesperson instead.

The marketplace defines the rate-card construct, holds both sides' rules and runs the evaluation between them, so it is already standing where a negotiation would happen.

Where it must move next

To control terms, the marketplace's own rules would have to determine the price or the conditions, rather than evaluate rules the seller wrote.

What this could lead to

Negotiation could become rule configuration, and the party that holds the rules would hold the outcome.

Why the stage is rated forming

Procurement agents draft and price terms, and AWS Marketplace generates the priced offer from the seller's rate card. Both compose the offer a buyer receives.

This rating considers every player active at Negotiate.

What the evidence does not show

The marketplace sets the form an offer may take; the seller sets the prices inside it. Nothing in the evidence shows any party with authority to agree terms through an agent.

Competitive collision, demonstrated with procurement agents

Three interactions begin at Negotiate and three arrive there, drafting, revising or pricing terms.

Marketplaces here

AWS Marketplace generates the private offer automatically from the seller's rate card.

What both may contest

Producing the priced offer. Both sides compose it, so a buyer gets the offer from one or the other.

The marketplace decides which approval route a purchase follows.

Example

AWS Marketplace uses channel configuration to determine whether particular purchases are routed through procurement. It does not approve the purchase for the buyer, but it can influence which approval process the buyer encounters.

The marketplace owns the agreement structure and the pre-approval setting. The firm owns the workflow that setting can route around.

What this control could unlock

Deciding which purchases procurement ever sees is upstream of deciding what procurement approves. If the same rule reached product classes that carry invoice value, the channel would be shaping the firm's spend under review rather than routing it.

What this could lead to

Which approvals a firm performs could become a setting held outside the firm.

Why the stage is rated emerging

Three lateral players act on the approval from different directions, and none of them does the procurement agent's job. The clearest case applies to two product classes only.

This rating considers every player active at Approve.

What the evidence does not show

The pre-approval applies to two product classes that carry no invoice value. No customer is named in any of these records, so none of this is confirmed by a buyer.

Shared stage with procurement agents

Seven of the 21 interactions arrive at Approve, delivering a prepared decision to the approver.

Marketplaces here

A marketplace setting decides whether the firm's approval step is reached at all.

Why this is not a contest

Different functions. The agent prepares what an approver decides on; the marketplace decides whether an approval is required. A buyer could have both, and would still have each doing its own thing.

The order completes on the marketplace, and the agreement is created and kept there.

Example

After the firm's system approves, the transaction completes on AWS Marketplace and the agreement is created there programmatically. The subscription state then lives on the marketplace, and the firm's purchase order points at it.

The marketplace issues the entitlement, so it holds the object the order becomes.

What this control could unlock

Holding the agreement puts the marketplace in the renewal before anyone opens a sourcing event, because the entitlement and its dates are already on its side of the boundary.

What this could lead to

The record of what was bought could sit with the marketplace while the firm's system holds only a purchase order pointing at it.

Why the stage is rated emerging

Two lateral players act on what the order becomes, one issuing the instrument and one holding the agreement, and neither replaces creating the order itself.

This rating considers every player active at Order.

What the evidence does not show

The purchase order stays in the firm's system. Nothing shows that procurement has to consult the marketplace to do its own work.

Shared stage with procurement agents

Two interactions arrive at Order and one begins there.

Marketplaces here

The transaction completes on the marketplace and the agreement is created and held there.

Why this is not a contest

Different objects. The agent creates the firm's purchase order; the marketplace creates the agreement the order points at. The record splits rather than being competed for.

An approval inside the contract workflow can be marked complete by a permitted client.

Example

A user with the required permission can use Ironclad's API to mark an approval complete. This shows that a contract platform can sit inside the approval workflow, but the current evidence does not establish an agent making the decision.

The platform owns the workflow and the approval state inside it, and exposes that state through its public interface.

Where it must move next

To control the decision, contractual logic would need to determine whether the purchase is permitted, rather than record a decision made elsewhere.

What this could lead to

If approval is a state another system can write, the question could shift from who decides to who holds the permission.

Why the stage is rated emerging

Three lateral players act on the approval from different directions, and none of them does the procurement agent's job. The clearest case applies to two product classes only.

This rating considers every player active at Approve.

What the evidence does not show

This is an interface a permitted client can call. No agent is shown using it, so what exists is the ability to delegate rather than a delegate.

Shared stage with procurement agents

Seven of the 21 interactions arrive at Approve, delivering a prepared decision to the approver.

Contracts here

A permitted client can mark the contract approval complete through the platform's interface.

Why this is not a contest

Different functions. The agent prepares the decision; the contract platform records that it was made. Nothing shows either doing the other's part.

The ledger could decide which purchases need an approval at all.

Example scenario

A firm sets its approval threshold inside the ledger. Bills under that figure are paid without approval, and the procurement policy that describes an approval step is never reached.

The same system holds the bill, the threshold that decides whether it needs approving, and the instruction that pays it.

What this control could unlock

Holding both the rule and the instruction would let the financial system decide which purchases procurement ever sees.

What this could lead to

Approval policy could migrate from the procurement system to the ledger without anyone deciding to move it.

What happens instead if it does not

Procurement keeps the approval policy in its own system and the ledger only executes what that system has already approved.

Why this matters to a buyer

An approval policy is only as strong as the system that enforces it. Check whether yours is written where the money moves or somewhere the money can bypass.

Why the stage is rated emerging

Three lateral players act on the approval from different directions, and none of them does the procurement agent's job. The clearest case applies to two product classes only.

This rating considers every player active at Approve. The selected systems of record movement remains a proposition.

What must be true

• Approval thresholds are set in the ledger rather than in the procurement system.
• The ledger's record becomes the record the firm reconciles against.
• Firms accept an approval performed through a credential rather than by a person.

What could prevent it

• The documentation does not say what happens below the threshold, so nothing can be concluded about purchases under it.
• Procurement keeps the approval policy in its own system.
• Finance treats the administrator override as an exception rather than a route.

What the evidence does not show

This is a proposition derived from the player's existing position. It is not demonstrated in the current evidence.

Shared stage with procurement agents

Seven of the 21 interactions arrive at Approve, delivering a prepared decision to the approver.

Systems of record here

Proposed: the ledger threshold would decide whether an approval is required at all.

Why this is not a contest

Different functions. The agent prepares an approval; the ledger would decide whether one is needed. One is a step in the decision, the other is a rule about the step.

A single role can pay a bill whatever the approval policy says.

Example

An authorized administrator can pay a bill even when the configured approval process has not been completed. This shows that execution authority can sit in the financial system, but it does not show the system deciding what the approval policy should be.

The ledger holds the bill, its approval state and the payment instruction together, so nothing external stands between the instruction and the payment.

What this control could unlock

BILL already holds execution authority in the documented example. To move upstream, it would need to determine which purchases require approval before payment.

What this could lead to

A control that exists in the written policy may not exist at the moment of payment.

Why the stage is rated forming

Procurement agents carry an approved obligation through to payment, and BILL can execute the payment itself. Both run the same step.

This rating considers every player active at Pay.

What the evidence does not show

The override is available to one role. Nothing shows a bill being paid this way in practice, and the documentation is silent on what happens below the approval threshold.

Competitive collision, demonstrated with procurement agents

Two interactions arrive at Pay, carrying an approved obligation through to payment.

Systems of record here

An authorized administrator can pay a bill despite the configured approval policy.

What both may contest

Carrying an approved obligation through to payment. Both sides execute the payment, so a buyer runs accounts payable on one of them.

An operational event could become a purchase need without a person raising it.

Example scenario

A maintenance system records that a pump has failed a scheduled inspection. It converts that reading into a purchase need for a replacement part, and procurement receives a requirement it did not start.

The operations system holds the asset record, the condition data and the maintenance schedule, so it sees the event that creates the need before anyone writes it down.

Where it must move next

To control demand, the operational system's reading would have to be the requirement that proceeds, which means procurement accepting requests it did not create.

What this could lead to

Demand could start being generated by systems that watch equipment rather than by people who watch budgets.

What happens instead if it does not

A person continues to notice the event and raise the request, and the operational system remains a source of information rather than a source of demand.

Why this matters to a buyer

If demand starts in an operational system, procurement's intake stops being the front door and becomes a review of a request that already exists.

Why the stage is rated emerging

Two players propose entering the need and neither is demonstrated there. The work shown at this stage is done by procurement's own providers.

This rating considers every player active at Need. The selected operational platforms movement remains a proposition.

What must be true

• Operational data identifies a real purchase need rather than a fault to be repaired.
• The system is permitted to initiate a request.
• Procurement rules constrain the resulting request.

What could prevent it

• Operational data is incomplete and the reading does not establish a purchase.
• A person must define the need before it becomes a request.
• Procurement refuses requests created outside its own workflow.

What the evidence does not show

This is a proposition derived from the player's existing position. It is not demonstrated in the current evidence.

The operational record could become the requirement suppliers are asked to meet.

Example scenario

The maintenance system already holds the part number, the specification and the site constraints. It writes those into the requirement, so the request that reaches procurement is already specified.

The system holds the asset specification and the service history, which is most of what a requirement has to say.

Where it must move next

To control specification, the operational record would have to be treated as authoritative, so that rewriting it is not an option.

What this could lead to

What a firm asks suppliers for could be produced by a system that has never seen a supplier.

What happens instead if it does not

Procurement rewrites the requirement in its own template and the link back to the asset record is lost, so the operational data informs the request without shaping it.

Why this matters to a buyer

The quality of your requirements may already depend on a system procurement does not own. Ask who would notice if the asset record were wrong.

Why the stage is rated forming

Procurement agents already turn a need into a written requirement, and Ramp now generates the RFx that goes to suppliers. Both produce the same document.

This rating considers every player active at Define. The selected operational platforms movement remains a proposition.

What must be true

• Requirements can be generated from the operational event.
• The specification held by the operations system is current and complete.
• Procurement accepts a requirement it did not write.

What could prevent it

• The operational record describes an asset, not a commercial requirement.
• Engineering or the business owner must confirm what is actually needed.
• Procurement rewrites the requirement in its own template and the link is lost.

What the evidence does not show

This is a proposition derived from the player's existing position. It is not demonstrated in the current evidence.

The operations system could start the supplier search itself.

Example scenario

Having written the requirement, the system looks up the suppliers approved for that part and puts a shortlist in front of the buyer, so the search starts before procurement opens a sourcing event.

The system already knows which supplier serviced the asset last time and what was fitted, which is a supplier shortlist in everything but name.

Where it must move next

To control discovery, the system would need access to supplier and policy information it does not hold today, and buyers would have to stop searching outside its shortlist.

What this could lead to

The supplier set could be assembled by a system procurement does not run and does not read.

What happens instead if it does not

Sourcing teams treat supplier selection as their own decision and the operational shortlist is never consulted, so the last supplier keeps winning by habit rather than by rule.

Why this matters to a buyer

Repeat purchasing may already be decided by service history rather than by sourcing. Ask how many of your renewals were ever competitively tested.

Why the stage is rated forming

Procurement agents already assemble the supplier set, and Ramp now researches suppliers from its own vendor and payment history. Both produce the same shortlist, and three further players propose entering.

This rating considers every player active at Find. The selected operational platforms movement remains a proposition.

What must be true

• The system can reach supplier and policy information it does not itself hold.
• Procurement rules constrain the resulting search.
• Buyers accept a shortlist assembled outside procurement.

What could prevent it

• The operational platform has no access to supplier or policy information.
• Preferred-supplier and compliance rules live in procurement and are not exposed to it.
• Sourcing teams treat supplier selection as their own decision.

What the evidence does not show

This is a proposition derived from the player's existing position. It is not demonstrated in the current evidence.

A seller's agent could make its offer visible to a buyer's agent at the moment of search.

Example scenario

A buyer's agent publishes a machine-readable requirement. A seller's agent reads it, decides the seller can meet it and returns a structured offer, so the seller enters the buyer's shortlist without a salesperson.

The seller holds the price, the availability and the terms the buyer's agent is looking for, and is the only party that can publish them.

Where it must move next

To move beyond access, the seller's agent would need its offer to change what the buyer compares, not merely to appear inside the comparison.

What this could lead to

Supplier discovery could stop being something buyers do and start being something sellers answer.

What happens instead if it does not

Sellers keep waiting to be found through catalogues and salespeople, and buyer-side agents keep searching sources the seller does not control.

Why this matters to a buyer

If sellers can answer your agents directly, the supplier set stops being something you assemble and starts being something you receive. Decide now who may answer.

Why the stage is rated forming

Procurement agents already assemble the supplier set, and Ramp now researches suppliers from its own vendor and payment history. Both produce the same shortlist, and three further players propose entering.

This rating considers every player active at Find. The selected seller-side agents movement remains a proposition.

What must be true

• Buyer and seller agents exchange machine-readable requirements and offers.
• The buyer permits seller agents to participate.
• Both agents operate within defined mandates.

What could prevent it

• There is no shared protocol between the two sides.
• The buyer refuses direct agent access to its requirements.
• Trust and verification requirements prevent autonomous interaction.

What the evidence does not show

This is a proposition derived from the player's existing position. It is not demonstrated in the current evidence.

A seller's agent could answer the buyer's comparison while it is being made.

Example scenario

The buyer's agent scores three offers. The seller's agent sees that it is second on price, supplies a revised configuration and re-enters the comparison before the buyer closes it.

Only the seller knows what it can flex on, and a seller's agent could apply that in the time a comparison stays open.

Where it must move next

To control the comparison, the seller would need to shape the criteria the buyer scores against, not only the offer being scored.

What this could lead to

Comparison could become a live exchange rather than a fixed set of submitted offers.

What happens instead if it does not

Offers stay fixed once submitted, and comparison remains a one-shot evaluation of what was sent rather than a live exchange.

Why this matters to a buyer

A comparison that can be answered while it is open is a different negotiation. Decide whether your evaluation is a sealed process or a conversation.

Why the stage is rated forming

Procurement agents already evaluate suppliers, while Ramp now performs important parts of supplier research and comparison.

This rating considers every player active at Compare. The selected seller-side agents movement remains a proposition.

What must be true

• The interaction supports offers, counteroffers and constraints.
• The buyer's evaluation is visible to the seller in a usable form.
• Both agents operate within defined mandates.

What could prevent it

• Sellers cannot change terms dynamically.
• The buyer refuses to expose an evaluation while it is still open.
• People retain the authority to change an offer.

What the evidence does not show

This is a proposition derived from the player's existing position. It is not demonstrated in the current evidence.

Both sides could settle terms through agents rather than through people.

Example scenario

The buyer's agent asks for a longer payment term and a volume break. The seller's agent concedes the term, refuses the break and offers a shorter commitment instead, inside a mandate each side has set in advance.

The seller holds the terms it can concede and the limits it cannot, which is exactly what a negotiation mandate would encode.

Where it must move next

To control terms, an agent would need a mandate to bind its firm, which nothing in the evidence establishes for any party.

What this could lead to

The speed of a negotiation could stop being limited by how often two people can meet.

What happens instead if it does not

People on both sides keep the authority to agree, and agents prepare positions that a person still has to carry into a conversation.

Why this matters to a buyer

The constraint on negotiation speed is mandate, not capability. Decide what an agent may concede before anyone asks you to grant it.

Why the stage is rated forming

Procurement agents draft and price terms, and AWS Marketplace generates the priced offer from the seller's rate card. Both compose the offer a buyer receives.

This rating considers every player active at Negotiate. The selected seller-side agents movement remains a proposition.

What must be true

• Both agents operate within defined mandates.
• The interaction supports offers, counteroffers and constraints.
• Each side accepts an outcome reached without a person in the exchange.

What could prevent it

• People retain negotiation authority on both sides.
• Nothing in the evidence shows any party letting an agent agree terms on its behalf.
• Trust or verification requirements prevent autonomous interaction.

What the evidence does not show

This is a proposition derived from the player's existing position. It is not demonstrated in the current evidence.