Direct RFQ Today and Tomorrow: A Step-by-Step Guide to the Agentic B2B Transaction

For decades, the B2B request-for-quotation process has followed the same basic pattern.

A buyer prepares a specification, sends an email or PDF, waits for the supplier to review it, answers additional questions and eventually receives a quotation. Data is repeatedly copied between spreadsheets, inboxes, ERP systems, CRM platforms and quotation templates.

Direct RFQ changes this architecture.

It transforms the request for quotation from a human-readable document into a structured, machine-readable business transaction that can move directly between the systems—or AI agents—of the buyer and the supplier.

Direct RFQ is not yet a single universal protocol. It is an emerging operational model built from existing procurement standards, APIs, enterprise systems and new agent communication technologies.

This guide explains how Direct RFQ works today, how companies can implement it step by step and how it may evolve into a foundation for Agentic Commerce.

Part One: What Direct RFQ Means Today

What is Direct RFQ?

Direct RFQ is a private and structured request for quotation sent directly to a selected supplier.

It is different from a broadcast RFQ, where a requirement is published on a marketplace or sourcing platform and distributed to multiple potential suppliers.

In a Direct RFQ process:

the buyer identifies a specific supplier,
both parties can be authenticated,
the request follows a defined data structure,
commercial information remains inside a trusted relationship,
the supplier’s systems can process the request automatically,
the response can be returned in a machine-readable format.

A Direct RFQ may be exchanged through:

EDI,
XML,
JSON,
a procurement API,
an ERP integration,
a private data-space connector,
an MCP tool,
an A2A agent endpoint.

The concept builds on established electronic procurement standards. OASIS Universal Business Language, for example, defines formal Request for Quotation and Quotation documents, while industrial initiatives such as Catena-X are developing interoperable RFQ exchange models for manufacturing networks.

Direct RFQ is therefore not a replacement for every existing procurement standard. It is the next operational layer built on top of them.

Step 1: Detect the Purchasing Intent

A traditional RFQ usually begins when a person notices a requirement.

A Direct RFQ can begin when a business system detects it.

The trigger may come from:

inventory falling below a defined level,
a new production order,
a maintenance alert,
a delayed delivery,
a project approval,
an expiring supplier agreement,
an increase in forecast demand,
a failure of an existing component,
a change in raw-material prices.

The source may be an ERP, MRP, WMS, CMMS, procurement platform or supply-chain planning system.

At this stage, AI does not need to make a purchasing decision. Its first role is to identify that a valid procurement need exists and gather the surrounding context.

Today

The trigger often creates:

a purchase requisition,
a sourcing task,
an email notification,
a draft RFQ.

Tomorrow

The trigger will increasingly create an agent task:

Secure 500 units of the approved component before 15 August, within the authorized budget and supplier policy.

The procurement agent will then decide which systems, suppliers and workflows must be activated.

Step 2: Convert the Need into a Structured RFQ

A purchasing intention is not yet a valid request for quotation.

The next step is to compile a complete RFQ specification.

A basic Direct RFQ should contain:

RFQ identifier,
buyer and supplier identifiers,
product name or part number,
quantity and unit of measure,
required delivery date,
delivery destination,
currency,
Incoterms,
payment requirements,
response deadline.

A more advanced industrial RFQ may include:

CAD files,
tolerances,
materials,
production methods,
quality requirements,
required certificates,
test procedures,
packaging requirements,
approved substitutes,
forecast volumes,
contract duration,
sustainability information.

Catena-X’s RFQ Exchange illustrates this direction. Its standard describes a semantic RFQ model and an API-based exchange mechanism designed to transfer manufacturing requirements between buyers, manufacturers and enterprise applications while preserving control over industrial data.

Today

Many companies already use structured fields inside procurement platforms, but the information is often converted into a PDF before reaching the supplier.

Tomorrow

The structured record itself will become the primary transaction. The PDF will be generated only when a human-readable representation is required.

Step 3: Validate the RFQ Before Sending It

Incomplete RFQs are one of the main sources of delay in B2B sales.

Before the request is submitted, the system should check:

whether all mandatory fields are present,
whether quantities and units are valid,
whether the requested delivery date is realistic,
whether the product identifier is recognized,
whether technical requirements are internally consistent,
whether required attachments are included,
whether the request follows company procurement policy.

An AI agent may help interpret natural-language descriptions or extract information from documents. However, the final validation should use deterministic rules.

For example:

quantity must be greater than zero,
delivery date cannot precede the quotation deadline,
currency must come from an approved code list,
the requested substitute must meet defined technical constraints,
the purchase value must fall within the requester’s authority.

Today

Validation usually checks whether a form has been completed.

Tomorrow

Validation will evaluate whether the RFQ is technically, commercially and procedurally executable.

The key question will not be:

Has every field been filled in?

It will be:

Can a supplier safely calculate and commit to an offer based on this information?

Step 4: Select and Authenticate the Supplier

Direct RFQ is based on targeted communication.

The buyer must know:

which supplier should receive the request,
whether the supplier is approved,
which endpoint accepts RFQs,
which products or capabilities the supplier supports,
how the receiving system must be authenticated.

In an agent-driven environment, this capability may be published through an A2A Agent Card.

The Agent2Agent protocol provides a standardized model through which independent agents can discover capabilities, exchange tasks and communicate across different frameworks and vendors. An Agent Card can describe the agent’s identity, service address, capabilities, supported interaction methods and security requirements.

A supplier agent could advertise capabilities such as:

accepting industrial-material RFQs,
checking live availability,
producing customer-specific quotes,
proposing approved substitutes,
retrieving compliance documentation,
accepting order confirmations.

Today

Supplier selection is usually based on an approved-vendor list inside the procurement system.

Tomorrow

Supplier selection will combine:

approved-vendor status,
verified machine identity,
declared agent capabilities,
category competence,
delivery coverage,
past execution performance,
transaction-level authorization.

Step 5: Send the Direct RFQ

Once validated, the RFQ is sent directly to the supplier.

A simplified request may look conceptually like this:

{
  "rfq_id": "RFQ-2026-00841",
  "buyer_id": "BUYER-PL-001",
  "supplier_id": "SUPPLIER-EU-014",
  "currency": "EUR",
  "delivery_terms": "DDP",
  "response_due": "2026-07-14T14:00:00+02:00",
  "items": [
    {
      "manufacturer_part_number": "SKU-123",
      "quantity": 500,
      "unit": "piece",
      "required_delivery_date": "2026-08-15",
      "delivery_location": "Warsaw, Poland"
    }
  ]
}

The request may be transported through:

REST API,
EDI gateway,
data-space connector,
message broker,
MCP-compatible tool,
A2A task message.

The transport mechanism is less important than the business guarantees around it:

identity,
authorization,
confidentiality,
integrity,
acknowledgement,
traceability.

Today

Most integrated RFQ processes depend on dedicated connections between known applications.

Tomorrow

A2A may make agent communication more portable across different vendors and platforms, while established procurement schemas continue to define the commercial data.

Step 6: Let the Supplier Agent Orchestrate the Internal Systems

The receiving agent should not invent an answer.

Its role is to coordinate the systems containing authoritative business data.

The supplier agent may query:

PIM for product specifications,
ERP for cost and customer conditions,
WMS for stock,
MRP or APS for production capacity,
CPQ for configuration and pricing,
CRM for contract terms,
TMS for transport costs,
DMS for technical and compliance documents,
risk systems for credit or sanctions checks.

This is where the Model Context Protocol can become important.

MCP provides a standardized way for agents to access tools and data sources. In a Direct RFQ architecture, the supplier agent may communicate with the buyer’s agent through A2A while using MCP-compatible tools to access its own enterprise systems.

The distinction is:

A2A connects an agent to another agent.
MCP connects an agent to tools, systems and data.

The MCP roadmap places enterprise authorization, observability and auditable access among its priorities, reflecting the requirements of controlled business deployments.

Step 7: Calculate the Offer with Deterministic Rules

The language model should never be the final source of price, margin or delivery commitment.

A valid quotation should be generated by approved pricing and business logic.

The calculation may consider:

current product cost,
raw-material indexes,
required margin,
customer-specific discounts,
requested quantity,
inventory level,
available production capacity,
setup costs,
freight,
payment terms,
credit risk,
urgency,
contract value.

