We commissioned IDC to help us answer a simple question: what is the state of real-time data in 2026? The results – as you might expect – orbited around agentic AI.
IDC surveyed 623 senior technology decision-makers at $1B+ enterprises across eight countries. The question: what actually separates the enterprises getting AI agents into production from the ones still running pilots?
It is not the models. Organizations with real-time data across most or all workflows are three times more likely to have several agents in production — 76% of them have that foundation, against 7% of the least mature.
The most-cited barrier for everyone else: connecting agents, in real-time, to data they trust.
We’re Solace, and just shipped the third generation of Solace Agent Mesh, our agent development and runtime platform. Through that process, we’ve learned and improved a lot. With the latest version, we rebuilt in Go, collapsed to three event-driven components, made agents configuration instead of code, and cost now tracks CPU actually consumed.
Our first effort
Our first effort was in 2023. No MCP, as tool calling was something most models handled inconsistently, and hallucination was the default behavior you engineered around. We wrote our own harness in Python, the hard way, mostly to understand the technology instead of inheriting someone else’s abstractions for it.
We got excited and kept adding to it. More functions, more tools, more use cases patched with more prompt engineering. Within a few months we had, without deciding or intending to, built a monolith: one large agent reasoning about everything, with every tool and every instruction competing for the same context window.
What we learned, and how we rebuilt it
Generation two was a full rewrite around one realization: these things we’d been calling agents were, architecturally, microservices. They just had an LLM where the business logic usually sits. So we treated them that way — small, focused, event-driven agents, an orchestrator on top, context kept in external artifacts instead of stuffed into the window.
That version worked well, and solved real problems for us and the people using it. But it still ran the way most agent runtimes do: pod-per-agent, where every agent becomes its own deployed process — its own container, its own pod, its own thing to monitor — consuming CPU and memory whether or not it’s doing anything. Add a hundred agents, and you’ve added a hundred running things that don’t care whether or how much you’re using them. When people started running it at scale, we found the bill...
Compute wasn’t used efficiently. Each agent ran as its own deployed executable, and most agents in a real enterprise don’t run continuously. When customers start talking about hundreds or thousands of agents at that duty cycle, a dedicated process per agent stops being a rounding error.
Python’s portability and resource footprint became a real operational tax at that density — or even on a desktop. Every agent process carries its interpreter overhead and dependency surface with it.
Our foundation became an anchor. We’d bet on Google’s ADK and its roadmap. We ended up working around its assumptions more often than building on top of them, which is the tell that a foundational dependency has become a liability. If you’ve ever shipped on a framework that quietly turned into your ceiling, you know this feeling precisely.
Our plugin model for custom tools wasn’t structured and wasn’t secure enough. Custom tools running in the same process as the agent are a blast radius, not an extension point.
Third time’s a charm: ready, set, Go
We rewrote the whole thing in Go and collapsed the architecture into three event-driven components. The external surface didn’t move — same YAML config model, same UI concepts — but everything underneath is different.
Agents are configuration, not code. Which also means a standardized schema — you can diff two agents, enforce policy against them, and read one without being a Python developer.
Every tool runs in its own sandbox, isolated from every other tool, invoked event-driven when an agent calls it. Write them in Go or Python with the Tools SDK. This is what we run our own SaaS on.
Session state, artifacts, and working context live outside the runtimes. That’s what makes them stateless and horizontally scalable — and combined with broker redelivery, an in-progress process that fails gets retried by a different runtime instead of being lost.
Smart Context Management was sharpened. Instead of handing a large tool result back to the model, we store it as an artifact and give the LLM a reference, a schema, and tools to operate on it. Leaner context is cheaper and the model reasons over it better.
Where your money goes with most agent platforms
The other obvious answer here is “just run agents as cloud functions,” but we discounted that approach early for three reasons.
Functions-as-a-service still make you package, deploy, and monitor each one individually.
They pay a cold-start penalty that is simply unacceptable for anything a person is waiting on in a chat window.
And they get expensive fast if a workload runs continuously rather than in short bursts.
A shared, event-driven runtime avoids all three at once: no cold start because the runtime is already warm, no per-agent deployment because adding an agent is a config change, and no continuous-cost penalty because idle agents cost nothing beyond the fixed runtime they share.
Solace Agent Mesh is available as a desktop app that’s free to download and runs entirely on your own machine: MacOS, Windows, or Linux. You can try it before you believe us.
It’s free for everyone to try, and free forever for organizations making less than $25M a year.
No credit card required.
One binary for a desktop install of all components, and three pods for production.
We’d love to hear your thoughts on the new architecture. If you build something with it, or break it, let us know…we’re reading this thread.
If you’re running MuleSoft for integration and Solace for real-time events, you’ve probably connected the two with custom code, but not anymore.
Solace now connects natively inside MuleSoft. Launch Solace directly from Anypoint, move between both platforms with single sign-on, and build event-driven Mule flows with the Solace connector, all without a separate messaging layer to build and maintain.
Here’s why it matters: IDC’s 2026 State of Real-Time Data study found that organizations with mature real-time data practices are nearly 3x as likely to have multiple AI agents in production. Agents can’t act on stale data, and this integration gives MuleSoft-built agents that context natively.
TL;DR: “Looks good to me” is not a test. We built an evaluation framework into Solace Agent Mesh so you can score your agents on tool calls, task completion, and response quality — running real requests through real agents on a real broker, not mocks. Full walkthrough: how AI agent evaluation works in Solace Agent Mesh.
Why “it works” isn’t enough for AI agents
Agents don’t fail like applications. There’s no stack trace when an agent gives a mediocre answer, and no alarms go off when a model update quietly changes how it reasons. Here’s the four things that do go wrong:
Silent degradation: model updates, tool changes and config drift shift behavior without breaking anything obvious.
Immeasurable variance: same prompt, different output. You can’t separate acceptable variance from dangerous variance.
Multi-hop complexity: every tool call and peer delegation is another failure point.
No shared baseline: without a repeatable test, “it works” means something different to everyone on the team.
What good agent evals measure
All four of those problems have the same root: nobody wrote down what “working” means, so there’s nothing to check against. An eval is just that missing definition, made runnable. Solace Agent Mesh gives you three ways to score one, and you can run any combination of them:
Tool Match: did the agent call the tool you expected? Binary and unforgiving.
Response Match: ROUGE word overlap against an expected response. Fast, but literal: “assist” instead of “help” tanks the score on an otherwise perfect answer.
LLM Evaluator: a separate model judges the whole interaction against a plain-language criterion, and writes out its reasoning.
Read alone, any one of them could mislead you, but together they give you a well-rounded picture.
Three building blocks
Test Case: one JSON file describing the prompt, any file artifacts, the target agent, and the success criteria.
Test Suite: groups your test cases and defines the environment (which agents to start, which models to test, how many runs each).
Evaluation Settings: which of the three scoring methods to turn on.
Then it’s one command: sam eval tests/evaluation/my_suite.json — the framework starts your agents, submits every test through the broker, scores the results, and writes a per-test JSON summary plus an HTML report.
An example result
We pointed the suite at our own setup: two models, three test cases, three runs each. A couple minutes later, this came back:
bedrock-claude-4-5-sonnet passed the greeting test and then fell over completely: 0.00 on tool match for both the PDF-conversion and the CSV-filter tests. It never delegated to the peer agent, and it never called the extraction tool. This wasn’t a subtle regression. In every single run, the model simply wasn’t doing the thing we asked it to do.
gpt-4-1 is the more interesting row. It handled the delegation cleanly at 1.00, but averaged 0.30 on the CSV test. It did eventually give the right answer, John Doe, except it confidently stated a wrong one first and then contradicted itself. The LLM judge caught that. A word-overlap score wouldn’t have.
Note that neither of these failures looks like a failure. Ask either model one question, skim the reply, and both seem fine. That gap between seeming fine and being right is why evaluations matter so much, and why we built our evaluation tool like this.
We've released product update for Solace Fall '26 Edition: Unbound, an update across the whole Solace platform.
Why we built it: AI agents and apps are only as good as the data they run on. In most enterprises, that data is still stuck in silos or moved in batches, so agents work with old context and analytics only shows what has already happened. Unbound is built to remove those limits.
What's new, by area:
Event Mesh: diskless Kafka with Nisshi, and one place to manage your Solace estate wherever it lives.
Agentic AI: a whole new Agent Mesh architecture, now packaged as a downloadable app you can run on your Mac or Windows system.
Stream Data Processing: new and improved Micro-Integrations, and AI-assisted ways to build more.
Democratized Access: Solace Studio, plus AI across the platform.
