What fifteen years of event-driven systems taught us about running AI agents inside banks, exchanges, airports and factories

05:41:07

At 05:41:07 on a winter morning, a message is published to a topic at a large hub airport. It is small, a few hundred bytes. It says that an inbound flight has been assigned a hold because a band of freezing fog has dropped visibility below minima. The message does not know who will read it. That is the whole point of it.

By 05:41:08 it has reached fourteen subscribers. The flight information displays. The stand-planning system, which now has a conflict on the horizon. The baggage reconciliation system. A crew-management system that has just acquired a duty-time problem. A ground handler's dispatch console. A catering scheduler. A passenger-notification engine. Some of these systems are twenty years old. Some were deployed last quarter. Not one of them was written with the others in mind. They subscribed to a topic, and the event found them.

This is how the best-run enterprises have worked for two decades. Exchanges, airports, banks, ports and factories moved from point-to-point integrations to events precisely so that adding a fifteenth subscriber would not require touching the other fourteen. We at Iesoft have spent most of our working lives inside that shift. The trading floors and control rooms we know best all run on the same quiet principle: publishers publish, subscribers subscribe, and the broker in between guarantees that nothing gets lost.

So here is the question that has been sitting with us for the last two years. What happens when some of those subscribers can reason?

Nobody warns you about the second agent

The first agent is a triumph. A team wires a model to a few tools and a little memory, usually in LangGraph, usually in an afternoon, and it works. It reads the disruption, it drafts a recovery plan, it answers questions in plain language. The demo goes well. The budget gets approved.

Nobody warns you about the second agent.

The second agent is built by a different team, in a different tool, because they had a different problem and did not want to wait. The third agent needs data from the first, so someone writes a small internal API on a Friday and the two agents start calling each other directly. By the sixth agent, three of them call the same customer system in three different ways. By the tenth, there is a spreadsheet somewhere listing which agent talks to which, and it is already wrong.

Then someone from risk or internal audit asks the only question that matters: "Which of these decided to rebook those forty passengers, who approved it, and can you show me?" And the room goes quiet, because the answer is spread across ten log files in ten formats, some of which have rotated.

This is not a failure of any team. It is the oldest problem in enterprise software, arriving in new clothes. Point-to-point calls between agents are point-to-point integrations between systems, and we already know how that story ends. It ends with brittleness, with nobody able to change anything, and with the one architect who understands the whole picture refusing to take holidays.

We solved this for data with events. The interesting news is that the same solution works for agents, and one of the companies whose broker sits at the heart of the world's exchanges and airports has built it.

We have seen this movie before

Before we describe what Solace Agent Mesh is, it is worth saying why we trust the idea underneath it.

Some years ago we built a file replication layer for one of the largest securities exchanges in the region. Files had to move between datacentres at several gigabits per second, and they had to arrive intact, because the business processes waiting on them did not have the luxury of a retry. We wrote the adapters in C, put a high-performance Solace broker between the datacentres, and structured the entire thing as publish and subscribe. It is live across critical departments today. The thing that made it work was not the C. It was the decoupling. New consumers could be added without anyone on the producing side knowing or caring.

We built ThingSphere, an IoT platform that holds more than a million devices connected and active at the same time over MQTT, on Solace PubSub+ and AWS. When you have a million publishers, the idea that a consumer might call a device directly is simply absurd. Everything is events. Digital twins, rules engines, command and control, alerts: all of it is built as subscribers on a broker.

We built a financial marketplace in the Gulf that has served more than three million customers and is integrated with more than twenty banks. We built a notifications platform that pushes SMS, email, WhatsApp and app notifications through a single API with audit trails and compliance filters, because in regulated markets the message that reaches a customer needs a paper trail as much as the payment does.

And alongside all of that, we built the kind of machine learning that people now file under "AI" as though it were new. A sentiment engine that reads product reviews at more than 95 percent accuracy. A robo-advisor for personal finance. An image pipeline, trained from scratch, that reads rapid antigen test strips and processed thousands of tests a day during the pandemic. Defect classifiers and anomaly detectors for visual quality control on production lines.

The lesson from all of it is dull and durable. The systems that held up under pressure were the ones where the producer did not know the consumer. That single property is what let those systems grow. Agents are simply the newest, hungriest and least predictable kind of consumer we have ever had to plug in.

What Agent Mesh actually is

Solace Agent Mesh takes the event broker that already carries an enterprise's real-time traffic and makes it the communication fabric for AI agents.

