Building the Intelligent Store with Solace Agent Mesh — Part 1: The Sudden Rush

The value of your data is bounded by how fast you can act on it.

Imagine (if you’re not..) that you are a large grocery and general-merchandise retailer with thousands of locations around the world. You have invested tens of millions of dollars building machine-learning models that predict sales from historical foot traffic, demographics, weather, promotions, and a dozen other signals you keep close to your chest as a competitive advantage.

You know the fundamental truth of your business: the sale happens when the product is in front of the customer at the moment they want to buy it. A pallet of chocolate-covered cherries in the backroom during a Mother’s Day rush is not inventory — it is a stack of lost sales, one customer at a time. Out of Stock events cost you money – and you know 25%[1] of them are preventable in the store.

So you’ve optimized. You’ve tuned your associate task flow. You’ve refined your replenishment models. You’ve moved from weekly to daily to hourly forecasts. You’ve invested in streaming to move data faster.

But moving data is only half the puzzle.

The other half is getting agents, models, and human associates to act on that data in real time, across disparate systems in the store – all before the customer walks out the door.

That is the problem this series is about — reducing the amount of time it takes to decide, and to act. Over the next three posts, I’ll walk you through real world in-store scenarios and show how Solace Agent Mesh enables you to connect sensors, models, external agents, and humans into a coordinated workflow that decides and acts on the timescale your customers actually shop on.

I’ll start with the scenario every store manager has lived through…

The Situation: A Sudden Rush of Demand

It’s 2:15 PM on a Tuesday. The elementary school three blocks up the street let out ninety minutes early — a half-day the district scheduled months ago but that never made it into any of your forecasting models. Two hundred parents and kids just walked through your doors at once.

They want the easy stuff. Pre-made rotisserie chickens. Bakery cookies. Deli mac and cheese. Fruit trays. The top-mover, one-hand-grab, kid-friendly SKUs that make an unplanned Tuesday dinner feasible.

Your nightly forecast predicted a normal Tuesday afternoon, and that’s what your shelves are stocked for. Twenty minutes from now, half of those top movers will be at zero on the floor — even though there’s plenty in the backroom.

The question isn’t whether you have the product. It’s whether anything in your store knows, right now, that it needs to be on the floor.

Let’s watch what happens when it does.

The Choreography

Planning and acting in real-time

Figure 1 — The Sudden Rush workflow. One Solace Agent Mesh Workflow choreographing A2A, MCP, Databricks ingestion with ZeroBus, Webhook, Teams, and REST endpoints integrations.

The Building Blocks

Every step in the diagram features one of these Agent Mesh capabilities.

• Predictive Restock Flow defines the sequence of steps executed by the Agent Mesh. Triggered by an event, it invokes agents in a defined order, waits for their responses, and dispatches the next step. Designed and deployed through the AI assisted Agent Mesh Workflow Builder, an interactive editor for choreographing agents into a repeatable pattern. No Orchestrating Agent is needed -> the sequence is known, the failure modes are known, and every run of this workflow behaves the same way.
• Event Mesh + Topics. With Solace Platform you can build an event mesh that serves as the pub/sub fabric carrying events between publishers and subscribers. Publishers write to a topic; anyone subscribed to that topic — a data-lake connector, a workflow, another agent — receives the event, ordered and once-only, without either side knowing the other exists.
• Event Mesh Gateway. How Solace Agent Mesh listens to your event mesh: A topic subscription becomes the trigger that launches a workflow run.
• A2A proxy. Agent-to-Agent invocation. The workflow calls another agent — one that may live in a different cloud, on a different team, or with a different vendor — as if it were local. The proxy handles the wire protocol; the caller just gets the response.
• MCP. Model Context Protocol. A standard, tool-shaped way for an agent to pull data or invoke actions on an external system. The workflow queries a database, an API, or a file store through the MCP surface an agent exposes.
• Solace Micro-Integrations. Solace’s bridge between your event mesh and external systems — databases, data lakes, other systems of record. Reads from a topic and pushes into a destination; conversely, publishes external changes into a topic. Two variants appear in this workflow: ZeroBus streams topic events into a data lake (step 2); the REST endpoint variant fires an HTTP call in response to a topic event (step 10).
• Teams. A first-class channel for talking with a human. Agent Mesh can notify a Teams user (or listen to one) as a normal step in a workflow.

Every step below uses one of these. The color of the numbered badge and the label prefix in the diagram identify which.

