The buying decision is moving inside the software
Cloudflare's August 2026 Agents Week announcements put two pieces of infrastructure on the same roadmap: Wallets, which gives software a way to hold identity and transact, and Radar, which lets users explore Internet data through natural language. The immediate headline is that software can increasingly find something, evaluate it, and pay for it without a person completing every step.
That headline is too narrow.
The important change is not that software can transact. Payment was always going to become an engineering problem with an engineering solution. The larger shift is that software will increasingly select services on your behalf. It will choose a data provider, an enrichment service, a logistics carrier, a model endpoint, a compliance vendor, or a specialist workflow based on rules you may never see.
That creates a board-level question: who decides what software buys?
If the answer is an opaque catalog, the market will reward visibility over quality. The cheapest result, the most heavily promoted listing, or the service with the best machine-readable metadata may win even when it produces inferior outcomes. Procurement risk will move upstream, into discovery and ranking, before a contract is ever signed.
Discovery becomes a commercial control point
Traditional procurement assumes that a person creates a shortlist. That person checks references, asks for security documentation, compares prices, negotiates terms, and explains the decision to finance or legal teams.
Automated purchasing compresses those steps into a selection function. The software may receive a task, query a directory, filter by price and availability, and choose a provider in seconds. The result is efficient, but efficiency amplifies whatever criteria the system can observe.
That is the problem. Price is easy to compare. Presence is easy to measure. Capability quality is not.
A service catalog without reliable evidence will produce predictable distortions:
- New providers with strong marketing will outrank proven providers with poor metadata.
- Low-cost services will win work by hiding failure rates, support costs, or data restrictions.
- Providers will optimize descriptions for machine ranking instead of improving outcomes.
- Sponsored placement will look like neutral recommendation unless the ranking policy is visible.
- A single bad selection rule will replicate across thousands of transactions.
This is not a hypothetical concern. Search engines, app stores, ad exchanges, and procurement portals have spent years dealing with versions of the same problem. Once software becomes the buyer, the ranking mechanism becomes part of the commercial infrastructure.
Wallets solve authority, not judgment
Cloudflare's Wallets announcement matters because it addresses a real missing primitive. Software needs a durable identity, controlled authority, and a way to act on an owner's behalf. Those capabilities make machine-mediated commerce possible at useful scale.
They do not answer whether a selected provider is competent, safe, compatible, or worth the price.
A wallet can authorize a purchase. It cannot determine whether a service's advertised capability matches its actual behavior. A transaction record can prove that money moved. It cannot prove that the buyer received a correct result, that customer data was handled within policy, or that a cheaper option would have produced a better outcome.
This is the distinction procurement teams need to make now:
- Authorization answers whether software may buy.
- Discovery answers what it can consider.
- Evaluation answers what it should trust.
- Accountability answers who owns the result.
Most current discussions focus on the first item because it is concrete. The other three determine whether automated commerce creates savings or simply automates bad purchasing decisions.
The catalog needs evidence, not descriptions
A useful service directory cannot stop at a name, a price, and a list of features. Software needs structured evidence that can be evaluated consistently across providers.
At minimum, every listing should expose:
- A verifiable identity tied to an organization, operator, or accountable owner.
- Machine-readable capabilities with explicit limits and exclusions.
- Versioned compatibility information, including supported protocols and data formats.
- Security and compliance evidence appropriate to the service's risk.
- Operating history, including availability, response quality, and incident records.
- Commercial terms covering price changes, refunds, usage limits, and termination.
- Data handling rules, jurisdictions, retention periods, and subprocessors.
- References or outcome measurements that distinguish successful completion from mere availability.
The point is not to create another vendor questionnaire. It is to make evidence portable and comparable. If every provider describes performance differently, software will default to the fields that are easiest to normalize, usually price and visibility.
That would turn service discovery into a race toward polished metadata. Buyers need a way to compare claims against independently verifiable facts.
Architecture must separate finding from choosing
Teams designing this infrastructure should treat discovery and selection as separate functions with separate controls.
The discovery system can answer which providers appear eligible. A policy system should determine which criteria matter for a particular purchase. A decision record should preserve the candidates considered, the evidence available at the time, the rule that produced the ranking, and the reason the final choice was made.
That record matters when the purchase is small but repeated. A single low-value transaction may not justify review. Ten thousand automated selections can create material financial, operational, or regulatory exposure.
Architects should also assume that catalogs will change while software is running. Providers will alter pricing, capabilities, data practices, and ownership. Listings need version history, expiry dates for evidence, and explicit handling for stale or disputed claims.
The selection policy should support constraints such as:
- Never send regulated data to a provider without current compliance evidence.
- Prefer providers with demonstrated success for this workload, not merely broad feature coverage.
- Require a human approval threshold for purchases above a defined amount.
- Penalize repeated failures even when the provider remains the cheapest option.
- Preserve a fallback provider when availability or geopolitical risk matters.
Those rules turn a catalog from a shopping list into decision infrastructure.
Procurement needs to own the ranking policy
This is where the procurement function must change. Procurement cannot remain responsible only for approving suppliers after technical teams have already embedded a service into software.
The team needs a voice in how services are discovered, scored, and selected. It should define which evidence is mandatory, which claims require verification, and which decisions require escalation. Legal and security teams should help specify the evidence, but they should not be forced to review every routine purchase manually.
The goal is a policy that software can apply consistently and humans can audit when needed.
That connects directly to the concern raised in Kitesurf Is a Procurement Test, Not a Browser Upgrade. When software can operate across unfamiliar systems, access control is only part of the problem. The organization also needs a clear explanation for why one external service was selected over another.
The same logic applies to a growing technology cluster. As Is London’s AI Hub Making Procurement Harder? argued, easier discovery can increase evaluation burden. Machine-mediated catalogs will accelerate that tradeoff. More options will arrive faster than any procurement team can inspect manually.
What to do before automated buying becomes normal
Start with a narrow category where service selection already happens frequently. Define the evidence required for each provider, the ranking criteria, the approval thresholds, and the audit record. Then test the catalog with deliberately misleading inputs: a cheaper provider with worse reliability, a highly visible provider with incomplete compliance evidence, and a new provider with strong independent results but limited history.
If the system always chooses the cheapest or most visible option, you have discovered a governance flaw before it becomes a spending problem.
Cloudflare's announcements make software-to-software commerce feel immediate. The competitive advantage will not belong to the company that merely enables transactions. It will belong to the company that makes good selections explainable, verifiable, and repeatable.
BluePages is built around that missing decision infrastructure: service records that combine identity, capabilities, compatibility, and trust evidence before software makes a choice. Define your selection criteria now, before an automated buyer defines them for you.