Each agent runs as its own independent process. When it starts, it publishes a small capability document, an AgentCard, to a well-known discovery topic. Every other agent and every gateway subscribes to that topic, so the mesh learns what is available without anyone maintaining a registry by hand. When an agent needs help, it does not call another agent's endpoint. It publishes a task using the open Agent-to-Agent protocol (A2A) over a governed topic hierarchy, and the specialist that can do the work picks it up. Tools and enterprise data are reached through the Model Context Protocol (MCP), the same open standard now supported across the major model providers and frameworks.

Humans and systems enter the mesh through gateways: a web interface, a REST API, Slack, webhooks, and, most importantly for our clients, the event mesh itself. That last one is the quiet revolution. It means an agent can be woken by the 05:41:07 message rather than by a person typing a question.

Because everything moves through the broker, agents inherit properties that in-process frameworks cannot give them. Guaranteed delivery. Backpressure when a downstream is slow. Replay of what actually happened. The ability to upgrade or replace one agent while the others keep running. And when an agent delegates work to another, the caller's permission scope travels with the task, so a chain of agents can never quietly exceed the authority of the person who started it.

The Enterprise edition, generally available since late 2025, adds what a bank or an airport will insist on before anything touches production: single sign-on with the usual identity providers, role-based access control with deny-all defaults, human-in-the-loop approvals, audit, and tracking of model token spend by agent, by model and by task. It runs as a self-managed container on your own infrastructure or on Solace's cloud, and it is free to evaluate, and free outright for organisations under 25 million dollars in annual revenue.

Two honest notes. Agent Mesh is standards-first: an agent you already built in LangGraph, or on a hyperscaler's agent runtime, or as plain code, can register as a peer without a rewrite. And the agentic layer is young. The event platform beneath it has served the most demanding institutions on earth for two decades; the agent layer arrived in the last two years, and its list of named production references is still short. We would rather you heard that from us than discovered it later.

Four floors, four stories

The best way to explain what changes is to walk through a building. Each of the four stories below is a composite, built from work we have done and problems we have been asked to solve. None of them describes a specific client.

The control centre, 05:42

Back to the airport. Among the fourteen subscribers to the hold message, there are now four that can think.

A crew-legality agent wakes the instant the event lands, checks the affected rotations against duty limits, and posts a proposal: two swaps, both legal, one of which frees a captain for an afternoon departure that would otherwise cancel. A stand agent notices the gate conflict eleven minutes before the old system would have flagged it and offers a re-plan that keeps the catering trucks where they are. A passenger-communications agent drafts three notifications in four languages, then stops and waits, because the wording of anything sent to passengers during a disruption requires a human's approval, and the mesh will not let it proceed without one. A disruption agent pulls all of this together and presents the duty manager with a single recovery plan and the reasons behind it.

We built an operations copilot along these lines as a proof of concept for an airport operator's control centre. The moment that landed with the operations team was not the reasoning. It was that when the duty manager asked a question, the copilot named a flight, and that aircraft lit up on a three-dimensional model of the airfield. The copilot was valuable because it was watching the same events the operational database was watching, not because it was clever.

When the post-incident review asks why those forty passengers were rebooked the way they were, nobody hunts through log files. Every proposal, every approval and every action was a message on a governed topic. You replay it.

The exchange, 09:14

A settlement break appears in a post-trade system fourteen minutes after the open. Yesterday this went into a queue that a human would reach by mid-morning.

Today the event wakes a reconciliation agent. It reaches through MCP into the three systems that hold the relevant records, assembles the context a human would have spent twenty minutes collecting, and identifies that the break comes from a counterparty reference that was truncated upstream. A surveillance agent, subscribed to the same trade stream for entirely different reasons, notices that the same counterparty appears in an unusual pattern across the last hour and raises a separate alert. A market-intelligence agent, a direct descendant of the sentiment engine we built years ago for product reviews, adds a line about what the news is saying about that counterparty this morning.

None of these agents were built together. The surveillance team and the operations team have never sat in the same meeting. They discovered each other on the mesh.

The operator on the desk sees a proposed correction, the surveillance context, and the market context, in one place, and approves the correction with one click. The agents acted under the operator's own scope the entire time, so nothing was touched that the operator could not have touched personally. When the regulator asks, months later, for the full sequence of events around that counterparty, the answer is a replay of a topic, not a reconstruction from memory.

The bank, 14:30

A payment is missed on a personal loan. In most banks this triggers nothing until a batch runs overnight, and the customer hears from a dialler three days later.

On the mesh, the missed-payment event wakes a risk agent that looks at the account's recent pattern, not just the missed instalment, and concludes this is a customer who has paid on time for four years and whose salary credit is late this month, not a customer who is disengaging. It proposes a gentle reminder rather than a collections escalation. An outreach agent composes the message, then hands it to the same notifications platform we built for regulated messaging, where compliance filters check the wording and the audit trail records what was sent, to whom, and why.