Conceptually:

[
Quote Price =
Cost

Required Margin
Logistics
Risk
Financing
Configuration
Approved Discount
]

The agent can select the right tools, collect the input data and explain the result. It should not be allowed to bypass the pricing engine.

Hard rules should include:

minimum margin,
maximum discount,
maximum order value,
inventory reservation limits,
customer credit limits,
permitted delivery regions,
approval thresholds.

Today

Automated pricing is already common for standard products, transport, configurable software and selected manufacturing processes.

Tomorrow

Pricing will become more capacity-aware, context-sensitive and continuously updated.

A supplier may offer a better price when:

production capacity is temporarily unused,
an order fits an existing production run,
delivery can be consolidated,
the buyer accepts a different date,
a substitute product is available,
payment terms improve cash flow.

Step 8: Return a Machine-Readable Quotation

The supplier should return more than a price.

A complete quotation response should include:

quotation identifier,
RFQ reference,
offered product,
quantity,
unit price,
total value,
currency,
delivery date,
lead time,
transport cost,
taxes,
Incoterms,
payment terms,
quotation validity,
technical deviations,
substitute information,
required documents,
assumptions and exclusions.

UBL and similar business-document standards already support the relationship between an RFQ and the resulting quotation, including document references and associated commercial information.

A useful response should also distinguish between:

confirmed data,
calculated data,
estimated data,
conditions requiring human approval.

This prevents an agent-generated estimate from being mistaken for a binding commercial commitment.

Step 9: Compare Offers Using More Than Price

Direct RFQ becomes especially valuable when several approved suppliers receive private requests.

The buyer’s agent can normalize the responses and evaluate:

unit price,
total cost,
delivery date,
freight,
payment terms,
quality,
risk,
compliance,
service,
sustainability,
reliability.

The comparison may use a weighted utility model:

[
Supplier Score =
Price Weight

Delivery Weight
Quality Weight
Risk Weight
Compliance Weight
Service Weight
]

Agentic sourcing platforms are already moving beyond simple workflow automation. Current systems can structure sourcing events, collect comparable bids, recommend suppliers and escalate decisions that fall outside defined parameters.

Today

Automation primarily helps the buyer create an event and compare submitted bids.

Tomorrow

The buyer agent will continuously adapt the evaluation to the context of the requirement.

For an emergency spare part, delivery may outweigh price.

For a regulated material, documentation may outweigh both.

Step 10: Negotiate Within Guardrails

Not every Direct RFQ needs negotiation.

For standard purchases, the buyer may simply accept or reject the offer.

For more complex transactions, agents may negotiate selected variables:

price,
quantity,
delivery date,
contract duration,
payment terms,
freight,
minimum order quantity,
rebate,
packaging,
service level.

The negotiation must be bounded.

The buyer may authorize:

a maximum price,
a preferred delivery window,
a maximum number of rounds,
acceptable substitute categories,
permitted concessions.

The supplier may authorize:

a minimum margin,
a maximum discount,
an acceptable payment range,
available delivery slots,
permitted volume commitments.

Autonomous negotiation platforms already support policy-guided negotiations that can operate independently or return agreements for buyer approval.

Today

Autonomous negotiation is most suitable for repetitive, clearly bounded commercial terms.

Tomorrow

Negotiation will become multi-variable and event-driven, but strategic, high-risk and technically complex contracts will still require human judgment.

Step 11: Apply Human Approval Where Necessary

Direct RFQ should not mean uncontrolled purchasing.

The preferred model is:

Zero-touch for routine transactions, human control for exceptions.

Automatic approval may be appropriate when:

the product is approved,
the supplier is approved,
the quantity is normal,
the value is below the threshold,
the margin is protected,
no technical deviation exists,
all compliance documents are valid.

Human review should be triggered when:

the transaction value is unusually high,
a new supplier is involved,
a substitute has been proposed,
the requested specification is unclear,
required documents are missing,
the price falls outside an expected range,
credit limits are exceeded,
the transaction affects safety or regulatory compliance,
the purchase requires a new contract.

