Event-driven AI agent monitoring

Event-driven monitoring decouples the monitoring system from the agent's execution path. Instead of running monitoring checks synchronously on every tool call, the agent emits events that are processed asynchronously by the monitoring system.

Why event-driven

Synchronous monitoring adds latency to every tool call. For Sentinel's in-process monitoring, this is negligible (microseconds). But for external monitoring, dashboards, alerting, and log aggregation, synchronous calls add unacceptable latency.

Event-driven architecture solves this: the agent emits an event and continues. The monitoring system processes the event independently.

Event types

AI agent systems produce several event types:

| Event | Trigger | Contents | |-------|---------|----------| | action.evaluated | Every tool call | Tool name, args, decision, receipt | | action.blocked | Blocked tool calls | Tool name, args, reason | | action.escalated | Escalated tool calls | Tool name, args, approval request | | threat.detected | Aegis finds a threat | Threat type, score, snippet | | anomaly.detected | Sentinel flags anomaly | Metric, expected, observed | | session.started | New agent session | Session ID, principal | | session.terminated | Session ends or killed | Session ID, reason |

Architecture

[Agent] → guard() → [Event Emitter] → [Message Queue] → [Consumers]
           ↓                                               ↓
        Tool call                                    [Alert Router]
        continues                                    [Dashboard]
                                                     [Log Storage]
                                                     [Auto-Response]

The agent is never blocked by the monitoring system. If the message queue is slow or down, the agent continues operating. Events are buffered and processed when the queue recovers.

Implementation

const guard = createGuard({
  policy,
  events: {
    emit: async (event) => {
      await messageQueue.publish('agent.events', event);
    }
  }
});

Event consumers

Alert router

Filters events and routes alerts to the right team:

consumer.on('anomaly.detected', (event) => {
  if (event.severity === 'critical') {
    pagerduty.trigger(event);
  } else {
    slack.post('#agent-alerts', event);
  }
});

Dashboard aggregator

Aggregates events into metrics for real-time dashboards:

consumer.on('action.evaluated', (event) => {
  metrics.increment('actions.total', { tool: event.tool, action: event.decision });
});

Auto-response

Automatically responds to certain event patterns:

consumer.on('anomaly.detected', (event) => {
  if (event.metric === 'denial_rate' && event.observed > 0.5) {
    // More than 50% of actions blocked: kill the session
    controlPlane.killSession(event.sessionId);
  }
});

Message queue options

Any message queue works:

• Redis Streams: Simple, low-latency, built into most stacks
• Apache Kafka: High throughput, durable, good for large deployments
• AWS SQS/SNS: Managed, no infrastructure to run
• NATS: Lightweight, high performance

Choose based on your existing infrastructure. Do not add a message queue just for agent monitoring if you do not already have one. Start with Sentinel's in-process monitoring and add event-driven architecture when you need external consumers.