When buyer agents meet supplier agents

What changes when both sides use agents?

Most demonstrations of agentic commerce begin with one agent and one cooperative system. A consumer asks an assistant to find a product. A merchant exposes a catalog and checkout. The assistant chooses, the merchant accepts, and a payment follows.

Business-to-business commerce is less tidy. The buyer and supplier are independent organizations with different policies, data, incentives, and systems of record. Each may use multiple agents. Neither side should have to trust the other's internal workflow. A valid result may require supplier qualification, budget checks, technical review, negotiation, approvals, tax treatment, a purchase order, fulfillment evidence, and reconciliation.

The important unit is therefore not the purchasing agent. It is the cross-company agent boundary: the controlled surface through which two organizations let autonomous systems discover, propose, negotiate, commit, and report without merging their private systems.

This boundary is becoming practical in 2026. SAP describes a Joule Sourcing Assistant that can support supplier discovery, sourcing-event creation, bid analysis, and counteroffers. In June, SAP reported that procurement leaders were focused on process foundations, clean data, and the limits of black-box automation, not only model capability, in a direct procurement roundtable. Mastercard said in May that partners in Australia and New Zealand were enabling AI-driven procurement to source from approved suppliers, place orders, and initiate payments. That statement is a company account of partner activity, not independent evidence of general adoption.

Together, these developments show the direction. They do not yet show a fully open market of independently operated buyer and supplier agents. The gap between those two states is where the architecture gets interesting.

Procurement is a boundary problem

Inside one company, a procurement agent can draw on trusted identity, category policies, budgets, supplier records, and approval workflows. A supplier agent can do the same with inventory, capacity, cost, margin, customer eligibility, and delivery commitments.

The problem begins when the agents meet. The buyer cannot expose its full budget strategy. The supplier cannot expose its cost model or capacity plan. Yet both need enough shared structure to reach a usable outcome.

A cross-company interaction must preserve two security domains:

• private commercial strategy, including walk-away points, ranking logic, forecasts, and internal approvals;
• shared commercial state, including requests, offers, accepted terms, obligations, receipts, and permitted evidence.

Confusing these domains creates immediate risk. If a buyer agent sends its maximum budget as a negotiation parameter, the supplier can price to the ceiling. If a supplier agent exposes its marginal cost or hidden capacity constraints, the buyer can exploit them. If either side treats an external message as an internal instruction, prompt injection becomes a commercial control failure.

The boundary must therefore be expressive enough for commerce and restrictive enough for strategy.

A buyer agent is not one system

“Buyer agent” sounds singular, but enterprise purchasing already divides responsibility. One system finds suppliers. Another checks sanctions and qualification. A sourcing platform runs an RFQ. A policy engine checks spend authority. An ERP creates a purchase order. A payment system releases funds. People approve exceptions.

Autonomy does not remove this separation. It makes orchestration more important.

Plural Worlds models the buyer side as five roles, which may be implemented by one agent or many:

1. Discovery: find possible suppliers and normalize their offerings.
2. Qualification: establish whether a supplier is eligible for this category, jurisdiction, and risk profile.
3. Sourcing: request proposals, compare terms, and negotiate within policy.
4. Commitment: obtain the required approvals and create an authorized order or agreement.
5. Execution: monitor delivery, accept evidence, reconcile invoices, and initiate settlement.

The supplier side has a corresponding shape: publish capabilities, qualify the buyer, configure an offer, reserve capacity, authorize a commitment, fulfill, and issue evidence.

This model helps avoid a misleading architecture. A conversational agent does not need direct, standing permission to perform every step. It can call controlled services, present proposed actions for approval, and receive narrowly scoped credentials for particular transactions.

Discovery must describe capability, not only products

Consumer catalogs are optimized around items. B2B discovery often begins with capabilities and constraints.

A manufacturer searching for calibration services may care about accreditation scope, geographic coverage, instrument classes, turnaround time, on-site availability, evidence formats, insurance, and quality-system compatibility. The relevant offering is not a single SKU. It is a service capability that can be configured into a proposal.

An agent-readable supplier surface should separate:

• stable claims, such as certifications and service regions;
• dynamic claims, such as current capacity and lead time;
• commercial terms, such as price and minimum order;
• qualification evidence, including issuer, scope, and expiry;
• interaction methods, including quote requests and negotiation;
• confidence and provenance, so an agent knows which data is authoritative.

Machine readability does not eliminate verification. It makes provenance more important. A supplier should be able to state a capability without giving every potential buyer the same access to supporting evidence. A buyer should be able to request proof appropriate to the transaction.

RFQs become stateful conversations

An RFQ is not one prompt and one response. It is a stateful commercial process.

The buyer may request 8,000 units delivered in two locations. One supplier can meet the quantity but proposes a different delivery split. Another offers a lower price if the buyer changes the packaging specification. A third needs a forecast commitment before reserving capacity. Technical, legal, and operational terms can move independently.

Agents can make this process faster, but speed magnifies ambiguity. Each proposal needs an identifier and version. A counteroffer should state what it replaces. An acceptance should refer to the exact current terms. Expiry, withdrawal, and parallel alternatives need explicit handling. Otherwise two systems can both believe they accepted a deal while referring to different versions.

