Building an Agentic RFQ System with Solace Agent Mesh

Building an Agentic RFQ System with Solace Agent Mesh

I’ve just published a blog post walking through how to build an agentic RFQ (Request for Quote) system using Solace Agent Mesh, and wanted to share it here along with some context on why I found this problem worth writing about.

Read the full post →


Why RFQ?

RFQ processes look simple on the surface :

  • someone asks for a quote
  • you pull some data
  • you respond.

In practice they span multiple systems (ERP, product catalog, shipping aggregators, vendor portals), involve parallel lookups with interdependencies, and frequently require human approval at checkpoints. That combination makes them a genuinely interesting candidate for an agentic approach and not just a workflow problem dressed up with AI.

The blog actually starts by asking whether agents are even the right tool here. There’s a tendency to reach for agentic solutions before checking whether a simpler workflow would do the job. RFQ passes that test, mainly because of three things: the inputs are ambiguous (natural language requests, PDF vendor replies), the sub-tasks are independently parallelisable, and human-in-the-loop approval is a real governance requirement, not an afterthought.


What the architecture looks like

The system uses a two-level orchestration model:

  • Main Orchestrator : receives requests (from a web UI or upstream events) and routes to the appropriate sub-orchestrator. Intentionally thin so it doesn’t need to change as the RFQ workflow evolves.

  • RFQ Sub-Orchestrator : owns the quote assembly logic. Fans out to specialist agents in parallel, collects responses, and consolidates the final quote.

  • PIM Agent : RAG-based retrieval against the product catalog for specs, dimensions, and pricing.

  • SAP Joule Agent : connects to SAP S/4HANA for stock levels, ATP quantities, warehouse origin, and confirmed lead times.

  • Shipping Agent : runs after PIM and SAP Joule complete, since it needs product dimensions and warehouse location to calculate shipping options and cost.

The structured fan-out matters here: PIM and SAP lookups run in parallel, so total latency is the slowest of the two, not the sum. The shipping agent then runs as a second phase. That’s a meaningful difference at scale compared to a sequential workflow.


Where Solace Agent Mesh fits in

A few things about the architecture are worth calling out:

Async-first by design : agents publish and move on rather than blocking on a response. If the ERP is slow, messages queue durably rather than timing out a thread. This also means agents can crash and restart without losing in-flight work.

Agent discovery via A2A capability cards : agents register what they can do, and the sub-orchestrator routes accordingly. Swapping or scaling an agent doesn’t require reconfiguring anything else.

Auditability as a side effect : because every agent interaction is an event on the broker, you get a full decision trail as a message sequence without any additional instrumentation.

Extensibility without disruption : the post walks through adding a hypothetical export/sanctions check agent running on AWS Bedrock. It deploys, registers, and starts participating. No existing agents are modified or redeployed.


A few things I’d highlight for architects

The two-level orchestration pattern (main orchestrator + domain sub-orchestrator) is something I’d recommend thinking about carefully for any agentic system of moderate complexity. Keeping the entry point stable while letting the domain orchestrator evolve independently makes a real difference when requirements change.

Also worth reading if you’re evaluating agentic approaches: the comparison table in the post looks at manual coordination, BPM/workflow engines, and custom ETL integrations side-by-side with agentic. Parallelism, error handling, and extensibility all look quite different depending on where you land.


This came out of a Solace Office Hours session so if you prefer video there’s a walkthrough there too.

Happy to discuss the architecture or answer questions in the comments — particularly around the orchestration design and the SAP integration, which had a few interesting wrinkles.