TL;DR Solace Insights can forward real-time broker metrics and alerts to your existing observability platforms like Dynatrace, New Relic, Prometheus/Grafana, Splunk, and more. This enables proactive monitoring, automated alerting, and unified observability across your entire event-driven architecture—all without leaving your preferred monitoring tools. This is a common need for organizations that maintain separate operations or security centers that already have their own visualization layers. Operations teams get the benefits of a purpose build EDA observability tool while retaining the flexibility to send some (or all) data to thier other services.

Key Benefits:

• Early warning detection – Catch slow subscribers, queue buildups, and resource constraints before they impact your business
• Unified dashboards – Monitor your event mesh alongside your applications in a single pane of glass
• Automated remediation – Trigger runbooks and auto-scaling based on broker metrics
• Historical analysis – Trend analysis and capacity planning with long-term metric retention
• Correlation – Link broker performance issues with application behavior

The Challenge: Visibility Gaps in Event-Driven Architectures

You’ve built an elegant event-driven architecture with Solace at the center. Events flow seamlessly from publishers to subscribers, topics route data intelligently, and queues provide guaranteed delivery. Everything works beautifully—until it doesn’t.

Common Scenarios We’ve Seen:

Scenario 1: The Slow Subscriber

“We discovered our Order Cancellation app was falling behind. By the time we noticed, there were 50,000 messages queued, and customers were waiting hours for order cancellation confirmations. The app team said, ‘Why didn’t anyone tell us sooner?'”

Scenario 2: The Resource Crunch

“Our broker’s spool usage hit 95% during a product launch. Messages started getting rejected, and we had no idea until customers complained. We needed to know when we crossed 80% so we could take action.”

Scenario 3: The Bridge Outage

“A network issue took down our VPN bridge between edge and cloud. The edge broker kept queueing messages for 3 hours before anyone noticed. We need automated alerts when bridges go down.”

The Root Problem

Many organizations already have observability platforms in place, and some use several depending on the team:

• DevOps teams use Datadog or Dynatrace for application monitoring
• Operations teams use Splunk for log aggregation and alerting
• Platform teams use Prometheus + Grafana for infrastructure metrics
• SRE teams use PagerDuty for incident management

But the event broker metrics live in a silo—accessible only through Broker Manager or CLI. Your monitoring tools don’t know about queue depths, consumer lag, or bridge health. More importantly, many broker metrics on other tools aren’t even instrumented to provide true end-to-end telemetry making EDA somewhat of a black box.

This creates a visibility gap. You’re flying blind until something breaks.

The Solution: Solace Insights Forwarding

Solace Insights is Solace’s unified approach to broker observability. It collects metrics, logs, and traces from all event broker form factors (appliance, software, and cloud) and makes them available through multiple channels:

1. Solace Insights Datadog Sub-org – Cloud-based dashboards and analytics
2. Metrics and Logs Export – Forward metrics to third-party observability platforms
3. Event Notifications – Real-time alert notifications

Today, we’re focusing on #2: Metrics and Logs Export to third-party backends.

How It Works

 

The Insights agent runs alongside your broker, collecting metrics via the Solace Monitoring API (SEMP).

It formats and forwards them to your observability platform using standard protocols:

• Prometheus format (scrape or push)
• OpenTelemetry (OTLP)
• Vendor-specific Exporters (Dynatrace, Splunk, etc.)

Why Forward Broker Metrics to Your Observability Platform?

Integrating event broker metrics into your existing observability tools provides three critical benefits:

Unified Visibility

Your DevOps and platform teams already live in tools like Datadog, Dynatrace, Prometheus, or Splunk. They monitor applications, infrastructure, databases—everything except the event broker.

With Insights forwarding:

• Single pane of glass – Monitor your entire event-driven architecture alongside applications
• No context switching – Engineers don’t need to learn a separate tool or log into Broker Manager
• Consistent workflows – Use the same dashboards, query language, and alerting you already know

Example: Your Datadog dashboard shows application CPU, database query times, AND queue depths—all in one view. When an issue occurs, you see the full picture immediately.

Proactive Alerting & Faster Response

Insights is great for troubleshooting, but it’s limited to Insights users only. Third-party tools enable proactive monitoring within the whole organization.

With Insights forwarding:

• Automated alerts – Get notified via Slack, PagerDuty, or email when queue depths spike or bridges go down
• Early warning – Catch issues like slow subscribers or resource exhaustion before customers are impacted
• Faster MTTR – Engineers see alerts in their existing incident response tools, reducing response time by 75%+

Example: Instead of discovering a slow subscriber after 2 hours of customer complaints, you get a Slack alert within 5 minutes when queue depth crosses 10,000 messages. The on-call engineer investigates immediately and resolves the issue before customers notice.

Historical Analysis & Capacity Planning

Your observability platform stores metrics and logs for months or years, up to your choice.

With Insights forwarding:

• Trend analysis – Identify growth patterns: “Message volumes growing 20% per month, need to add capacity by Q3”
• Seasonality planning – “Queue depths spike every Monday at 9 AM, let’s pre-scale”
• Post-mortem analysis – “What did queue depths look like during last month’s outage?”
• Correlation with deployments – “Did the last app release impact message processing rates?”

Example: Your capacity planning dashboard shows message throughput trends over 6 months, helping you forecast when you’ll need additional broker capacity—before you hit limits.

Setting Up Insights Forwarding

Solace Insights supports forwarding broker metrics to popular observability platforms. The configuration is done through the Solace Cloud console, where you can easily set up integrations without modifying broker configuration.

Supported Platforms

Solace Insights can forward data to:

• Prometheus – Open-source monitoring and alerting
• Dynatrace – AI-powered application monitoring
• Splunk – Data analytics and SIEM
• New Relic – Full-stack observability platform
• Elasticsearch – Search and analytics engine (via Elastic Observability)
• Generic HTTP or gRPC endpoints – Custom integrations via OTLP or other protocols

How to Configure Data Forwarding

Step 1: Access Solace Cloud Console

1. Log into your PubSub+ Cloud Console
2. Navigate to your Account Details in User & Account
3. Click Insights Settings
4. On the Forwarding Metrics and Logs tile, click Enable Forwarding Destination.

Step 2: Create a New Forwarding Destination

1. Add Destination
2. Select your observability platform (e.g., Datadog, Prometheus, Dynatrace)
   
3. Provide connection details:
   • For Prometheus: Endpoint URL for remote write
   • For Dynatrace: Dynatrace OTLP API endpoint and API token
   • For Splunk: HEC endpoint and token
   • For New Relic: OTLP endpoint and API key
   • For Elasticsearch: Elastic Cloud Managed OTLP Endpoint and API key
   • For Generic HTTP or gRPC endpoints: host:port of the endpoint and credentials headers
     

Step 3: Configure Forwarding Settings

1. Choose whether to forward metrics, logs, or both
2. Configure connection security:
   • Secure (TLS/SSL) – Validates server certificates
   • Insecure – Skips certificate validation
3. Optionally configure separate destinations for metrics vs. logs

Note: Once enabled, Insights automatically forwards all broker metrics and logs to your configured destination. The system forwards comprehensive observability data to give you complete visibility.

Step 4: Enable and Validate

1. Click Save and Enable to start forwarding metrics
2. Metrics will begin flowing to your platform within 1-2 minutes

Complete Setup Guide

For detailed step-by-step instructions and advanced configuration options, see the official documentation:

Solace Insights Data Forwarding Guide

This guide covers:

• Detailed configuration for each supported platform
• Authentication and security best practices
• Metric filtering and sampling options
• Troubleshooting connection issues
• Rate limits and quota management

Best Practices & Recommendations

Start with Critical Queues

Don’t try to monitor everything on day one. Start with:

• Business-critical queues (e.g., order processing, payment transactions)
• High-throughput queues (most likely to hit resource limits)
• Cross-region bridges (most likely to experience network issues)

Expand monitoring as you gain experience.

Set Contextual Thresholds

Generic thresholds don’t work well. A queue with 1,000 messages might be:

• Normal for a batch processing queue that fills up hourly
• Critical for a real-time transaction queue that should never exceed 100

Recommendation: Set thresholds based on:

• Historical baseline (P95, P99 values)
• Business SLAs (how long can customers wait?)
• Application capacity (what’s the consumer’s max throughput?)

Use your observability platform’s baseline and anomaly detection features.

Create Actionable Alerts

Bad alert: “Queue depth is high”
Good alert: “Q.cloud.order.cancelled depth is 15,234 (threshold: 10,000). Consumer lag: 45 seconds. App: order-cancellation-service. Runbook: https://wiki/slow-subscriber-response“

Include:

• Context: Which queue, what’s the current value, what’s the threshold
• Impact: What business process is affected
• Action: Link to runbook, suggest remediation (restart app, scale horizontally)

Correlate Broker and App Metrics

The real power comes from correlation. In Datadog/Dynatrace:

• Tag queues with the consuming application name
• Create dashboards that show queue metrics alongside app metrics (CPU, memory, request rate)
• Set up correlation so alerts show related metrics

Example: Alert fires for high queue depth. Dashboard immediately shows the consuming app’s CPU is at 100%—likely cause identified.

Monitor the Monitor

Set up alerts for the Insights agent itself:

• Agent down: No metrics received in last 5 minutes
• Collection lag: Metrics delayed by more than 30 seconds
• Export failures: Failed to forward metrics to backend

You need observability of your observability!

Conclusion

Event-driven architecture is powerful—but only if you can see what’s happening inside your system. Solace Insights forwarding bridges the visibility gap by bringing broker metrics into your existing observability tools.

The result? Proactive monitoring, faster incident response, and fewer customer-facing issues.

You don’t need to change your workflows. You don’t need to adopt new tools. You just need to connect your broker to the monitoring platform you already use.

Start small. Pick one critical queue. Set up one alert. See the value. Then expand.

Your on-call engineers (and your customers) will thank you.

Resources & Next Steps

Documentation

• Insights Overview
• Metrics Export Configuration
• Solace Insights Metrics and Checks

Integrations

• Prometheus Exporter
• OpenTelemetry and Dynatrace
• Splunk Add-on

Community

• Solace Community Forum
• GitHub Examples
• Solace Academy Training

Talk to Us