Current procurement platforms increasingly combine agentic execution with defined human oversight rather than attempting to eliminate people from every decision.

Step 12: Convert the Accepted Quote into an Order

Once the quotation is accepted, the transaction should not return to manual data entry.

The accepted quote can be transformed into:

a purchase order in the buyer’s ERP,
a sales order in the supplier’s ERP,
an inventory reservation,
a production order,
a transport request,
a delivery schedule,
a contract reference.

The systems should preserve the relationship between:

purchasing intent,
RFQ,
quotation,
negotiation history,
approval,
purchase order,
sales order,
delivery,
invoice.

This provides the audit trail required to understand not only what was purchased, but how and why the transaction was authorized.

Part Two: How to Implement Direct RFQ Today

A company does not need fully autonomous AI agents to begin.

The practical implementation should follow a controlled sequence.

Stage 1: Standardize the RFQ

Define:

mandatory fields,
optional fields,
category-specific fields,
document requirements,
acceptable units,
identifiers,
validation rules.

Start with one repeatable product category.

Good initial categories include:

packaging materials,
standard industrial components,
MRO products,
spare parts,
transport services,
consumables,
repeat production orders.

Avoid starting with highly customized, high-risk or poorly documented purchases.

Stage 2: Create a Single RFQ Intake Layer

The company should be able to receive requests from:

forms,
email,
spreadsheets,
PDFs,
procurement platforms,
APIs,
AI agents.

All requests should be transformed into one internal RFQ model.

This creates an important transitional capability:

human-readable input on the outside, structured data on the inside.

Stage 3: Connect Product and Commercial Data

The RFQ process should connect to:

product identifiers,
technical attributes,
customer records,
pricing rules,
inventory,
production capacity,
logistics,
documentation.

This is part of Agent-Ready Offer Optimization: preparing the product and commercial offer so that machines can understand, compare, verify and execute it.

An agent-ready offer should include:

consistent identifiers,
structured attributes,
pricing logic,
quantity breaks,
lead times,
compatibility data,
substitute relationships,
compliance evidence,
warranty and service conditions,
RFQ requirements,
machine-accessible actions.

Stage 4: Automate Validation

Introduce deterministic checks for:

completeness,
product recognition,
commercial policy,
technical feasibility,
customer authorization,
document availability.

Stage 5: Automate Quote Preparation

Allow the system to prepare draft quotations for standard cases.

A salesperson may initially approve every quotation.

As performance improves, automatic issuance can be allowed for transactions that meet defined criteria.

Stage 6: Expose Secure Tools

Make selected functions available through secure APIs or MCP-compatible interfaces:

check availability,
retrieve technical data,
calculate freight,
create a quotation,
retrieve documentation,
check order status.

A public unrestricted ERP endpoint is not required and would usually be inappropriate. The company should expose only carefully controlled business capabilities.

Stage 7: Add Agent-to-Agent Communication

After the internal data and rules are reliable, the company can introduce A2A communication.

The supplier agent should clearly declare:

its identity,
supported product categories,
accepted RFQ formats,
available actions,
security requirements,
escalation process.

Stage 8: Introduce Bounded Autonomy

Allow agents to execute only transactions that remain inside approved limits.

Increase autonomy gradually based on observed performance, not on technical possibility alone.

Part Three: Direct RFQ Tomorrow

The following development path is an inference based on the current direction of RFQ standards, A2A, MCP, data spaces and agentic procurement platforms.

1. RFQ Will Become Event-Driven

Requests will increasingly be triggered by operational events rather than manually created documents.

An ERP may detect a shortage.

A maintenance system may predict failure.

A transport system may identify a delayed shipment.

An agent will translate the event into a sourcing objective.

2. RFQ Will Become Continuous

A quotation will no longer always be a one-time static document.

Agents may re-evaluate:

current price,
raw-material indexes,
delivery capacity,
freight availability,
supplier risk,
exchange rates,
substitute availability.

This will create continuous RFQ and continuous renegotiation models.

3. Supplier Capacity Will Become Quotable

Companies will not only request products.

They will request:

machine hours,
production capacity,
warehouse space,
transport slots,
service availability,
manufacturing processes.

A supplier agent may also proactively offer unused capacity to trusted buyers.