The Workflow

The workflow breaks into four beats: collecting and distributing the data, figuring out what’s needed, notifying employees and AI agents, and closing the loop.

Collect: Sensors publish, the mesh distributes

1. Event: Store sensors — door counters, IR presence detectors, and camera aggregators — publish presence and demographic signals to the Store Presence Topic on your event mesh. Camera frames never leave the store; only the inference (head counts, estimated age distribution, dwell time by zone) flows onto the mesh.
2. Datalake Ingest: An instance of Solace Micro-Integration for DataBricks ZeroBus already subscribes to the Store Presence Topic and streams every event into your Data Lake in Azure for long-term analytics. This part of the picture likely already exists in your enterprise — the sensors are wired, the lake is receiving, the dashboards are dashboarding. Nothing about your event mesh disturbs that, but now the same events can be acted upon in real time.
3. Event: The same topic feeds the Agent Mesh workflow through the Gateway. One event, two subscribers, and one of them is the trigger that launches PredictiveRestockFlow.

Plan: The Workflow queries what it needs

4. A2A: The workflow calls your Forecast Agents in GCP through an A2A proxy: “For these demographics, at this time of year, what are the top movers and how many units do you expect to sell in the next hour?” Under the hood, these are the models your data-science team already owns, running where they already run. In production this is usually not a single agent — it’s a Selection Agent that identifies candidate SKUs handing off to a Forecast Agent that predicts unit sales, each running behind its own orchestrator, pulling historical data from your warehouse and invoking multiple models to produce a composite result. We’ve collapsed them into one A2A call here for clarity.
5. MCP: In parallel, the workflow queries the Store Inventory system through MCP for the current floor and backroom balances on every SKU the Forecast Agents flagged. MCP is how the workflow reads inventory without a bespoke integration for every operation — the Store Inventory agent exposes its data as a tool the workflow can call.

With responses from both, the workflow now knows: 1) which SKUs are predicted to sell in the next hour, 2) how many units are on the floor, and 3) how many are in the back. It computes the shortfall for each SKU and identifies which exceptions are worth acting on.

Dispatch (steps 6–8): Notify humans and register work

6. <MS Teams: For any exception whose projected lost revenue exceeds a store-configurable threshold, the workflow posts a Teams message to the Store Leader. Situational awareness for the person running the shift, without them having to go looking. “Showroom shortfall identified for 5 products — dispatching Associates to restock from backroom.”
7. A2A. The workflow calls the Task Prioritization Agent via A2A to register the restocks as high-priority tasks. TPA sits between decision and execution; it knows the store’s existing task queue, ranks the new work against it, and decides what dispatches immediately vs. what waits.
8. Webhook: TPA fans the tasks out to associates by webhooking into your task-management platform, which pushes to their Associate Handheld devices. Five associates, five different SKUs, five parallel restocks — chosen to maximize recovered revenue across the store, not first-come-first-served.

Close the loop (steps 9–11): Reality catches up with the plan

9. Event: An associate pulls two cases of cookies from the backroom, walks them to the bakery shelf, and taps Restock Complete on their handheld. The handheld publishes that event to the Completed Tasks Topic on the mesh.
10. REST: A Solace micro-integration subscribed to the Completed Tasks Topic issues a REST call to your Store Inventory system — POST /store-inventory/balance-update — moving 24 units from backroom to floor. Solace triggered the REST call; the handheld didn’t need to know the endpoint URL, and the inventory API didn’t need to know the Agent Mesh exists.
11. Event (feedback). The same Completed Tasks event flows to a RestockCompletionFlow workflow — a small, single-purpose tool-calling workflow whose only job is to mark the workflow instance as closed. PredictiveRestockFlow has now completed one cycle, and the Agent Mesh is ready to execute the next when a new trigger arrives.

Not shown, because it’s the outcome rather than a step: customers reach the bakery aisle, the cookies are on the shelf, and they buy them.

Where the Agents Run, and Why it Doesn’t Matter

Look back at the ten participants and ask a natural follow-up: where does each of these things live? They live wherever it makes sense.

