Agent-to-Agent Event Mesh
Consent-based WebRTC links for selected events across independently operated Banalytics Agents.
A distributed edge system should share operational outcomes without turning every site into a public endpoint or a transparent message transit network. Agent Connector gives two approved Agents a direct WebRTC event channel while the Banalytics portal controls who may establish each route.
Need selected events to cross an organisational or site boundary?
Describe the Agents, owners, event contract and network constraints. We will help identify the smallest route topology that preserves local autonomy.
Share outcomes, not entire edge systems
Each Banalytics Agent owns its local devices, tasks, files, rules, dashboards, and recovery behaviour. That boundary is valuable: a remote network outage should not stop a camera recorder, Modbus poller, or local safety response. Some outcomes still need to cross the boundary-for example an alarm produced at a remote site, a calculated measurement required by a mobile platform, or an equipment state used by a central operations Agent.
Agent Connector adds a narrow event path between two Agents. The source decides which events leave through Event Manager and Forward Event To Consumer. The receiver republishes them into its local event bus with their remote identity preserved, allowing local rules and history to act on them without pretending the two Agents are one runtime.
The portal approves the signalling route
The portal route is an authorization record, not a data proxy. Its source is the designated Initiator; its target is the Listener. For different accounts, both owners take an explicit action: the Initiator owner requests the route and the Listener owner confirms it. Until the route is ACTIVE, the portal refuses to relay the WebRTC Ready, Offer, Answer, and ICE messages for that pair.
| Route state | Meaning | Connection effect |
|---|---|---|
| PENDING | The source owner requested a cross-account link; the target owner has not decided. | No Agent-to-Agent signalling is relayed. |
| ACTIVE | Both owners approved, or one account owns both Agents. | The pair is selectable in Agent Connector and signalling is allowed in the declared direction. |
| DECLINED | The Listener owner rejected the request. | The route cannot be used; a new request requires resolving the existing record. |
| Deleted | Either owner revoked the relationship. | New signalling is blocked and the peer disappears from configuration lists. |
The portal derives the sender Agent UUID from its authenticated WebSocket session. Agent Connector therefore does not exchange a shared component password. The receiving Agent also checks that an incoming link names the configured peer.
Signalling is centralized; event delivery is peer to peer
- The Initiator announces readiness. Its connector periodically sends Ready while the link is down.
- The portal checks the route. It verifies ACTIVE status, direction, and the route signalling budget before relaying the message.
- The Listener creates the offer and events channel. Its delivery setting defines ordering and retransmission behaviour.
- Offer, Answer, and ICE candidates cross the authenticated portal sessions. STUN/TURN configuration may remain local or be deliberately provided by one peer.
- The WebRTC data channel opens directly. Heartbeats, events, and link statistics then use that channel; the portal does not carry the event payload.
Build explicit edges, not an implicit relay cloud
| Pattern | Use | Important boundary |
|---|---|---|
| Point to point | One field Agent shares selected states or alarms with one receiving Agent. | Smallest consent and troubleshooting surface. |
| Hub and spokes | Several site Agents forward selected outcomes to an operations Agent. | The hub processes each inbound stream locally; it is not a transparent transit router. |
| Purpose-built mesh | Agents have direct links only to the peers that require their event contract. | Every edge needs its own route, two connector instances, monitoring, and revocation owner. |
| Cross-organisation link | A customer, supplier, research partner, or service operator shares a narrow operational result. | Cross-account activation always waits for the Listener owner's confirmation. |
Events received through an Agent link are not automatically forwarded into another Agent link. This loop barrier prevents accidental cycles and broadcast storms. If a receiving site needs to publish a derived outcome, create a new local event with an explicit contract and route that result deliberately.
Decide what is allowed to cross the link
- Send final or aggregated outcomes. Prefer alarm transitions, calculated measurements, accepted detections, and health changes over frames or raw high-frequency samples.
- Keep stable identity. Consumers should be able to distinguish source Agent, component, event type, key, unit, quality, and source time.
- Choose delivery semantics deliberately. Reliable ordered delivery suits state transitions; unordered reliable delivery avoids head-of-line blocking; limited modes suit data that becomes useless when stale.
- Define side effects at the receiver. A relayed event may trigger notifications, recording, or device actions. Filter by source and test failure/reconnect behaviour before enabling production actions.
- Record the contract, not every transport detail. Event History can retain selected remote outcomes and link-state events for audit and troubleshooting.
Make ICE server ownership explicit
Each peer normally uses its Agent-wide STUN/TURN list. For a relationship that needs a dedicated relay or shared configuration, one connector can use PROVIDE and the other CONSUME. Credentials may be stored through Secret Manager references instead of being copied into plain configuration.
A successful portal route does not guarantee a viable peer network path. Test direct connectivity, TURN fallback, firewall policy, reconnect time, packet loss, and latency from the actual sites. If the link carries control-relevant state, the receiving system must retain safe local behaviour when the channel disappears.
Monitor and revoke the relationship as one change
The Agent Connector panel exposes WebRTC state, current role and peer, RTT, heartbeat loss, message counters, and recent errors. State transitions are also events, so a site can record availability or notify an operator without polling the panel.
- Create and approve the portal route.
- Configure and start the Listener, then the Initiator.
- Verify the expected direct or TURN-assisted path and observe heartbeat metrics.
- Forward one harmless test event and confirm its remote identity and rule behaviour.
- Enable the bounded production event set and record link-state changes.
- When access ends, delete the portal route and stop or remove both connector Things.
This white paper is based on the implementation and the original Agent Connector use-case description.