4. Compliance Will Become Part of the Transaction

A future Direct RFQ will not ask only:

Can you supply this product?

It will ask:

Can you supply this product with the required evidence for this market, application and delivery date?

Certificates, declarations, test reports and product-passport data will become machine-verifiable elements of the offer.

5. Agent Identity Will Become a Commercial Requirement

Companies will need to verify:

which organization an agent represents,
what authority it has,
what information it may access,
what value it may commit,
how its actions can be audited.

An agent requesting a public catalogue price may require little authority.

An agent negotiating contract pricing or submitting a binding order will require a verifiable mandate.

6. RFQ Schemas Will Become Industry-Specific

A universal RFQ core may define common commercial fields.

Industry extensions will define specialist requirements.

Examples include:

chemical RFQ with CAS, grade and SDS requirements,
packaging RFQ with dimensions, material and recycled content,
manufacturing RFQ with CAD, tolerances and processes,
logistics RFQ with route, weight, volume and equipment,
machine RFQ with throughput, integration and safety requirements.

7. The Website Will No Longer Be the Only Sales Interface

Human buyers will continue to use websites.

Agents may interact through:

feeds,
APIs,
MCP tools,
A2A endpoints,
capability registries,
compliance-data services.

The future supplier will therefore need two interfaces:

a persuasive, understandable interface for people,
a structured, executable interface for machines.

8. The Main KPI Will Change

The most important metric will not be:

response time alone,
website visits,
number of quotations generated.

It will be:

Time-to-Valid-Quote

This is the time required to produce an offer that is:

complete,
technically feasible,
commercially approved,
document-supported,
deliverable,
auditable,
ready for acceptance.

A fast but incorrect quotation has little value.

Direct RFQ Maturity Model

Level 0: Email RFQ

The request is sent through email or PDF and processed manually.

Level 1: Structured Digital RFQ

A form or portal collects standardized data.

Level 2: API-Connected RFQ

Buyer and supplier systems exchange structured requests and quotations.

Level 3: Agent-Assisted RFQ

Agents extract information, validate the request and prepare the quotation.

Level 4: Bounded Autonomous RFQ

Agents submit, evaluate and negotiate RFQs within defined policies.

Level 5: Closed-Loop Agentic Commerce

The process from purchasing intent to order, delivery and settlement is machine-orchestrated, with humans managing exceptions and strategy.

Most companies should not attempt to move directly from Level 0 to Level 5.

The sustainable path is:

Structure first. Integrate second. Automate third. Add agents fourth.

Final Checklist

A company is ready to begin Direct RFQ when it can answer yes to most of the following questions:

Are products and services uniquely identified?
Are quotation requirements clearly defined?
Are technical attributes structured?
Are units and terminology standardized?
Are pricing rules documented?
Can availability and lead time be checked reliably?
Are customer-specific conditions accessible?
Are compliance documents linked to the correct products?
Are approval limits defined?
Can unusual transactions be stopped automatically?
Can every quotation be traced to its source data?
Can a human take control when required?

If the answer is no, the company is not primarily facing an AI problem.

It is facing a data, process and governance problem.

Conclusion

Direct RFQ today is a structured and integrated method of exchanging private quotation requests between trusted business partners.

Direct RFQ tomorrow becomes a transaction primitive of Agentic Commerce.

The future process may look like this:

Intent → Specification → Validation → Trust → Direct RFQ → Quote → Negotiation → Approval → Order → Fulfilment

A procurement agent detects the need.

An RFQ compiler creates a complete specification.

A2A connects the buyer’s agent with the supplier’s agent.

MCP gives the agents controlled access to business tools and data.

A deterministic pricing engine creates the commercial offer.

Guardrails protect margin, authority, compliance and risk.

Humans intervene when the transaction falls outside normal conditions.

Direct RFQ is not about removing relationships from B2B commerce.

It is about removing the delays, duplicated work and information gaps surrounding those relationships.

The competitive advantage will not belong to the company with the most impressive chatbot.

It will belong to the company whose products, capabilities, prices, documents and commercial rules are ready to be understood—and safely used—by both people and machines.

kontakt@salesbot.pl