From Request to Quote: Building an Agentic RFQ System with Solace Agent Mesh

This post is based on a system that was built and demonstrated in a recent episode of Solace Office Hours.

“Can I get a quote for this?”

Seems like such a simple question…a buyer specifies what they need, and a supplier or seller responds with availability, pricing, and a delivery window.

But generating that quote requires getting product details, checking stock levels in an ERP, calculating lead times, and pricing out shipping and other logistics costs. Each of these steps requires checking a different system (some internal, some external), with its own data contract, turnaround times and failure scenarios.

The traditional way to resolve this problem is sequential: a sales rep or some automation workflow can route a form, check multiple systems, send email requests and wait for vendor responses, assemble the results and send out a quote which may be stale by the time it is read.

On top of the process delays are situations like vendors replying with partial quotes, ambiguity in specs, unavailable supplier and missed deadlines. Many times, procurement or sales teams end up doing the coordination work manually, defeating the purpose of automation entirely.

Why Traditional Automation isn’t Enough

The first choice when automating an RFQ process is to choose familiar tools: a workflow engine to sequence the steps, API integrations to connect the systems. These approaches work well in bounded and predictable processes. Unfortunately, an RFQ process is neither of those.

Workflow Engines Create a Sequence that is not Needed

A typical RFQ process has the following steps :

• Check the Product Information Management (PIM) system and wait for the request to complete
• Check the inventory and pricing, waits again
• Then query shipping and wait again.

The three lookups are independent, but their execution is serial. On a slow ERP day, that step could drag on.

Data Living in too Many Places

Most large enterprises are inherently multi-system. And each system has its own “master” data. In an RFQ process, the initial requirement might come from an ERP, vendor communications happen over emails or portals, pricing rules are governed by personal relationships and spreadsheets, approval history lives in a ticketing system and finally compliance checks reference a separate vendor management database.

Error Handling Evolving into a special Case

Most workflow-based automations assume the happy path. When an API call fails, the ERP times out or, takes too long, retries or failures are the only mitigation options. Partial results, cached fallbacks etc. require conditional branching that makes the workflow definition unmaintainable in the long run.

Extending the Process Requires Modifying It

If a regulatory compliance check or a supplier credit scoring service needs to be added to the quote flow, a traditional integration script has to be extended and re-tested as a whole. There’s no mechanism for adding a new participant without touching the existing one.

Why RFQ Is a Strong Candidate for an Agentic Solution

Not every business process or automation workflow benefit from an agentic solution. The overhead of LLM inference, the non-determinism of agent reasoning, need for a high error threshold and the complexity of multi-agent coordination all carry real costs.

Before committing to an agentic solution, always ask this question: does this process really need AI and agents or is it a workflow problem dressed up as an AI problem.

The RFQ process has several characteristics that align clearly with how agentic solutions work:

Multi-Step Reasoning Across Ambiguous Inputs

An RFQ is not a single transaction. It is a sequence of dependent decisions, each of which may require interpreting context from previous steps. Parsing an incoming requirement, assessing vendor fit, handling partial or non-conforming responses, normalizing heterogeneous quote formats, and producing a ranked recommendation all require reasoning, not just routing.

The inputs are also structurally ambiguous. A buyer might submit a requirement in natural language. A vendor might reply by email with a PDF attachment that does not match the original or expected format. An approval stakeholder might ask a clarifying question mid-process. These are some edge cases that simply cannot be pre-coded for; they are the nature of the process itself.

Parallel and independent sub-tasks

A complete quote requires product information, live inventory availability, and shipping costs. Product catalog and inventory lookups are independent of each other and can run in parallel. Shipping rate calculation depends on both – product dimensions from the catalog and origin warehouse from the inventory check.
The result is a two-phase execution: independent tasks run concurrently, and the shipping lookup follows when both are complete. This is a significant latency improvement over running all the three sequentially.

Approvals from a human in the loop

Agentic pipelines can pause at defined checkpoints for a human to review and confirm before continuing. For high-value quotes, this is a feature rather than a workaround, and the pipeline handles it without needing a special execution mode.

The table below shows a high level comparison of agentic and traditional alternatives :

The Agentic AI-Powered RFQ

The designed solution runs on Solace Agent Mesh, which provides both the agent framework and the event-driven messaging fabric.
Agents communicate with each other via the Solace Event Broker which means they are decoupled by design. An agent publishes to an event topic; the broker routes it; the receiving agent processes it asynchronously.

The agent topology uses two levels of orchestration which is a very conscious choice.

A single flat orchestrator with knowledge of product lookup, ERP queries, and shipping calculations would become a maintenance problem fast. The domain-specific logic would accumulate in one place.

By separating a dedicated RFQ sub-orchestrator, there is a clean boundary: the main orchestrator handles routing across business domains, and the RFQ sub-orchestrator owns the quote-assembly logic specifically.

Agent roles

Orchestrator

The main orchestrator is the system’s entry point. It receives incoming requests from the web UI or any other integration surface including events, identifies the appropriate downstream handler, and returns the final assembled response.
For RFQ requests, it delegates immediately to the RFQ sub-orchestrator. The main orchestrator doesn’t change when the RFQ workflow evolves.
This separation pays off in a multi-domain deployment. If the same Agent Mesh handles order management, inventory alerts, and RFQ workflows, the main orchestrator routes each to the right sub-orchestrator and without any of them knowing about each other.