• Store sensors and associate handhelds live at the edge connecting to topics on a local (edge) or store-facing Solace broker. Latency-sensitive work belongs close to the sensors, and personally identifiable data must never leave the building.
• The Forecast Agents live in GCP, alongside the feature store and the training pipeline your data-science team already operates. The A2A proxy means the workflow can invoke them regardless of where the mesh’s other subscribers live.
• Store Inventory and the Data Lake live in Azure, collocated with your systems of record.
• The Predictive Restock Workflow runs next to the event brokers in Azure, dispatching work across all of the above without knowing which cloud any specific agent is in.
• Your event mesh spans from the store edge to the cloud, with brokers in GCP and Azure, routing data to agents and subscribers as needed no matter their location

None of this required any of these participants to know where the others live. Solace Platform — with dynamic message routing (DMR) stitching brokers together across edge, GCP, and Azure — presents one logical namespace. An event published anywhere is available everywhere its subscribers live, with guaranteed ordering and delivery. Compute goes where it makes the most sense — cost, latency, data gravity, regulatory boundary — and the mesh handles the wiring.

That is the practical meaning of event-driven. Not just “we use a broker.” Every workload gets to live where it should, and the coordination layer stops being a constraint on the architecture.

What just happened that couldn’t happen before

Figure 1 — The Sudden Rush workflow. One Solace Agent Mesh Workflow choreographing A2A, MCP, Databricks ingestion with ZeroBus, Webhook, Teams, and REST endpoints integrations.

Play back the sequence and notice the physics of it:

• The trigger (a sudden crowd) was detected by sensors already in the store — no new hardware.
• The models that predicted top movers and demand were models you already own — the Predictive Restock Workflow invoked them as external agents through A2A, without moving them or rewriting them.
• No human noticed the school let out early. The store noticed.
• The restocks happened before the shelves hit zero, not after — no lost sales, no customers walking out empty-handed.

Contrast this with how these decisions get made in a typical enterprise today:

The traditional approach isn’t wrong. It’s necessary for training, for accounting, for long-horizon planning. What it can’t do is close the loop inside the customer’s visit.

Calculating the Business Value at Enterprise Scale

One restock in one store on one Tuesday afternoon is a rounding error. That’s not the story.

The story is what the mesh does across a fleet — every hour, every day. Every one of your stores lives through micro-moments where a shelf is understocked relative to demand a real-time model could have predicted. A school lets out, a game ends, a storm breaks, a bus arrives, a competitor closes early, a viral trend hits a category. Historically those moments have been invisible to your systems until the receipts came in, if at all.

Meanwhile – you know that 21-43% of shoppers will go to another store to buy the item they want if it is out of stock, and that you lose nearly half of intended purchases when customers encounter Out-of-Stocks[2].

Here is one illustrative frame modeling full walkouts. Dial the assumptions to your own operations:

At the mid-point:

• 30 baskets × $49.06 × 4.75 Preventable Out-Of-Stock Events = ~$7,000/store/week in recovered revenue
• × 3000 stores × 52 weeks ≈ $1.09 Billion a year across the Enterprise

And it stacks. Real-time detection of missed sales (part 2, coming soon!), staffing for a coming rush before the lanes back up (part 3), demand shocks from social media, cross-department pulls, competitor closures — every recoverable moment is additive. The investment you’ve already made in ML models, in streaming, in edge compute, in point-of-sale telemetry, in your data lakehouse — all of it is currently underemployed, waiting on a coordination layer that can move information between them at the speed of your customers.

That is what Solace Agent Mesh is.

Next in this Series

This post walked one scenario end-to-end because the mechanics are easiest to see in a single story. In the next two posts we’ll widen the aperture:

• Part 2 — Why isn’t the candy selling? We roll up our sleeves in the Solace Agent Mesh Agent Builder and build a working solution to the reverse problem: real-time detection of missed sales — the 24-hour analytics loop, in seconds instead of a day. From blank canvas to deployed agents.
• Part 3 — The lanes aren’t staffed for the storm. Extending from stocking to staffing: when demographics, weather, and traffic combine to predict a rush at the front-end that HR systems can’t see, and agents surface it to labor management in time to act.

If you’re building for the intelligent store — whether from the model side, the platform side, or the store-operations side — the through-line is the same: The faster you can act on your data, the more value it has.  To increase sales in the modern store, “how fast” can mean “before the customer leaves.”

Solace Agent Mesh — and the agents that reason on top of it — are how you get there.

[1] Gruen, Corsten & Bharadwaj, Retail Out-of-Stocks: A Worldwide Examination, GMA, 2002

[2] Corsten & Gruen, Stock-Outs Cause Walkouts, Harvard Business Review, 2004

[3] Average Consumer Spend per in-Store visit, FMI | Food Industry Facts