If the risk agent had instead proposed a hardship arrangement, it would have stopped and waited for a human, because arrangements that change the terms of a loan require one. The agent knows this not because someone wrote a rule inside it, but because the mesh's approval policy applies to any agent that tries.

We spent years building a robo-advisor and a personal-finance marketplace for millions of customers, and the thing we learned is that customers do not want cleverness. They want the bank to notice what is happening in their life at the moment it happens, and to respond like an institution that knows them. Events give agents the moment. The mesh gives the bank the control.

The plant, 22:00

A vibration signature changes on a conveyor drive at ten in the evening. There is nobody on the floor.

The event comes off a platform like ThingSphere, where a million devices publish continuously. A predictive-maintenance agent recognises the signature as an early bearing fault and estimates the remaining useful life. A parts agent reaches through MCP into the ERP and confirms the bearing is in stock at a depot two hours away. A scheduling agent proposes a maintenance window at the next planned changeover, when the line will be stopped anyway. A visual-inspection agent queues a request for the camera at that station to capture a sequence at the next pass, so a defect classifier, the same kind of model we have trained for production-line quality control, can confirm whether the wear is visible.

Then all four of them hold. No one is there to approve, and the mesh does not act on a production line without approval. The proposals sit on their topics. At 06:00 the shift supervisor sees a complete case: what was detected, what it likely means, what is in stock, when to fix it and what it will cost to wait. One approval, and the work order is created.

We are not describing a fantasy. An industrial equipment company has publicly announced it is building exactly this kind of conveyor-health intelligence on Agent Mesh. The pattern is the pattern.

The part where we tell you not to buy it

If you are building one application, one customer assistant, one internal copilot, one retrieval service, you should probably not put a broker in the middle of it. LangGraph with LangSmith will get you to production faster, with a far larger community, more integrations and a deeper hiring pool behind you. LangChain reports around ninety million downloads a month and use across roughly a third of the Fortune 500, and that gravity is real. Klarna has said publicly that its LangGraph-based assistant took on two-thirds of its customer-service chats. That is not a niche tool.

We know this because we build on that stack too. Our teams work across LangGraph, CrewAI, the Anthropic API and the Model Context Protocol, and we have written our own MCP servers for the domains we work in. When a client's problem is one clever agent, we say so and we build it in the tool that fits.

Agent Mesh earns its place when the problem is not one agent but an estate. Many agents, many teams, many frameworks. Agents that must wake on real-time events rather than on a human's prompt. Workloads where "the process died and took the task with it" is not an acceptable failure mode. Institutions where a regulator, an auditor or a safety board will one day ask for the replay. And organisations that already run Solace, or Kafka, and would rather build on the fabric they have than migrate to a platform they do not.

Even then, you do not have to choose. Build the brains in LangGraph. Connect and govern them with the mesh. Keep LangSmith as the microscope on what happens inside each agent while the broker governs what happens between them. The failure we see most often is not picking the wrong framework. It is picking a single-application tool for an enterprise-wide problem, and then spending a year quietly rebuilding delivery guarantees, discovery and audit by hand.

Start with your own events, not with a platform decision

You do not need to decide anything about platforms to find out whether this fits you. You need two to four weeks and a real slice of your own event traffic.

That is how we prefer to work. Pick one flow that matters: a disruption, a settlement break, a missed payment, a sensor fault. Put two or three agents on the mesh against your actual events, with a human approval in the loop where your policy requires one, and measure against an outcome you define before we start. If you run Kafka rather than Solace, that is fine; the mesh is built to bridge the Kafka you already have. If your company is under the free-tier threshold, the software costs nothing while you find out. If it does not earn its place, you will know quickly and cheaply. If it does, you will have a governed pattern you can extend one agent at a time, without a migration.

Your data science team keeps building in the tools it knows. We bring the broker, the mesh, the A2A and MCP plumbing, and fifteen years of opinions about what breaks in production.

05:41:07, again

The message still does not know who is listening. It never will, and that is still the point.

What has changed is that some of the listeners can now think, propose, and ask a human for permission. That is a smaller change than the hype suggests, and a much larger one than most enterprise AI programmes have delivered so far. It is the difference between an agent and an agent estate, and it is the work we do.

Talk to us about a two-to-four week Agent Mesh proof of concept on your own live events. We will bring the architecture and an honest read on whether event-driven is right for your problem, or whether you are better served staying in-process for now.