RFQ Sub-Orchestrator

The RFQ sub-orchestrator owns the quote-assembly workflow. It receives the structured request from the main orchestrator, fans out to the specialist agents in parallel where applicable, collects their responses, and consolidates a complete quote to return upstream.
Business rules that span multiple data sources belong here: input validations, minimum order quantity checks, escalation flows amongst others.

 Product Information Management Agent

The PIM agent is a RAG-based agent that queries the Product Information Management (PIM) system. Given a product identifier or a natural-language description from the RFQ, it retrieves product specifications, upsell and cross selling opportunities, product dimensions. The agent handles embedding-based retrieval from the product catalog index and returns a structured response to the sub-orchestrator.

SAP Joule Agent

The SAP Joule agent is the most integration-intensive component in the system. Solace Agent Mesh connects to an SAP Joule agent via the A2A protocol, which in turn accesses SAP S/4HANA (or other SAP systems) for real operational data: Available-to-Promise (ATP) quantities, current stocking levels, warehouse location, and confirmed lead times.
The SAP Joule agent translates the sub-orchestrator’s request into an SAP Joule agent query, parses the structured response, and surfaces the fields the RFQ workflow needs.

Shipping Agent

The shipping agent connects to a shipping integrator, a service that aggregates rates and delivery windows across multiple carriers. Given an origin warehouse, a destination, a weight or volume estimate, and a required delivery date, it returns a list of carrier options.

It runs after the PIM and SAP Joule agents complete, because it depends on both: product weight and dimensions come from the PIM response, and the origin warehouse comes from the SAP Joule response. The sub-orchestrator assembles these inputs and dispatches them to the shipping agent as a single request once Phase 1 is done.
Shipping APIs are often the most variable in terms of response time, so the total quote latency is bounded by the slower of Phase 1 (PIM and SAP Joule in parallel) plus the shipping lookup.

How Agent Mesh connects it all

Individual agents are only as useful as the infrastructure that connects them. Solace Agent Mesh provides the event-driven backbone that makes multi-agent coordination reliable, observable, and scalable.

Agent discovery and routing

Agents in the mesh publish their capabilities as standard A2A cards. When inventory data is required, the sub-orchestrator identifies the SAP Joule agent based on its A2A Agent Card and  publishes a request to the SAP Joule agent which acts on it and sends a response back. Solace Agent Mesh allows all of the agents to be scaled, restarted, or swapped without reconfiguring the rest of the system.

Async-first by design

RFQ timelines are measured in hours and sometimes days, not milliseconds. Solace Agent Mesh is built for durable, asynchronous message delivery. An agent can publish a request and resume other work while waiting for a response. If the ERP is slow, the message waits in the queue rather than blocking a thread. This gives Solace Agent Mesh fault tolerance – if an agent crashes mid-process, the message is not lost and the agent will periodically retry.

Auditability

Every agent interaction is an event on the mesh. This means the full decision trail, which agent made which decision, when, and based on what input, is captured as a sequence of messages. Replaying the event stream for a specific RFQ gives you a complete audit log without any additional instrumentation.

Extensibility without disruption

Adding a new process, for example: an export and sanctions check agent on AWS Bedrock, means simply deploying a new agent and registering it with the Orchestrator.
No existing agent needs to be modified or redeployed. This is the practical realization of what the earlier section described as the limitation of traditional integration: in a mesh, you extend the process by adding participants, not by modifying the existing flow.

Key Takeaways

• RFQ is a structurally complex process, not a simple workflow. The multi-system, multi-party, exception-heavy nature of quote generation makes it a poor fit for rule-based automation and a strong fit for an agentic solution.
• Not every process needs agents. Before reaching for an agentic solution, validate that the process genuinely requires multi-step reasoning, handles ambiguous inputs, or has frequent unpredictable exceptions. RFQ passes this test on all three counts.
• Two-level orchestration keeps concerns separated. A main orchestrator handles cross-domain routing; the RFQ sub-orchestrator owns quote-assembly logic. Each agent can evolve independently, and this boundary is what makes the system maintainable at scale.
• Structured fan-out reduces latency without sacrificing accuracy.The total quote time is bounded by the slowest individual lookup, not the sum of all lookups in sequence.
• Human approval is a mandatory requirement. Agentic pipelines pause and resume cleanly at approval checkpoints. For high-value procurement decisions, this is a governance requirement, not a limitation to work around.

Appendix and Resources

• Solace Agent Mesh: https://solace.com/products/agent-mesh/
• Introduction to SAP Business Agent Foundation: https://community.sap.com/t5/technology-blog-posts-by-sap/ai-business-agents-and-the-evolution-of-business-automation-join-the/ba-p/13614232
• Solace Office Hours Episode: Solace Office Hours – “Jan” 2026 – Agent Mesh + SAP Joule

Next Steps

• Star the Solace Agent Mesh GitHub Repository
• Try out the open-source Solace Agent Mesh: Open-source Solace Agent Mesh
• Contact us to schedule a demo: Schedule a Solace Agent Mesh Demo
• Ask to run a Solace Agent Mesh pilot: Run a pilot