• Questions? Reach out to your Solace account team
• Want a demo? Contact us for a personalized walkthrough
• Ready to get started? We can help with architecture and implementation

The adoption of AI by enterprises is accelerating, but many initiatives fail to move beyond pilots. While teams can build capable agents quickly, those agents often fail to integrate cleanly with real enterprise systems and other agents. The challenge is not intelligence — it is integration and orchestration.

Agents must be able to talk to and work with ticketing systems, documentation platforms, internal APIs, and operational workflows without compromising security, governance, or reliability. Systems that rely on synchronous calls and tightly coupled workflows may succeed in demos, but they introduce fragility, latency, and operational risk that doom them to failure in production.

What enterprise AI needs is a durable foundation for integration and orchestration — one that links distributed systems, facilitates long-running processes, and can carry on through failures of individual agents, applications, and network links.

Why Agent Mesh is the Right Foundation

Solace Agent Mesh is not a standalone AI framework. It is built on top of Solace Platform, which many of the world’s leading enterprises have used to build event meshes that make real-time data available across their mission‑critical distributed systems like factory floors, stock markets, supply chains, and trading systems.

Where many AI frameworks assume synchronous calls and tightly coupled workflows, Agent Mesh uses an asynchronous, decoupled foundation. This enables agents to reliably communicate across long‑running processes, partial failures, multiple environments, and strict governance boundaries.

By orchestrating agents on top of an event mesh, you gain:

• Asynchronous coordination without blocking
• Built-in buffering and backpressure
• Natural fan-out and intelligent routing
• Replay and auditability
• Location transparency across environments

This transforms agents from experimental tools into resilient enterprise services.

Enterprise adoption also depends on how agents are introduced and connected. Organizations already have existing agents, services, and domain specific AI components built using different technologies and deployed across multiple environments. Agent Mesh is designed to integrate these external agents into a shared orchestration layer rather than replace them.

This integration is achieved through two complementary methods:

• A2A, which allows external agents to participate directly in agent-to-agent workflows
• MCP, which provides a governed integration surface for invoking external services and capabilities

 

Agent Discovery and Integration over the Event Mesh

For agent orchestration to work at enterprise scale, agents must be discoverable, describable, and dynamically connectable without hard‑coding endpoints or relying on centralized registries.

Agent Cards are defined as part of the A2A interaction model and provide declarative descriptions of an agent’s identity, skills, interfaces, and security requirements. Solace Agent Mesh implements Agent Cards over the event mesh by publishing them as events through the broker, enabling orchestrators to subscribe to capability announcements and route requests dynamically.

How Agent Cards flow through the Event Mesh

Agent Cards are published as events, enabling dynamic discovery and loose coupling. Readers who are new to Solace topic hierarchies and publish subscribe semantics can refer to this overview for background.

A typical topic taxonomy includes:

• {namespace}/a2a/v1/discovery/agentcards — agent capability announcements
• {namespace}/a2a/v1/agent/request/{agent_name} — requests to an agent
• {namespace}/a2a/v1/agent/response/{agent_name}/{request_id} — asynchronous responses
• {namespace}/a2a/v1/agent/status/{agent_name} — health and lifecycle updates

Because all interactions are event‑driven, agents can be added, removed, or relocated without reconfiguration to the agent itself, as long as it integrates via A2A or MCP.

MCP Server: External Incident Resolver Agent Example

To make this concrete, consider an external custom agent: an Incident Resolver. The resolver analyzes incident context, retrieves relevant history and documentation, and produces an actionable status summary. It is integrated into Solace Agent Mesh via an MCP Server so it can be invoked asynchronously through publish/subscribe topics.

Integration Steps

To bring this external agent into Solace Agent Mesh:

1. Create an MCP Server that wraps your external agent and exposes its capabilities as MCP tools
2. Create a SAM Agent configured to connect to the MCP Server
3. Define the Agent Card describing the agent’s skills and tools
4. Deploy — SAM publishes the Agent Card and subscribes to the appropriate request/response topics

Agent Card

The Agent Card advertises the Incident Resolver’s capabilities to the mesh (skills and the MCP tools behind them), along with interface and security requirements. Orchestrators use these cards to select the right agent at runtime without hard‑coded endpoints.

Topic Taxonomy

Once deployed, SAM automatically generates topic subscriptions for the Incident Resolver agent. For the namespace incident-mgmt:

Topic-Pattern	Purpose
incident-mgmt/a2a/v1/discovery/agentcards	Agent Card announcements
incident-mgmt/a2a/v1/agent/request/incident_resolver	Requests TO the agent
incident-mgmt/a2a/v1/agent/response/incident_resolver	Responses FROM the agent
incident-mgmt/a2a/v1/agent/status/incident_resolver	Agent health/status updates
incident-mgmt/sam/events/session/>	Session management

All communication flows through the Solace broker using publish/subscribe semantics. Requests are published to the agent’s request topic; responses are published back on response topics correlated by request_id, enabling asynchronous and resilient workflows.

End-to-End Orchestration Flow

1. A user submits a request, for example: “What’s the status of INC-1234?”, which is published as an event to
   incident-mgmt/a2a/v1/agent/request/orchestrator.
2. The orchestrator (Agent Mesh agent) consumes the request event and evaluates available Agent Cards to determine the appropriate agent capability and required context.
3. The orchestrator publishes the request event to the selected agent’s request topic:
   incident-mgmt/a2a/v1/agent/request/incident_resolver.
   The Incident Resolver agent is subscribed to this topic and receives the event asynchronously.
4. The Incident Resolver agent processes the event and invokes an MCP tool, for example
   suggestResolution("INC-1234").
5. The MCP Server authenticates via OAuth2, invokes the external Incident Resolver agent or service, and returns the result to the Incident Resolver agent.
6. Incident Resolver agent publishes the result as an event to
   incident-mgmt/a2a/v1/agent/response/incident_resolver/{request_id}.

A2A Proxy Integration

While MCP integration wraps external agents behind an MCP Server, A2A integration provides a complementary path. The key architectural difference is the proxy layer.

With MCP, an Agent Mesh agent invokes an MCP Server that wraps the external agent. With the A2A Proxy, the external agent runs independently with its own A2A endpoint, while the proxy bridges between the event mesh and HTTP. This allows external agents to participate in Agent Mesh workflows without any Solace-specific dependencies.

The A2A Proxy discovers A2A-native agents, retrieves their Agent Cards, and publishes those cards into the event mesh so the orchestrator can route requests transparently. From the orchestrator’s perspective, proxied agents are indistinguishable from native SAM agents.

Use MCP when you want a governed wrapper around existing tools or services. Use A2A Proxy when agents already speak A2A and should remain independently deployable.

What This Gives You

You Control	Agent Mesh Provides
Agent logic, reasoning, and framework	Discovery via Agent Cards over event mesh
Where it runs (cloud, on-prem, edge)	Event-driven orchestration and routing
What tools, APIs, and data sources it uses	MCP and A2A Proxy for protocol bridging
MCP and A2A Proxy for protocol bridging	Governance, observability, and audit
Independent scaling and deployment	Resilient pub/sub delivery and replay

You keep full control over your agent’s logic, where it runs (cloud, on‑prem, edge), and the framework it uses internally—while Agent Mesh provides discovery (Agent Cards), event‑driven orchestration, governance, observability, and resilient pub/sub delivery.

Here is an example illustration of the observer agent execution with Agent Mesh:

Conclusion

Enterprise AI success depends on integrating agents with real systems safely and reliably. With MCP integration for wrapping external tools, A2A Proxy for connecting native A2A agents, and event‑driven discovery via Agent Cards, Agent Mesh lets you bring your own agents—built with any framework, running anywhere—into a governed orchestration layer.

Key takeaways:

• MCP provides the governed bridge between SAM and your external tools and agents
• A2A Proxy enables native A2A agents to participate in the mesh without wrappers or Solace-specific dependencies
• Agent Cards enable dynamic discovery and selection without hard‑coded endpoints
• Topic-based routing enables asynchronous, resilient communication at scale
• You keep control of your agent’s logic, location, and implementation

Bring your own agent. Let SAM orchestrate it.

Rail operations live in motion. Trains move, platforms change, delays ripple—and the control room needs to know now so it can act before disruptions cascade. In this post, I’ll use a railway monitoring prototype to show how an event-driven architecture (EDA) makes operational systems faster, more resilient, and easier to evolve. We’ll focus on the operational domain model (Zone, Division, Route, Schedule, Journey, Station, Platform) and show how Solace Event Portal helps design and govern an event mesh that scales.

Why EDA for rail ops?

Rail is a perfect fit for EDA because operational facts are inherently events:

• A train departs a station.
• A platform is reassigned.
• A schedule is updated.
• A journey is delayed.

Each of these operational facts matters to more than one system at the same time—dispatch, passenger apps, station operations, maintenance, analytics, and automation—so broadcasting them as events is a natural fit.

Also note that these are not request/response interactions. They are facts that need to propagate in real time to many consumers: dispatch, passenger apps, maintenance, analytics, and automation. EDA makes those facts first-class, scalable, and reusable.

Operational domains we model

Core domains (Ops focus)

• Zone: Large operational regions, often managed by different control centers
• Division: Sub-areas inside zones
• Route: The planned path a train follows across stations
• Schedule: The planned timetable for a train, including changes
• Journey: The live, in-motion execution of a schedule
• Station: Physical location where trains stop, pass through, or originate/terminate
• Platform: Physical resource assignment at stations

Potential expansion

• Crew, rolling stock, maintenance, yards, signals/blocks, incidents, weather, passenger load, freight, power

Event-driven system view

In this model, each domain publishes its own events. Consumers subscribe to what they need, without tight coupling to the producers.

Example Operational Scenario:
Alert Generation + Management

When an alert is raised onboard a running train (for example, an AC malfunction or a water issue), it is automatically propagated to the next station for action. If the alert remains unserved/unattended, it continues to roll forward to subsequent stations until the final station of the journey is reached. If still unserved at the end, the system publishes an unserved alert to indicate a failure scenario.

This event trail enables analytics on alert/issue management performance at both station level and train level. Over time, it helps identify actionable operational insights—such as repeated failure points, slow response stations, or alert types that require better preventive maintenance—ultimately improving passenger experience.