This is one reason autonomous negotiation should not be represented as an unstructured conversation alone. Natural language can explain and persuade. Commercial state needs typed objects or another deterministic representation beneath it.

Authority must travel to the boundary

The supplier needs more than the buyer agent's identity. It needs confidence that the agent may request information, disclose relevant buyer data, negotiate the specific category, and eventually create a commitment within defined limits.

The buyer needs the mirror image. A response from a supplier-branded agent does not prove that the agent may reserve capacity, change payment terms, or bind the supplier to a delivery date.

The safe pattern is not to expose internal approval graphs. Each organization can produce a counterparty-facing proof or decision that is limited to the action at hand.

For example, a buyer may establish that:

• the agent acts for a named legal entity;
• the mandate covers laboratory services in the Netherlands;
• the transaction value may not exceed EUR 50,000;
• deviations from net-30 payment require a human approval;
• the mandate expires before the next quarter;
• a particular acceptance was checked against those conditions.

The supplier can verify the scoped result without learning which employee approved the annual budget or how the buyer ranks vendors internally.

Commerce protocols solve different parts

The emerging commerce stack is moving quickly. Shopify documents agent integrations around the Universal Commerce Protocol, and in June it deprecated Storefront MCP cart tools in favor of UCP cart MCP. Stripe's Agentic Commerce Protocol defines a checkout path between applications or agents and sellers and remains in private preview. Google's Agent Payments Protocol focuses on mandates and evidence for agent-performed payments.

These are important components. They do not make every B2B process look like retail checkout.

A configurable service, production commitment, multi-line RFQ, or framework agreement may need discovery, negotiation, qualification, and obligation tracking before a checkout session makes sense. The right architecture composes protocols according to responsibility. A commerce protocol can handle merchant capabilities and checkout. A payment protocol can prove authorization for value movement. An agreement layer can record authority, proposals, acceptance, and obligations. Enterprise systems remain responsible for internal policy and systems of record.

The eight boundary objects

Plural Worlds proposes a minimal set of object families for cross-company procurement. The names are descriptive, not a claim that every industry should adopt one schema.

1. Capability claim: what the supplier says it can provide, with scope and provenance.
2. Qualification request: what evidence the buyer needs and under which disclosure policy.
3. Commercial request: the goods, services, constraints, and decision timetable.
4. Proposal: priced terms, validity, dependencies, and the version it answers.
5. Authority proof: a scoped result establishing that an agent may take a particular action.
6. Agreement record: the exact terms both organizations accepted.
7. Obligation event: delivery, acceptance, exception, or other performance state.
8. Settlement evidence: instructions and receipts from external payment or accounting systems.

Each object should identify its issuer, subject, transaction context, version, and integrity mechanism. Sensitive fields should be disclosed selectively. A recipient should know whether a claim is current and whether the issuer could revoke or supersede it.

Machine speed requires deliberate friction

Procurement teams often describe autonomy as a way to remove friction. Some friction is waste. Re-keying data, chasing routine approvals, and comparing inconsistent quotes are good targets for automation.

Other friction is a control. A cooling-off period can prevent a cascade. A human approval can protect a novel or high-value purchase. A supplier confirmation can ensure that an algorithmic quote reflects real capacity. Rate limits can slow adversarial agents. Segregation of duties can stop one compromised system from discovering, approving, ordering, and paying by itself.

The goal is not zero friction. It is typed friction: controls triggered by value, novelty, risk, uncertainty, or policy rather than by every transaction equally.

This becomes essential when agents negotiate at machine speed. A flaw that produces one bad purchase per hour is different from a flaw that produces ten thousand commitments before a person sees an alert.

What a credible pilot should prove

A procurement pilot should not be judged only by cycle time or savings claims. It should demonstrate that the cross-company boundary behaves correctly.

At minimum, test whether the system can:

• keep private strategy out of counterparty messages;
• identify authoritative supplier data and its provenance;
• reject an expired or out-of-scope mandate;
• preserve proposal versions through counteroffers;
• require approval for a defined exception;
• prevent duplicate or conflicting commitments;
• retain evidence without overexposing personal or commercial data;
• recover safely when a model, tool, supplier endpoint, or payment system fails.

The most useful early deployments will probably be bounded. Approved suppliers, a narrow category, explicit value limits, and human review of exceptions can create real value while exposing the architecture's weaknesses.

The opportunity beyond autonomous checkout

Agentic commerce is often presented as a new interface for buying. In B2B markets, it can become something larger: a new operating surface between organizations.

Buyer and supplier agents could continuously align forecast changes, capacity, service levels, exceptions, and commercial terms. They could shorten sourcing cycles and make low-value negotiations economical. They could also concentrate power, hide discrimination, leak strategy, or create commitments no authorized person intended.

The differentiating infrastructure will not be the assistant that says it found a good deal. It will be the boundary that lets two independent organizations understand what their agents are allowed to share, propose, accept, execute, and prove.

Related Plural Worlds research

Agent identity is not commercial authority develops the authority model used at this boundary. The 2026 agent protocol stack shows how communication, commerce, payment, and agreement responsibilities can compose.