Event flow Examples

• AlertRaised is published when an alert is raised in the running train
• AlertServed is published when a station attends to the issue
  If the alert is not attended at a station, AlertMissed is published, followed by a new AlertRaised event targeting the next station
• Finally, if an alert remains unserved until the journey ends, AlertUnserved is published to indicate the end-state failure scenario

Consumers and Subscriptions

Ops Automation, Control Room UI, and Analytics services subscribe to operational alert events for real-time coordination and performance tracking. Passenger-facing systems typically subscribe only to schedule/platform updates needed for customer notifications.

Domain-Driven Event Taxonomy

Events should be named and grouped by the operational domain that owns them. Here’s a starter taxonomy for ops-focused rail monitoring.

Zone	ZoneCreated, ZoneUpdated
Route	RouteDefined, RouteUpdated, RouteClosed
Schedule	ScheduleCreated, ScheduleUpdated, ScheduleCancelled
Journey	JourneyStarted, JourneyDepartedStation, JourneyArrivedStation, JourneyDelayed, JourneyCompleted
Station	StationCreated, StationUpdated, StationClosed, StationReopened
Platform	PlatformAssigned, PlatformReassigned, PlatformCleared

Topic Hierarchy Used in Prototype

The prototype uses a tms (train monitoring system) namespace with explicit versions and routing keys. This keeps events discoverable, versioned, and easy to filter.

tms/{entity}/v1/{event}/{...routing-keys}

 

Train Lifecycle Events

• tms/train/v1/departed/origin/{origin}/{trainNumber}/{destination}
• tms/train/v1/arrived/destination/{origin}/{trainNumber}/{destination}

Station Movement Events

• tms/station/v1/stopped/{currentStation}/{previousStation}/{trainNumber}/{nextStation}
• tms/station/v1/arrived/{currentStation}/{previousStation}/{trainNumber}/{nextStation}
• tms/station/v1/departed/{currentStation}/{previousStation}/{trainNumber}/{nextStation}

Alert Lifecycle Events

• tms/alert/v1/raised/{alertType}/{trainNumber}/{stationCode}
• tms/alert/v1/served/{alertType}/{trainNumber}/{stationCode}
• tms/alert/v1/missed/{alertType}/{trainNumber}/{stationCode}
• tms/alert/v1/unserved/{alertType}/{trainNumber}/{stationCode}

Subscription Patterns

• tms/train/v1/>
• tms/station/v1/>
• tms/alert/v1/raised/>
• tms/alert/v1/served/>;
• tms/alert/v1/missed/>
• tms/alert/v1/unserved/>
• tms/> (all TMS events)

 

Extending the Hierarchy for Ops Domains

To bring Zone, Division, Route, Schedule, Journey, and Platform into the same scheme, keep the tms/{domain}/v1/{event} structure and use routing keys consistently:

• tms/zone/v1/updated/{zoneId}
• tms/division/v1/updated/{divisionId}
• tms/route/v1/defined/{routeId}
• tms/schedule/v1/updated/{scheduleId}
• tms/journey/v1/departed/{journeyId}/{stationCode}
• tms/platform/v1/assigned/{stationCode}/{platformId}

An Event-driven Rail Ops Prototype

Here is an EDA interaction diagram from Solace Event Portal for the railway monitoring prototype.
It highlights how key producers (Train Movement, Station Management, Alert Management) publish real-time operational events such as TrainArrived/Departed, StationArrived/Departed/Stopped, and AlertRaised/Served/Missed, which are then consumed by Ops Automation, Control Room UI, and Analytics & ETA services.

For the prototype, we keep the scope to operational domains and leave the door open for expansion. It is intentionally scoped to demonstrate event flow rather than model trains of “Vandebharath” class of Indian Railways that runs between major cities across the country. It focuses on:

• Train and station movement: single-train and multi-train simulation across a route with arrivals, stops, and departures.
• Alert lifecycle: raised, served, missed, and unserved alerts tied to trains and stations.
• Event topics and payloads: consistent, versioned topic hierarchy with payloads that carry operational context.
• Operational UI behaviors: live event panel, filtering by stream, and flags on stations that visualize alert state.
• Resilience patterns: publish toggle for operational control and an in-memory broker fallback when the external broker is unavailable.

The function of the prototype is to make the EDA model concrete and referenceable: it shows how a domain-owned event taxonomy, real-time topic subscriptions, and lightweight consumers can coordinate without tight coupling or point-to-point integrations.

This prototype is available on Github: Source Code  |  Demo

Use Cases Highlighted by the Prototype

• Control room UI subscribes to tms/train/v1/> and tms/station/v1/> for live tracking.
• Alert console subscribes to tms/alert/v1/raised/> and tms/alert/v1/missed/> for escalation.
• Ops automation listens to tms/station/v1/departed/> to trigger downstream workflows.
• Analytics/ETA consumes all TMS events to compute delays and performance trends.

How the Prototype Maps to the model

The simulation showcases these EDA ideas in a visual way:

• Train and station events are published on the tms/train/v1/* and tms/station/v1/* topics as trains move.
• Alert lifecycle events flow through tms/alert/v1/* with raised, served, missed, and unserved states.
• Alert types in the prototype include water tank, breakdown, AC malfunction, and emergency.
• Event views are categorized by train, station, and alert streams, mirroring domain-based subscriptions.
• Event publishing controls let operators turn event flow on/off, mirroring real-world operational governance.
• Dual messaging shows Solace PubSub+ with an in-memory fallback, demonstrating resilience in disconnected modes.

In production, each of those would be event producers feeding a shared mesh, not a single monolithic app.

Prototype to Production Mapping

Solace Advantages

Event Portal: Why it Matters Here

Solace Event Portal is the control plane for your event-driven architecture. In a rail system, it prevents chaos by making events explicit and governed.

Key capabilities used in this domain

• Cataloged event definitions so teams can discover and reuse existing events
• Schema and version governance to evolve safely without breaking consumers
• Lineage and ownership so every event have a domain owner and a lifecycle
• Domain-driven taxonomy that matches operational reality
• Reuse across teams (ops apps, analytics, passenger systems, maintenance)
• Event mesh alignment to ensure events flow across regions and systems

In the prototype, we simulate events (departures, arrivals, delays) and show how they can be published to the mesh. In a production system, this same taxonomy becomes the backbone for operational resilience and team autonomy.

Event Portal Prompt

If you want Event Portal to generate an EDA model aligned to this prototype, here is a detailed prompt you can use as-is in the AI-Designer feature:

Create an event-driven architecture model for railway operations monitoring and control. Use an ops-focused domain model with Zone, Division, Route, Schedule, Journey, and Platform as top-level domains, plus Train, Station, and Alert streams aligned to the existing prototype.

 

Topic hierarchy (must follow exactly for Train, Station, Alert):

tms/train/v1/{activityType}/origin/{origin}/{trainNumber}/{destination}
tms/train/v1/{activityType}/destination/{origin}/{trainNumber}/{destination}
tms/station/v1/{trainStatus}/{currentStation}/{previousStation}/{trainNumber}/{nextStation}
tms/alert/v1/{alertStatus}/{alertType}/{trainNumber}/{stationCode}

Define event schemas for station movement and alert lifecycle with fields based on the prototype payloads:
status, previousStation, previousStationName, currentStation, currentStationName, nextStation, nextStationName, distanceTraveled, trainNumber, trainName, time.

Also define a minimal Train event schema with:
status, origin, originName, destination, destinationName, currentStation, nextStation, previousStation, distanceTraveled, trainNumber, trainName, time.

Alert event schema should include:
alertType, trainNumber, stationCode, stationName, timestamp, severity, description.

Create applications with ownership/lineage and bindings:

• – Train Simulation (producer for tms/train/v1/*, tms/station/v1/*)
• – Alert System (producer for tms/alert/v1/*)
• – Control Room UI (consumer of tms/train/v1/>, tms/station/v1/>, tms/alert/v1/>)
• – Ops Automation (consumer of tms/station/v1/departed/>, tms/alert/v1/missed/>)
• – Analytics/ETA (consumer of tms/>)

Add versioning guidance: v1 topics for compatible changes; introduce v2 topics for breaking changes with dual-publish (when needed).

Model an event mesh spanning multiple regions, with low-latency delivery for ops UI and alerting.

Document domain ownership (Zone, Division, Route, Schedule, Journey, Platform) and lineage for each event.

Example Event Schema

Event Portal allows you to dig into the details, even down to the specific schema which defines the payload of an event. Here’s a simplified schema based on the prototype payload for a station departure event. In the prototype, the topic conveys the event type and the payload includes a status field.

{
"status": "departed",
"previousStation": "BWN",
"previousStationName": "Barddhaman",
"currentStation": "BHP",
"currentStationName": "Bolpur Shantiniketan",
"nextStation": "ASN",
"nextStationName": "Asansol",
"distanceTraveled": 842.4,
"trainNumber": "12987",
"trainName": "Howrah Rajdhani",
"time": "19/03/2025 10:15:00"
}

Event Portal tracks this schema, versions it, and ties it to its owning domain so it can evolve without surprises.

Solace Event Mesh

Rail operations demand low latency, high throughput, and flexibility across heterogeneous systems. Solace helps in several ways:

• Multi-protocol support (e.g., MQTT, AMQP, REST, WebSocket, JMS)
• Real-time, low-latency delivery for control-room dashboards and alerts
• Event mesh for multi-region and multi-system data movement
• Routing and filtering so consumers subscribe only to what they need
• Operational visibility for monitoring and compliance

For a modern rail ecosystem, this means you can integrate legacy systems and new services without re-architecting every interaction.

Event Versioning

The prototype already carries a version in the topic. In production, this enables strict compatibility:

• Patch changes: Add optional fields in payloads; keep the topic version.
• Minor changes: Add new event types or optional routing keys; keep v1.
• Breaking changes: Introduce v2 topics and dual-publish during migration.
• Deprecation: Use Event Portal to mark events end-of-life and track consumers.

This keeps real-time systems stable while still allowing evolution.

Performance

Operational UIs and alerts lose value if they arrive late. The prototype highlights this with:

• Live event panels that stream train, station, and alert events as they occur.
• Multi-train simulation to stress event volumes and filtering.
• Publish toggle to model operational control over event flow.

Solace’s low-latency delivery. High throughput capacity, and sophisticated filtering model map directly to these needs.

What the Event Mesh Unlocks Next

Once the operational events are in the mesh, you can build specialized systems without reworking the core:

• Micro-integrations for station systems, passenger info, and maintenance
• Predictive analytics based on journey and schedule events
• Automation (e.g., dynamic platform reassignment, delay propagation)
• Agent Mesh integrations for AI/ML assistants and automated workflows

This is where the prototype moves from a demo to a roadmap.

Summary

Event-driven architecture is a natural fit for rail operations because the business is already event-based. With Solace Event Portal and the Solace platform, you can design an event taxonomy aligned to operational domains, govern it with schemas and ownership, and scale it across an event mesh. The result is a system that’s faster to evolve, more reliable in real time, and ready for expansion into broader rail ecosystems.

If you’re exploring EDA for transportation and tracking, this prototype is a small but concrete example of what’s possible.

Scale smarter. Deploy faster. Operate more efficiently.

Today we’re excited to introduce two major advancements that make it even easier to build and scale event-driven integrations: multi-flow cloud micro-integrations and a new AI Mapping Assistant. Together, they streamline configuration, accelerate data transformation, and empower teams to move faster with less manual effort.

Multi-Flow Micro-Integrations:
Efficient Deployment of Related Flows

Solace micro-integrations already help teams connect systems in real time using lightweight, event-driven patterns. With our new multi-flow capability, customers can now group “similar” integrations—like multiple IBM MQ-to-Solace flows sharing the same connection details—into a single deployment. Every existing cloud micro-integration is now multi-flow capable—no migration required.

Key Benefits

Instead of configuring and deploying each flow individually, you can enter shared connection information once, define multiple event flows, and deploy them together, which offers the following benefits:

• Faster setup & deployment: Group related flows and deploy them in one click—no more duplicate configuration.
• More efficient cloud usage: Improved compute efficiency in Solace Cloud results in lower price per flow and encourages broader adoption of micro-integrations.
• Consistency across deployment models: Cloud micro-integrations are now even more aligned with self-managed micro-integrations, simplifying decisions and future-proofing your architecture.

Why It Matters

As event-driven systems scale, the integration layer must scale just as easily. Multi-flow micro-integrations let you:

• Build and update integrations faster
• Reduce operational overhead
• Scale with confidence—without added complexity

This is all about giving you more control, speed, and efficiency as your event-driven ecosystem grows.

AI Mapping Assistant:
Smarter, Faster Payload Transformation

As enterprise environments become more distributed and data flows across hundreds of applications, mapping and transforming event payloads has become one of the most time-consuming parts of integration development.

Traditionally, teams spend significant time analyzing schemas, writing custom transformations, and debugging mismatches—slowing delivery and increasing cognitive burden for integration experts and developers.

This new capability dramatically accelerates the mapping process. By understanding event payloads, suggesting field mappings, and generating transformation examples, it takes the manual heavy lifting out of schema alignment and data transformation.

Just provide source and target payloads—the AI assistant will propose intelligent mappings that you can accept, refine, and deploy.

Combined with our chained transformations interface, this creates a guided, intuitive mapping experience that empowers both developers and business users.

What This Means for You

• Faster development with automated mapping suggestions
• Lower barrier to entry for citizen integrators and analysts
• Reduced cognitive load for technical teams
• Greater consistency and accuracy in transformation logic
• Future-ready workflows that adapt as event schemas evolve

With the AI Mapping Assistant, you don’t start from a blank canvas—you start with smart, context-aware mapping guidance. See it in action — Watch the demo

New Micro-Integrations

We’re also continuing to expand our portfolio with new micro-integrations that let you integrate more systems into your event mesh faster and with less effort.

• Oracle Database CDC
• MySQL CDC
• MongoDB CDC
• IBM DB2 CDC
• Azure Cosmos DB
• Azure Blob Storage
• Amazon S3
• Google Cloud Storage
• PostgreSQL CDC | Solace Integration Hub | Solace
• Microsoft SQL Server CDC | Solace Integration Hub | Solace

Get Started with Micro-Integrations

Multi-flow micro-Integrations and the AI Mapping Assistant are now available to all Solace cloud micro-integration customers—no upgrades or migrations required.

• Convert existing micro-integrations into multi-flow deployments
• Try the AI assistant to speed up data mapping
• Explore new metadata-aware transformation capabilities
• Browse our growing library of micro-integrations

Check out our Integration Hub to check our growing library of micro-integrations for your favorite technologies.

When we first introduced Solace Event Portal’s AI Design Assistant as an experimental feature, it was a sneak peek into what AI could do for event-driven architecture (EDA). The goal was simple: make it easier—and faster—for teams to understand how event-driven systems fit together.

Now, it’s officially here. AI Design Assistant is now available for all users in Solace Event Portal, and it’s already helping architects, platform teams, and developers evaluate the platform by bringing their EDA ideas to life—instantly.

From “What if…” to “Wow!”

Here’s the magic part: with just one input—your company’s name and optionally a summary of what your business does—AI Design Assistant instantly generates a set of application domains, applications, events, topics, and schemes all based on your industry and stated goal.

You’ll see how your business domains, applications, and events could be modeled and interact across your organization. It’s not just a visualization—it’s a detailed, interactive, editable model you can explore and refine.  Once you are happy with the design, you can even promote the broker configurations for your designed applications directly into your runtime mesh from the tool.  This will illustrate how powerful Event Portal is in helping your teams get access to the event data flowing through your brokers or event mesh in your runtime environments.

What used to take hours of planning and whiteboarding, or just poking around in Event Portal to explore, can now happen in seconds.

“Event Portal’s AI Design Assistant was helpful for generating quasi relevant content to onboard and discover what Solace Event Portal can do.”
-Engineering Lead, Major Australian Retailer

Built for Learning, Built for Doing

AI Design Assistant has one goal in mind: make event-driven thinking accessible.

For anyone new to EDA, it’s a game-changer. Instead of starting from a blank canvas, you start with a meaningful example model specific to your industry and use case. You can explore what EDA looks like in context, see how applications publish and subscribe to events, and learn about the relationships that make modern, real-time systems work.

And whether you’re defining standards, managing a platform, or building the next great integration, AI Design Assistant meets you where you are:

• For Integration Architects: Quickly validate architectural patterns, explore event interactions across domains, and communicate designs with visual clarity.
• For Platform Teams: Accelerate onboarding by giving developers a guided, AI-assisted way to understand how published events are modeled with best practice topic structures and representative payload schemas. As well as how downstream consuming applications subscribe to the event data they need and are onboarded into your ecosystem.
• For Developers: Jumpstart your learning curve—see how event-driven applications interact and connect to the brokers, discover best practices, and get inspired to start building your own apps.

For some, it’s a hands-on learning tool. For others, it’s a creative co-designer that helps you brainstorm faster, model smarter, and move from idea to design to implementation without missing a beat.

Examples of AI Design Assistant in Action

Early adopters have already put our AI Design Assistant to work across industries, using it to visualize how events could streamline processes, improve responsiveness, and modernize integration landscapes.

Here’s a glimpse of what users have created so far:

Retail

A real-time inventory flow connecting online and in-store systems, with supply chain and warehousing applications, automatically adjusting product availability across channels.

Transportation

An event-driven fleet tracking system that models vehicle telemetry, maintenance alerts, and route optimizations.

Banking

A customer onboarding model that maps how KYC, payments, and account events interact across distributed systems.

Now Fully Integrated and Production-Ready

This launch brings more than polish—it brings power.

AI Design Assistant includes:

• Smarter AI models tuned for real-world business contexts and industry patterns
• Editable output so you can refine your AI-generated model directly in Event Portal before and after the EDA assets are created and cataloged
• Creation of sample payload schemas for the generated events types
• Integration with Runtime Event Manager, allowing you to promote the broker config for your new applications and events to a modeled event mesh
• Faster generation and better contextual mapping to help you visualize and evolve your design

It’s no longer just a learning tool—it could even be part of your new architecture workflow with some user touchpoints.

Why This Matters

EDA is powerful, but it can feel complex at first. AI Design Assistant lowers the barrier by helping users see how everything fits together with some best practices—instantly.

Whether you’re an architect introducing event-driven thinking to a new team, a platform owner scaling a mesh across your organization, or a developer experimenting with your first event flow—AI Design Assistant helps you:

• Evaluate Solace Platform – speeding up its setup and exploration
• Learn faster — by visualizing how events flow across systems
• Communicate better — by showing tangible, editable models to stakeholders
• Move faster — by promoting AI-generated designs into your runtime environments

It’s how teams are learning, experimenting, and designing smarter—without slowing down.

Your AI-powered Co-designer Awaits

AI Design Assistant is more than a fancy tool—it’s your creative partner in evangelizing and building the event-driven future of your organization.

Start by entering a few details about your business. In seconds, you’ll see your business mapped into events, domains, applications, and their interactions. From there, you can shape, share, and scale your event-driven vision—without guesswork.

Try Solace Event Portal’s AI Design Assistant today!

Closing Thought

This launch marks a major milestone in our vision to make event-driven architecture as intuitive and accessible as possible. AI Design Assistant is just the beginning—stay tuned as we continue to explore how AI can help automate, guide, and accelerate many more aspects of your EDA journey.

One challenge keeps surfacing in AI orchestration: context management. As Philipp Schmid explains, we’re witnessing a fundamental shift from prompt engineering to context engineering. It’s not just about writing better prompts anymore—it’s about managing everything the model sees: conversation history, memory, RAG retrievals, available tools, and structured outputs.

The problem gets worse as context windows grow. Anthropic’s engineering team describes this as “context rot”—model accuracy actually degrades as you add more tokens. This happens because of the transformer architecture itself: every token must attend to every other token, creating an exponential attention burden. Most agent failures aren’t model failures—they’re context failures.

This becomes critical when moving from pilot to production. As Ali Pourshahid, Solace’s Chief Engineering Officer, points out, stale data and batch-processing approaches fundamentally break AI agents in real-world environments. Traditional methods of passing massive datasets to large language models simply don’t scale.

But here’s where context engineering meets a bigger challenge: it’s not just about what information reaches the LLM. It’s about where data lives, how it’s processed, and when to involve the model at all. This is context management—the complete architecture of data flow in multi-agent systems.

Solace Agent Mesh tackles this through an event-driven approach that keeps data local, passes only schemas and metadata to LLMs, and uses intelligent query generation for analysis. Instead of sending everything to the model, agents store data locally in in-memory databases and only ask the LLM to generate queries—not process raw information.

The result: minimal token usage, faster processing, higher accuracy, and built-in security. As organizations deploy AI agents across the enterprise, this shift from context engineering to complete context management isn’t just optimization—it’s becoming essential for practical, cost-effective implementations.

The Context Management Crisis in Multi-Agent Systems

Before diving into solutions, let’s understand the problem. Traditional AI architectures often struggle with:

• Token Bloat: Sending entire datasets to LLMs consumes valuable tokens, driving up costs exponentially
• Context Pollution: Irrelevant data clutters the context window, reducing the quality of AI responses
• Processing Inefficiency: LLMs spending computational resources analyzing raw data rather than focusing on insights
• Accuracy Degradation: As context windows fill with unnecessary information, the precision of AI outputs suffers
• Latency Issues: Transmitting large datasets back and forth creates significant delays in response times
• Hallucinations: LLMs can produce an output that is plausible sounding but factually incorrect
• Inaccurate Mathematical Calculations: LLMs are not inherently good at mathematics as they are statistical in nature and used to generate text by predicting the most likely sequence of words based on training patterns, not by executing formal algorithms.

These challenges become exponentially more complex in multi-agent architectures where multiple AI agents need to collaborate, share information, manage session memory across interactions, and maintain coherent context across distributed systems.

The Solace Agent Mesh Approach: Intelligent Data Management

Solace Agent Mesh introduces a paradigm shift in how AI agents interact with data. Instead of the traditional “send everything to the LLM” approach, it implements an intelligent data management layer that fundamentally changes the game.

The Architecture of Efficiency

At its core, Solace Agent Mesh employs a sophisticated orchestration pattern that treats data as a first-class citizen in the AI workflow. Here’s how it revolutionizes context management:

1. Local Data Storage: When an agent retrieves data from a source, it stores it locally rather than passing all the data back to the LLM for further analysis.
2. In-Memory Database Creation: The system instantiates an in-memory SQL database with the retrieved data
3. Meta Data Based  Intelligence: Only the data schema, file type, summarized overview of the data and the schema is passed to the LLM, dramatically reducing token usage
4. Query Generation: The LLM crafts optimized SQL queries based on the schema and user intent
5. Local Execution: Queries run against the local database, with results processed by built-in visualization tools

Real-World Use Case: Monthly Sales Analysis

Let’s walk through a concrete example to illustrate this revolutionary approach. Imagine you need to analyze and visualize product sales month over month – this could potentially consist of millions of rows – each row consisting of fields like productId,customerId, region, date, quantity and revenue, the raw text representation quickly explodes in size.

In the traditional approach, the workflow is costly and inefficient. You would need to retrieve the entire dataset from the database, often millions of rows, and send it to the LLM. This alone could account for millions of tokens – increasing the cost and inefficiency of the entire process.
From there, the model would be asked to analyze the data, identify trends, recommend visualization strategies, and generate charts. The result is massive token consumption, slow processing, potential hallucinations, and potential inaccuracies due to the LLM’s limited context window and limited mathematical capabilities.

With Solace Agent Mesh, the process looks entirely different. The orchestrator dispatches sales agents to gather the necessary data, which is then stored locally as CSV artifacts. An in-memory SQL database is instantiated on the fly, and instead of sending all the raw data, only the schema, such as table structures, column names, and data types, is passed to the LLM. Using that schema, the model generates an optimized SQL query for the month-over-month analysis, which is executed locally against the in-memory database. The results are then rendered immediately with built-in visualization tools. This approach delivers minimal token usage, faster processing, higher accuracy, and instant visualization.

The Sales Order agent retrieves sales orders from Sales Forces, creates a CSV file of the orders, instantiates a database, and lets the orchestrator know of the data schema and relevant metadata to ask the LLM to construct a SQl query to analyze the data.

Extending the Pattern: Additional Use Cases

Customer Sentiment Analysis Across Multiple Channels

Organizations often need to analyze customer feedback drawn from social media, support tickets, and product reviews. Traditionally, pushing millions of text entries through an LLM would be both slow and prohibitively expensive. With Solace Agent Mesh, however, agents collect the data from various channels, and natural language processing happens locally for initial categorization. Structured sentiment scores are stored in an in-memory database, and the LLM only receives the schema in order to generate queries for higher-level trend analysis. The result is the ability to surface complex cross-channel sentiment patterns without overwhelming the model or burning through tokens.

Real-Time Supply Chain Optimization

Managing supply chain operations across warehouses and transportation routes requires ingesting high-volume, real-time data. Traditional approaches that attempt to pipe live streams into an LLM quickly run into context limitations. By contrast, Solace Agent Mesh enables event-driven agents to capture logistics data and process it locally, flagging anomalies and bottlenecks in real time. Time-series data is stored in optimized in-memory structures, and the LLM is tasked only with generating optimization strategies based on summarized patterns. Execution happens through the agents themselves, reducing reliance on constant LLM interaction while keeping performance responsive.

Financial Risk Assessment and Compliance

Financial services teams face the dual challenge of handling sensitive information and processing large transaction volumes. Running all of this through an LLM is both risky and expensive. With Solace Agent Mesh, sensitive data remains securely stored within the organization, while local pattern matching and anomaly detection identify potential fraud. Only statistical summaries and schemas are shared with the LLM, which generates targeted queries for compliance checks and trend identification. Audit trails are maintained locally, ensuring regulatory requirements are met without exposing sensitive information.

Healthcare Patient Journey Mapping

In healthcare, mapping patient interactions across multiple touchpoints is critical for improving care delivery, but HIPAA compliance and data volume constraints make traditional LLM-driven workflows impractical. Solace Agent Mesh solves this by ensuring protected health information remains in secure local storage. Anonymized schemas are shared with the LLM, which generates intelligent queries to identify patient journey patterns. Results are visualized through built-in tools, offering actionable insights while maintaining strict privacy standards. Real-time updates allow providers to continuously optimize care delivery without compromising patient confidentiality.

The Future of Context Management

As AI systems become more sophisticated and data volumes continue to explode, intelligent context management will become not just an optimization, but a necessity. Solace Agent Mesh’s approach represents a fundamental shift in how we think about AI-data interactions.

The framework’s ability to:

• Maintain data locality
• Reduce token consumption
• Improve processing speed
• Enhance accuracy
• Ensure security and compliance

…positions it at the forefront of the next generation of AI orchestration platforms.

Conclusion

As AI agents are increasingly being deployed across the enterprise, smart context management is becoming a more challenging task to address. Solace Agent Mesh is tackling this challenge head on. By reimagining how AI agents interact with data. By keeping datasets local, passing only schemas and necessary metadata to the LLMs, and leveraging intelligent query generation, organizations can build more efficient, accurate, and scalable AI systems.

Whether you’re analyzing sales trends, optimizing supply chains, ensuring financial compliance, or improving healthcare delivery, the intelligent data management capabilities of Solace Agent Mesh offer a path to AI implementations that are not just powerful, but practical, cost effective and accurate.

As we move into an era where AI agents become integral to business operations, the ability to manage context intelligently will separate successful implementations from costly failures. Solace Agent Mesh provides the foundation for this success, enabling organizations to harness the full power of AI while maintaining control over their data and their costs.

The future of multi-agent AI architectures isn’t about sending more data to LLMs, it’s about sending the right information at the right time. And with Solace Agent Mesh, that future is already here.

IBM’s announcement that it will acquire Confluent for $11B is another strong signal that real-time data is becoming an increasingly critical dependency for organizations aiming to accelerate agentic AI adoption .In the age of agentic AI, enterprise systems simply can’t function without up-to-the-moment information. Agentic AI and automation hold the potential to revolutionize the way companies improve customer experience, make smart decisions, and optimize their operational efficiency — if they can effectively make the ever-increasing amount of data they capture and generate available everywhere it is needed, in real-time.

Why Real-Time Data is Critical for Enterprise AI

IBM’s announcement emphasized agentic AI as a strategic driver for the deal, and we agree with their logic, for three reasons:

1. AI agents and the applications, connected devices and information sources they rely on are increasingly distributed – running in diverse clouds, datacenters and edge environments around the world.
2. Agentic AI systems rely on real-time information that’s captured and generated in all corners of that distributed ecosystem, and that requires a modern, event-driven foundation.
3. Event-driven architecture replaces legacy batch and point-to-point data exchange with a decoupled approach that supports simultaneous delivery to countless recipients, and makes it easy to add more at any time.

More than two decades ago, Solace was founded with a focus on moving data in real-time as efficiently as possible. Since then, we have developed a platform that is trusted by global enterprises with the most demanding operational use cases.  At the heart of our solution is a unique approach that sets us up perfectly to push the envelope and meet the new and demanding real-time requirements now introduced by agentic AI.

It also is the foundation for Solace Agent Mesh, our newly introduced production-ready agentic AI platform. It helps you build agentic applications that work with your enterprise systems, data and security requirements from Day 1.

What This Means for You and How we Can Help

Many of the enterprise clients we work with are already asking: How do we ensure our real-time data foundation can allow us to realize the potential of agentic AI ?

Our platform is designed to help enterprises move real-time data across complex heterogeneous environments without forcing alignment to a single cloud, vendor, or integration stack.

It’s why some of the world’s most demanding enterprises – like Airbus, Barclays, Danone, Heineken, JDE Peets, RBC, Renault, Stellantis and Unilever – rely on Solace to move their data in real-time to keep their business running, when it matters the most.

Our focus is helping enterprises build real-time data distribution that spans clouds, regions, business units, and now generative and agentic AI systems. Independence, interoperability, and openness are core to our strategy, and always will be.

If you have want to discuss how we can help capitalize on the opportunity of real-time data infrastructure and agentic AI, let’s talk.

Remember when “predictive maintenance” meant your equipment screamed at you before it exploded instead of during? Computerized maintenance management systems felt like the future—circa 2015. But let’s be honest: getting a work order that says “Pump 47 needs attention” is only marginally more useful than a fortune cookie that reads “Something will happen soon.”Today, companies across manufacturing, energy, and property management are replacing reactive maintenance with AI-powered predictive maintenance to turn alerts into actionable intelligence and optimize maintenance schedules.

Welcome to the age where machine learning and artificial intelligence is transforming predictive maintenance from an alarm system into something that resembles intelligence—particularly for companies operating in the oil and gas sector.

Unlike traditional preventative maintenance or reactive maintenance, AI in predictive maintenance uses machine learning models, historical maintenance records, new data, and predictive maintenance analytics to facilitate maintenance tasks, improve equipment reliability and asset performance.

The Problem with Being Predictive (But Not Smart)

Oilfield services companies have been running predictive maintenance systems for years, but early predictive maintenance technologies focused only on sensor anomalies, not on business outcomes or maintenance strategies. Sensors hum along in wellheads, drilling operations, and cementing equipment, monitoring vibration, temperature, pressure, and other variables. These systems dutifully generate work orders when something looks fishy, which then get dispatched to SAP or whatever other enterprise systems.

Optimizing Equipment Reliability Where it Matters Most

But here’s the thing: knowing that Equipment X needs maintenance is only half the battle. The other half? Figuring out whether Equipment X should be serviced before or after Equipment Y, and whether you should send Bob or Alice, and whether you need to order parts from Supplier A who’s reliable but slow, or Supplier B who’s fast but… well, let’s say “creatively consistent.”

By contrast, traditional predictive maintenance tools are like that friend who texts you “We need to talk” and then doesn’t elaborate. Sure, you have information. But you don’t have context. And in oilfield services, context is literally money. AI-driven predictive maintenance not only gives you the whole story, it gives you new data and initiates action.

Enter AI: How Predictive Maintenance is the Context Whisperer

So, what happens when you take a perfectly functional predictive maintenance system—the kind that’s been keeping offshore platforms and drilling operations running—and give it an AI upgrade? Magic!

Data Collection

Or more accurately, something that looks like magic but is actually data collection and data processing elevated to the clever synthesis of historical data and real-time data to enable more efficient operations.

Data Analysis

With AI systems for predictive maintenance machine learning, algorithms analyze real-time data from sensors, historical data in the form of maintenance records, and operational KPIs to detect anomalies, predict failures of critical equipment—and prioritize them by business impact. Making your maintenance practices not just predictive, but proactive maintenance and corrective maintenance. By helping you more intelligently schedule maintenance, AI tools can make your maintenance efforts can improve asset reliability and equipment effectiveness.

Data Processing

Data scientists are creating increasingly sophisticated machine learning algorithms and AI-based predictive maintenance systems that combine real-time data analysis with supply chain intelligence and customer sentiment. This is how real-time monitoring and AI tools transform maintenance data into business intelligence.

Instead of maintenance personnel receiving work orders that read like equipment ransom notes (“Motor 23 demands attention OR ELSE”), field service managers can now formulate maintenance schedules with something resembling actual business intelligence. We’re talking work orders enhanced with:

• Customer relationship data analysis: Because knowing that the operator whose cementing equipment needs servicing just renewed their multi-year contract hits differently than knowing they’ve been grumbling about switching service providers.

• Meeting sentiment analysis: That’s right—AI can now tell you that your last three meetings with the drilling contractor were about as cheerful as a dental appointment. Maybe their equipment jumps to the front of the line?

• Supply chain intelligence: Real-time visibility into whether the parts you need are sitting in a warehouse in Houston or on a container ship currently touring the scenic route around three continents. Or if the same part needs to be replaced on 200 well heads in the next 30 days, maybe bulk order is a possibility.

All of this gets synthesized—and here’s where it gets spicy—by predictive maintenance programs into priority and urgency rankings that actually make sense not just for your equipment by help predict equipment failures so you schedule maintenance more intelligently, reducing downtime and machine failures, but for your business.

The ROI of AI in Predictive Maintenance: Turning Data into Decisions

Let’s paint a picture. Your traditional preventive maintenance system, which does a fine job of continuous monitoring, and even real-time monitoring, fires off three work orders on a Monday morning:

1. Cementing unit at a major operator in the Permian Basin: Vibration readings elevated

2. Fracking pump at a shale development site: Temperature trending upward

3. Drilling motor at an offshore platform: Unusual noise detected

Now, which one do you tackle first? In the old system, maybe you’d go by severity of the sensor readings, or by who called first, or by whose rig is closest to where Bob happens to be having his morning coffee.

Predictive maintenance systems powered by AI can apply monitoring systems, machine learning and predictive maintenance analytics to recognize early warning signs and rank priorities based on contract value, operational processes, risk of machine failure, unplanned downtime cost, and asset reliability. That’s what makes AI-driven predictive maintenance important—balancing operational and commercial impact.

That’s why AI enhancement, you’re seeing the full picture:

Cementing Unit – Permian Basin Operator

• Priority: CRITICAL

• Customer sentiment: Very positive (last meeting included discussion of expansion into new formations)

• Contract value: $2.3M annually

• Parts availability: 2-day lead time

• Estimated downtime cost: $15K/day (well completion delays)

• Recommended action: Schedule immediately for Thursday when parts arrive

Fracking Pump – Shale Development Site

• Priority: MODERATE

• Customer sentiment: Frustrated (two service delays in past quarter)

• Contract renewal: Up in 6 months

• Parts availability: In stock at regional warehouse

• Estimated downtime cost: $8K/day (stage completion delays)

• Recommended action: Service ASAP to rebuild relationship

Drilling Motor – Offshore Platform

• Priority: LOW

• Customer sentiment: Neutral

• Contract value: $400K annually

• Parts availability: In stock

• Estimated downtime cost: $3K/day

• Recommended action: Schedule during next planned maintenance window

Suddenly, you’re not just preventing equipment failure—you’re preventing relationship failure, supply chain headaches, and the kind of costly decisions that happen when you’re operating blind in a capital-intensive industry.

The Secret Sauce of AI Predictive Maintenance: Synthesis

The real genius here isn’t that AI systems can perform data collection to read a customer relationship management system or check supply chain databases. Any decent integration could do that. The magic of AI in maintenance is that it makes it proactive maintenance. The emerging technology lies in the data synthesis—the ability to use machine learning and more to weigh multiple factors simultaneously and say, “Based on everything I know about your business, this is what matters most right now.”

With machine learning algorithms linked to sensor data, logistics and CRM insights, you can create comprehensive predictive maintenance models. It’s the difference between having a pile of puzzle pieces and having someone who can actually see what the final picture should look like. That’s how AI predictive maintenance solutions can empower maintenance teams to act strategically instead of reactively.

The predictive maintenance AI isn’t just regurgitating real-time data; it’s understanding that a $5K repair for a satisfied operator with a small contract might be less urgent than a $2K repair for a frustrated operator with a massive contract who’s already thinking about their options. It knows that parts on backorder change the equation of a particular equipment failure entirely. It understands that “critical” means different things depending on whether the client is in the middle of peak drilling season or experiencing a seasonal slowdown.

The Human Element: Actual Intelligence Complements Artificial Intelligence Technologies

Now, before you start worrying that Skynet is taking over your maintenance department, let’s be clear: the application of machine learning and artificial intelligence isn’t about replacing human decision-making; it’s about augmenting it.

The Role of Data Scientists

First, successful AI predictive maintenance strategies depend on collaboration between data scientists and maintenance teams, and human oversight ensures AI-powered predictive maintenance aligns with safety and business priorities, and asset management objectives.

Service managers still make the final calls over maintenance issues. But instead of making those calls based on incomplete information, gut feeling, and whoever’s yelling loudest, they’re making them based on comprehensive, synthesized intelligence that can detect anomalies and actually reflects business priorities.

Think of it as upgrading from playing checkers to playing chess. The rules are the same, but suddenly you can see twelve moves ahead instead of just one. And it’s documented—so  if the wrong decision is still made by the service manager, you can review, discuss, and maybe change the SOP so AI can help make a better decision, for every service managers.

The Bottom Line Impact of AI-Based Predictive Maintenance

Like any business, the oilfield business it’s about maximizing ROI—getting the most value from your limited resources of time, personnel, and parts.  Unplanned downtime and unnecessary repairs are margin assassins.

Traditional predictive maintenance powered by simple machine learning helped companies avoid catastrophic failures at well sites and drilling operations. Accurate predictions fueled by AI-based predictive maintenance help them optimize their entire service operation around business outcomes. It’s the difference between “keeping the wells producing” and “keeping the wells producing in a way that maximizes customer satisfaction, contract renewals, and profit margins.”

Better Asset Reliability; Fewer Equipment Failures

By integrating AI for predictive maintenance into daily operations, organizations increase equipment reliability, optimize maintenance schedules, and reduce costly downtime across facilities.

The work orders still flow into SAP (or whatever system you’re using). But now they arrive dressed for success, armed with context, and ranked in an order that reflects what matters to your business.

Is it perfect? No. Will it occasionally suggest something that makes you scratch your head? Probably. But it’s a whole lot better than staring at a list of equipment IDs and playing maintenance roulette.

Beyond Energy: How AI-Powered Predictive Maintenance Impacts Other Industries

And this isn’t just for oil and gas—AI-enabled predictive maintenance is becoming a key driver of operational efficiency in other industries, providing significant gains over various preventive maintenance strategies of yesterday. Here’s a few examples:

• Manufacturing: Using AI in predictive maintenance and machine learning to interpret and act on operational data minimize line interruptions and improve asset reliability.

• Property Management: AI enables predictive maintenance solutions that benefit property managers by use predictive models to reduce downtime by preventing HVAC, elevator, and utility system failures before they occur.

• Utilities & Infrastructure: Using advanced machine learning techniques, maintenance technologies and machine learning models, utility providers can recognize early warning signs and improve their maintenance management to enable real-time equipment health monitoring.

Implementing AI for Predictive Maintenance

Upgrading your maintenance from preventative maintenance and other various maintenance strategies to predictive maintenance won’t happen overnight. Here are some challenges you’ll face, things to consider, and suggestions for steps to get the process going.

Challenges and Considerations

• Data quality and infrastructure gaps.

• Over-reliance on algorithms without human validation.

• Change management for traditional maintenance teams.

• Importance of explainable AI and predictive maintenance governance.

Steps to take:

• Assess data readiness (sensor data + historical maintenance records)

• Select relevant machine learning algorithms and predictive models (anomaly detection, RUL prediction)

• Develop and train predictive maintenance models with data scientists

• Deploy and integrate AI-powered predictive maintenance with maintenance teams

• Continuously refine maintenance strategies based on predictive maintenance analytics outcomes

Welcome to Maintenance 3.0

We’ve come a long way from the days of “fix it when it breaks.” First we graduated to “fix it before it breaks.” Now we’re entering the era of “fix it before it breaks, in an order that makes business sense, with the right people and parts, and in a way that keeps your most valuable customers happy.” It’s a big step!

The next era of AI predictive maintenance isn’t just about preventive maintenance—it’s about using artificial intelligence to use operational data to orchestrate people, parts, and priorities through scalable predictive maintenance strategies that deliver measurable business impact in areas such as reducing downtime and labor costs, while extending equipment lifespan.

For companies serving the energy sector—whether that’s cementing, drilling, or completion services—this isn’t just a nice-to-have. It’s becoming table stakes in an industry where reducing unplanned downtime directly impacts well productivity and customer relationships.

It’s still predictive maintenance – it’s just finally as smart as the name implies.

We’ve mastered the prompt. But to make AI agents actually work in production, the enterprise needs a fundamentally new architecture—one built on real-time data, governance, and event-driven orchestration.

---

The initial wave of generative AI was defined by a sense of “magic.” We saw text generated in seconds, code written by machines, and images created from thin air. It was a period of rapid exploration, where the primary metric of success was the quality of the content created.

But as the dust settles on the initial hype cycle, enterprise leaders—from chief AI officers to CTOs—are asking a harder, more practical question: How do we turn this magic into real value for our business?

We are in the midst of a massive shift from generative AI (systems that create content) to agentic AI (systems that execute tasks). Companies want more from AI than summarizing a PDF or drafting marketing email. They want—intelligent agents that can autonomously manage workflows in their business.  Navigating supply chain disruptions, onboarding  a new client end-to-end, or instantly analyzing sales data across fragmented, hybrid cloud systems to trigger inventory restocking.

The aspiration is “agentic automation”: intelligent agents autonomously managing and executing multi-step business processes across multiple systems.  It’s a massive opportunity.

However, moving from proof-of-concepts (POC) running on a laptop to  resilient, production-grade agentic workflows is proving illusory. We are seeing high rates of “pilot purgatory,” where projects stall because they cannot scale, cannot be secured, or simply cannot handle the speed of real business.

The “Bespoke” Trap: Why Scaling Agentic AI is Hard

Currently, many organizations are approaching agentic AI with the same mindset they used for simple chatbots: they are building agents in isolation. A marketing team might build an agent using one open-source framework, while the IT operations team builds another using a different stack.

These become “bespoke” projects—fragile, siloed applications that either don’t interact at all, or rely on point-to-point integrations (usually REST APIs) to function. While this works for a demo, it creates four major barriers that prevent enterprises from moving to production.

Ungoverned AI Access

When you need your AI agents to have access to your actual data or act on your behalf, security becomes paramount. An agent that can execute transactions, move money, or update customer records creates a massive new attack surface.

Building agents in isolation often leads to “Shadow AI,” where access controls are hardcoded into the agent itself or missing entirely. Without a unified platform to govern authentication and scope of access, enterprises face a compliance nightmare. They cannot answer the simple question: Who authorized this agent to view this PII data?

Siloed, Rigid Infrastructure

AI assets—agents, prompt templates, vector databases—when introduced into an IT landscape in isolation, create new silos. If your AI architecture is rigidly designed, you cannot easily swap out an LLM (e.g., moving from GPT-4 to Claude 3) or reuse a successful agent in a new workflow.

This leads to the “Spaghetti Code” of the AI era. Developers end up maintaining bespoke connections for every single agent, killing agility and making the system incredibly brittle.

Slow, Bespoke Development

AI is also operationally challenging because the technology is immature and constantly evolving. Development teams that seek to implement AI projects in isolation invariably introduce different technologies and approaches. This results in every project becoming a “custom build.” For companies to speed ideas to reality, they require a standardized framework.

The Real-Time Data Gap

Most current AI architectures rely on static knowledge bases or batch-processed data. But the world doesn’t happen in batches. As noted in recent industry reports, Agentic AI requires event-driven data architectures to continuously provide high-quality, relevant, and contextual data.

If a logistics agent makes a decision based on inventory data that is even five minutes old, it risks “hallucinating” a solution that is physically impossible to execute. It might promise a shipment that cannot be fulfilled. To support the dynamic nature of agentic business activities, AI needs the “now,” not the “yesterday.” Without a real-time, event-driven foundation, agents are forever reacting to the past.

The Solution: A Complete Platform for Production-Ready Agentic AI

To solve these pain points, enterprises cannot rely on a patchwork of libraries and point solutions. They require a cohesive architecture designed specifically for the complexity of the enterprise. We need to treat AI agents not as standalone science experiments, but as first-class citizens of the IT landscape.

This is the design philosophy behind Solace Agent Mesh Enterprise.

Solace Agent Mesh is not just a tool; it is a production-ready platform designed to build, deploy, and orchestrate Agentic AI solutions. By leveraging the market-leading real-time data platform, it connects your agents to the pulse of your enterprise.

To move from “toy” to “tool,” an enterprise platform must deliver on three essential pillars:

Easy to Experiment and Build

Innovation dies in complexity. In most enterprises, the people who know how the business works (the subject matter experts) aren’t the same people who write the code. If building solutions requires deep technical expertise, good ideas never make it past the whiteboard. A strong platform should close that gap, lower the barrier to entry, make it easy to turn business intent into working systems without forcing subject matter experts to become developers.

• Democratized Development: Solace Agent Mesh addresses this by offering a no-code agent builder that includes an AI-assisted, form-based interface. This allows business analysts to create agents without writing code. Simultaneously, it offers pro-code agent building for developers who need to code sophisticated, custom logic.
• Rich Connectivity: Developers shouldn’t have to build the plumbing from scratch every time. The platform comes with out-of-the-box connectors for SQL, APIs, and MCP (Model Context Protocol). This allows agents to easily connect to both real-time streams, static knowledge bases and any enterprise application immediately.
• Flexible Workflows: Real-world business isn’t always linear. The platform uses an intelligent orchestrator that supports dynamic agent orchestration (breaking down inputs into tasks and assigning them in real-time) as well as prescriptive workflows (where the path is fixed to match your business or compliance reasons). This flexibility allows teams to start simple and evolve toward complexity.

Ready for Production

A POC might work on a laptop, but it won’t survive the enterprise. Production-grade AI requires resilience, security, scalability, and strict operational controls. This is where Solace Agent Mesh differentiates itself from lightweight open-source frameworks.

• High-Performance Orchestration: This is the core of the “Mesh” concept. Unlike REST-based chains that block and wait, Solace uses event-based agent messaging. This enables asynchronous, parallelized multi-agent orchestration. Multiple agents can work on different parts of a problem simultaneously. If one agent stalls, it doesn’t crash the entire workflow. The system is resilient to failures, capable of retrying and recovering automatically.
• Intelligent Data Management: LLMs are expensive, and context windows are limited. Dumping massive raw datasets into a prompt is inefficient and costly. Solace Agent Mesh includes intelligent data management that minimizes LLM compute costs by passing only relevant information to the model. This prevents hallucinations, improves the accuracy of the response, and significantly reduces token burn.
• Enterprise-Grade Operations: The platform is Kubernetes-native, meaning it aligns seamlessly with your existing DevOps, CI/CD, and GitOps workflows. It supports hot-swappable production agents, allowing you to update agent logic without downtime. Furthermore, it integrates with standard enterprise security protocols (SSO, action-level permissions, and user delegated access), ensuring that every action is authenticated, authorized, and auditable.

Open and Cloud-Agnostic

The AI landscape changes weekly. Today’s leading model today is tomorrow’s legacy tech. Locking yourself into a single cloud provider (hyperscaler) or a single SaaS vendor’s AI ecosystem is a massive strategic risk.

• No Lock-In: Solace Agent Mesh is built on an open-source core (Community Edition with Apache 2.0 license) and is fundamentally vendor-neutral. It is cloud-agnostic and SaaS-agnostic. You can deploy it on-premises, in the cloud, or across a hybrid environment.
• Ecosystem Compatibility: You can switch models—orchestrating OpenAI today and Llama tomorrow—without rebuilding your entire stack. Even more importantly, the platform allows you to preserve prior investments by reusing existing 3rd-party A2A (Agent-to-Agent) compliant agents. You can orchestrate a native Solace agent alongside a custom Python agent and a third-party service in a single, unified workflow.

A Better Way to Work: Use Cases

When you deploy a platform that meets these three criteria—easy to build, production-ready, and open—you fundamentally change how your AI operates. It allows you to unlock high-value use cases that were previously too risky or too complex to implement.

Here is what that looks like in the real world:

Conversational Analytics (Talk to Your Data)

The first hurdle for most enterprises is democratizing data access. Business users need to query complex systems—ERP, CRM, Inventory—without waiting for analyst reports.

• The Challenge: Connecting an LLM directly to a database is a security risk, and static dashboards are often outdated.
• The Solace Way: Using Gateways for preferred tools like web chat, Slack, or Microsoft Teams, a user can ask, “Give me metrics on sales by unit and revenue for this year.” The Agent Mesh intercepts this request, validates the user’s identity via the Gateway, retrieves the specific real-time data needed, and passes it to the agent for summarization. The result is democratized access to insights, governed by strict security, reducing time-to-knowledge from days to seconds.

The Event-Triggered Assistant

The next level of maturity is moving from reactive queries to proactive assistance. This requires an architecture that doesn’t just “wait” for a prompt but “reacts” to business events.

• The Challenge: Traditional AI agents often sit idle until a human prompts them. But in business, the most critical moments happen when no one is looking—a server crash, a stockout, a customer complaint.
• The Solace Way: Because Solace harnesses a real-time data platform, it enables Event-Triggered Assistants. Consider a customer service scenario: An angry email arrives. This “event” instantly triggers an agent on the Mesh. The agent drafts a response, opens a Jira ticket for the technical issue, and augments the ticket with customer data from Salesforce—all in milliseconds. This increases process efficiency and enriches data workflows without removing human oversight.

Agentic Automation (End-to-End Autonomy)

The ultimate goal for the enterprise is fully autonomous processes that eliminate manual handoffs entirely.

• The Challenge: Long-running processes are fragile. If you are automating a customer onboarding flow that involves identity verification, credit checks, and account provisioning, a failure in step 3 usually breaks the whole chain.
• The Solace Way: This requires agentic process automation. Solace Agent Mesh manages the state of these complex, multi-step workflows. It uses parallelized orchestration to verify identity and check compliance simultaneously. If the credit check API is slow, the Mesh handles the wait asynchronously. If a step fails, it retries. This capability drives straight-through processing (STP) rates, dramatically reducing operational costs and error rates and can include Human in the Loop verification.

Making Agentic AI Value More than an Illusion

We are standing at the precipice of a new era in enterprise IT.  The novelty of the chatbot is wearing off, replaced by the urgent need for operational efficiency and automated intelligence.

Enterprises need more than just a smart model; they need a foundation capable of harnessing AI agents while ensuring data is real-time, access is governed, and workflows are resilient.

Solace Agent Mesh Enterprise provides this. It connects your AI agents with everything else in your enterprise—data, tools, legacy and SaaS apps, and other agents—allowing you to stop experimenting and start orchestrating the future of your business.

Ready to Orchestrate Your AI Future?

Don’t let your AI strategy get stuck in a silo. Discover how Solace Agent Mesh can help you build, deploy, and scale the next generation of intelligent agents.

If you’re building or maintaining event-driven systems at scale, you’ve likely felt the pain of trying to map out what already exists. Applications, services, schemas and and events  running in production, but turning that into a clear, documented representation of your event-driven architecture (EDA) feels like a massive undertaking.What if you could point an AI coding assistant at your codebase and let it handle  most of that work for you?

In this walkthrough , I’ll show you how to set up the Solace Event Portal  Model Context Protocol (MCP) server with a tool like Claude Code to automatically analyze your code, identify event-driven patterns, and import your existing applications, events and schemas directly into Solace Event Portal.

Companion Videos for the Event Portal MCP Server
Setting Up with Claude
Import Existing Application Architectures

What We’re Building

By combining the Event Portal MCP Server with an AI coding assistant, you can build a workflow that:

• Analyzes your existing codebase to understand your system
• Automatically creates application domains, schemas, events, and applications in Event Portal
• Maps relationships between producers and consumers
• Generates a visual representation of your architecture
• Catalogs your applications, events and schemas to promote visibility, sharing and reuse

The process involves three main steps:

1. Setting up the Event Portal MCP Server with your MCP Client of choice
2. Using an LLM to analyze your code to find events, schemas, topics and application names
3. Giving your LLM tools a way to interact with Event Portal to create applications, events, schemas and application domains

Why Document Your Architecture in Solace Event Portal?

Event Portal gives developers tools to understand, govern and evolve event-driven systems:

• Design Tools: Visual design capabilities that help you plan and architect new features before writing code.
• Governance: Ensure your organization’s standards, naming conventions, and best practices are followed across all teams.
• Robust Cataloging: Create a single source of truth for all your events, schemas, and applications that developers can reference.
• Deployment Management: Coordinate deployments across your event mesh and manage the lifecycle of your event-driven components.
• Discoverability: Enable developers across your organization to discover and reuse existing events rather than recreating functionality.
• Visualizing & Sharing: Provide clear, visual representations of your EDA that make it easy to communicate system structure to management, enterprise architects, and new team members.
• Cross-Team Visibility: Give platform and integration teams insight into how applications are using the infrastructure they provide.

The biggest challenge? Getting your existing architecture into Event Portal. If you’ve been using Solace without Event Portal, or you’re migrating from legacy messaging technology, manually documenting everything through the GUI can take significant engineering time. The Event Portal MCP Server solves that.

Why Use the MCP Server Approach?

Traditionally,  importing architecture into Event Portal typically involves either:

1. Manual GUI Entry: Dispatch developers to manually go through the application stack and build out all components via the Event Portal interface. This is time-consuming, error-prone, and pulls developers away from feature work.
2. Custom Scripts: Build one-off import scripts that parse your codebase and documentation and add it to Event Portal via the REST APIs. This requires development effort, ongoing maintenance, and doesn’t adapt well to different codebases.
3. Event Portal Runtime Discovery + Manual Enhancement: Event Portal can perform runtime discovery on existing Solace brokers, gathering information about queues, topic subscriptions and broker configuration. This information is imported into the Event Portal where users must enhance it with publishing topics and schemas.

The Event Portal MCP Server offers a better way. By  letting your  AI coding assistant interact directly with Event Portal’s API, you can:

• Offload cognitive work to the LLM: Let AI understand your code structure, naming patterns, and event flows.
• Iterate interactively: Provide guidance and corrections as the import progresses.
• Maintain control: Review and approve changes before they’re made.
• Handle complexity: The LLM can leverage your build pipelines to better understand microservices architectures, and complex event flows.
• Adapt to your standards: Guide the AI to follow your organization’s naming conventions and topic structures by pointing to your organizations EDA and architectural guidelines.
• Enhance existing content: Leverage AI to explore your existing Event Portal content, whether added manually, via custom scripts or from an Event Portal Runtime Discovery scan, and enhance it to match your codebase, architectural guidelines and future plans.

Setting Up the Event Portal MCP Server

Prerequisites

• Solace Cloud account with Event Portal and API access
• MCP Client installed
• Your Solace API token

Installation Steps

These steps will vary, for the most up to date approach follow this Github readme.

Step 1: Export your API token

export SOLACE_CLOUD_TOKEN=your-api-token-here

**Step 2: Add the MCP server to your MCP Client

With Claude code it will be a claude mcp add command

Step 3: Launch your MCP Server and verify
claude

Inside Claude Code, type /mcp to see your running MCP servers. You should see the Solace Event Portal MCP Server listed.

Test it with a simple query:
What application domains exist?

Claude will reach out to Event Portal via the MCP server, and you’ll get a response listing your domains. You’re now ready to import your architecture.

Importing Your Existing Architecture

Crafting Your Prompt

The key to success is a well-crafted initial prompt. You’ll want to specify:

• Naming structure: How should components be named?
• Topic structure: Your organization’s topic hierarchy and versioning approach
• Human-readable names: Guidelines for creating clear, descriptive names
• Error handling: What should the LLM do when it encounters challenges?
• Scope constraints: Document only, don’t fill in gaps or make assumptions
• Domain boundaries: Whether to modify existing domains or create new ones

Example Workflow

Let’s walk through importing a credit card fraud detection architecture:

Navigate to your code directory and launch your MCP Client:
cd /path/to/your/architecture
claude

Provide your import prompt. Here’s an example structure:

Analyze this codebase and import the event-driven architecture into Event Portal.

Requirements:
- Create a new application domain for this architecture if one does not already exist
- Extract all schemas from the code and create schemas for them in event portal.
- Identify all events and their producers/consumers
- Create applications for each service
- Follow our topic naming convention: {organization}/{domain}/{event-type}/{version}/{variable}/{levels}/{as}/{required}
- Use descriptive, human-readable names
- Only document what exists - don't fill in gaps
- Link out to the relevant source code in the descriptions of objects created in event portal.
- Provide effective descriptions for all objects created.
- If you need to modify existing domains, ask for confirmation first

The codebase contains Gradle-based microservices for fraud detection.

Approve tool usage as Claude works. You’ll be prompted to approve:

• Creating application domains
• Creating schemas and schema versions
• Creating events
• Creating applications and versions

Monitor progress. Claude will report as it:

• Analyzes each service directory
• Extracts schema definitions
• Identifies event production and consumption patterns
• Creates the components in Event Portal

What Gets Created

In a typical import, you might see:

• Application Domain: A new domain for your architecture
• Schemas: JSON schemas extracted from your code
• Events: All events with their associated schemas
• Applications: Each microservice as an application
• Relationships: Producer and consumer connections wired up

Handling Issues and Edge Cases

LLMs may encounter limitations, such as:

• Character restrictions in custom attributes
• Naming conflicts with existing components
• Complex topic structures that need clarification

Your LLM will either work around these issues or ask for guidance. You can specify the exact way to handle issues in your prompt. You can also give guidance on how you want the process to be carried out and when your input is required. After the import, you can make manual adjustments in the Event Portal GUI or continue iterating with your MCP Client.

Reviewing Your Imported Architecture

Once the import completes, navigate to Event Portal and open your newly created application domain. You’ll see:

• Visual graph: Your architecture laid out visually with events (small dots) and applications (larger dots)
• Connections: Lines showing which applications produce and consume which events
• Details: All the information about schemas, versions, and configurations

The graph layout may need adjustment initially. You can refresh the layout calculation to get a cleaner view.

From here, you can:

• Continue iterating with your MCP Client to add new components
• Make manual tweaks and adjustments in the GUI
• Enforce governance policies on the imported architecture
• Use the architecture as a foundation for new feature design

Try It With Your Own Codebase

Here’s how to get started:

1. Get the MCP server: Visit https://github.com/SolaceLabs/solace-platform-mcp/tree/main/solace-event-portal-designer-mcp
2. Install and configure the Event Portal MCP server
3. Prepare your prompt with your organization’s standards and requirements
4. Start with a small architecture and test the process on a bounded domain first
5. Review, iterate and refine

What previously took days or weeks of manual documentation can now happen in minutes, with the AI handling the tedious extraction and entry work while you maintain control over the architectural decisions.

Explore More Solace MCP Servers

The Event Portal MCP server is part of a growing collection of Solace MCP servers designed to accelerate event-driven workflows. Visit the Solace Labs Github to explore other MCP servers and see what else you can automate.

Have you tried using MCP servers for your event-driven systems? Share your experience or reach out to a Solace Developer Advocate with questions.

If you would like to learn more about MCP Servers for Solace you can also check out our Office Hours on MCP Servers