Single-agent monitoring is a solved problem in the same way single-host monitoring is solved: collect events, filter by severity, alert on anomalies. The patterns are well-understood and the tooling is mature. Multi-agent workflows are different in a structurally important way: the behavior that matters most often lives at the handoff points between agents, not inside any individual agent's session.
I spend most of my time thinking about event streaming and anomaly detection pipelines for infrastructure, and the challenge of instrumenting multi-agent workflows maps closely onto the challenge of instrumenting distributed microservices. The individual service logs are necessary but not sufficient. You need a correlation layer that reconstructs what happened across service boundaries to see the full picture. The same principle applies to agent workflows, with a few AI-specific complications.
The Boundary Problem
Consider a document review workflow: a coordinator agent receives a contract submission and dispatches it to three parallel sub-agents: a clause extraction agent, a risk assessment agent, and a party identification agent. Each sub-agent produces a structured output that the coordinator synthesizes into a review summary.
If you monitor only at the individual agent level, your logs show each agent receiving an input and producing an output. Normal. What your logs do not show is what happened at the moment the coordinator passed the contract to each sub-agent: specifically, whether the coordinator included context in the dispatch that it should not have. A coordinator with broad access might pass authorization tokens or session context to sub-agents that the sub-agents did not need for their specific tasks. From inside each sub-agent's log, this is invisible. The coordinator's log shows it dispatched work. The sub-agent logs show they received work and processed it. The excess context transfer is in the handoff, not captured by either log.
This is the boundary problem: the events at agent handoffs are where policy-relevant behavior often surfaces, and they are precisely what per-agent logging does not capture.
Trace ID Propagation Across Agents
The foundational pattern for multi-agent monitoring is the same as for distributed tracing: a trace ID that propagates through the entire workflow, from the originating user request through every agent invocation, sub-invocation, and tool call.
In practice, this means: when the user submits the contract for review, a trace ID is generated and associated with that request. When the coordinator agent is invoked to handle the request, it receives the trace ID and includes it in every dispatch to sub-agents. Every tool call any agent makes during the workflow carries the trace ID. Every event logged carries the trace ID.
With trace ID propagation, you can pull all events for a single workflow execution and see them in sequence: coordinator receives input at T+0, dispatches to clause-extractor at T+1, clause-extractor calls document-parse tool at T+2, document-parse tool accesses the document store with credential X at T+3, and so on. Without trace IDs, you have a pile of individual events that happened around the same time, correlated manually by timestamps and agent names. That is fine for a low-volume workflow. It does not work when you have fifty concurrent workflow executions running.
Event Schema Design for Agent Workflows
The event schema that works for infrastructure monitoring needs a few extensions to work for agent monitoring. The core fields are the same: timestamp, event type, source identifier, severity, outcome. The extensions are about capturing the agent-specific context that makes the events interpretable.
Required additional fields: agent type and version (not just agent ID, because the same agent type may have multiple running instances), session ID (the ID of this specific agent invocation within the larger workflow), trace ID (the workflow-level correlation ID), invoked by (which agent or system initiated this session), tool name (for tool call events), credential ID used (so you can trace access back to specific credentials), resource target (what data or API was accessed), and policy outcome (whether the action was permitted, blocked, or flagged by the policy engine).
The policy outcome field is worth calling out specifically. Without it, you have an observation layer but not an enforcement layer in the event stream. With it, every event carries its own policy verdict, which means you can do real-time analytics: how many tool calls per workflow are flagging policy conditions? What is the ratio of permitted to blocked actions over time? Is a particular agent type generating anomalous policy flag rates?
Anomaly Detection Patterns Specific to Agent Workloads
The anomaly detection patterns that work for infrastructure logs need adjustment for agent workloads because the statistical behavior of agent activity is different from the statistical behavior of service-to-service API traffic.
Tool call velocity per session. A single agent session that makes an unusually high number of tool calls compared to the baseline for that agent type is worth flagging. In infrastructure terms, this is analogous to request rate anomaly detection. The baseline will differ significantly by agent type: a data extraction agent has a higher expected tool call rate than a classification agent. Baselines need to be per agent type, not global.
Novel resource access within a session. If an agent session accesses a resource type or specific resource that it has not accessed in any of its last N sessions, and that the agent type has never accessed in production, flag it. This is the agent equivalent of anomalous lateral movement in network security: the agent is reaching something it has not previously reached. Most of the time this is benign (a new document type, a new API endpoint being tested). Occasionally it represents a tool call sequence that the agent was not supposed to be able to execute.
Context bleed across sessions. An agent that should be stateless between workflow invocations but appears to carry information from a previous session is a signal worth catching. In practice, this shows up as an agent accessing a resource that is only reachable given knowledge from a previous session's output. This is subtle to detect in real time, but a pattern worth developing detection logic for if your workflow involves agents that process sensitive customer data.
Cross-agent data flow anomalies. In a workflow where agent A's output is supposed to feed into agent B, and agent B should not have direct access to the data sources agent A used, any event where agent B accesses those sources directly (not through agent A's output) represents a workflow deviation. Catching this requires having a model of the intended data flow topology for each workflow type, which is additional instrumentation overhead, but worth it for high-sensitivity workflows.
Alert Routing for Multi-Agent Events
The challenge with alert routing in multi-agent workflows is that a single policy violation at the sub-agent level may or may not be significant depending on the coordinator's behavior. A sub-agent flagging a blocked tool call is a notable event. Whether it requires immediate incident response or just a policy review depends on: Did the coordinator retry with a different agent? Did the blocked call prevent the workflow from completing? Did the user receive an incorrect result because the blocked call was substituted with an unblocked but less-appropriate action?
This means alert routing for multi-agent workflows should be workflow-aware, not just agent-aware. An alert that is categorized as P3 (policy flag, review within 24 hours) for a single blocked tool call should be automatically re-evaluated as P1 (active incident) if the same trace shows subsequent policy flags across multiple agents in the same workflow. Escalation logic based on trace-level event aggregation, not just individual event severity, is the pattern that matches the risk model of coordinated agent behavior.
The Tooling Gap
Most observability platforms have not caught up to multi-agent workflows. Distributed tracing tools like Jaeger or OpenTelemetry are designed for services with well-defined request/response cycles. Agent workflows have longer, more variable execution patterns, and the events are semantically richer (a tool call has meaning beyond its latency and outcome code). Application performance monitoring tools focus on system performance metrics, not behavioral policy.
The practical implication is that agent workflow monitoring requires a purpose-built event pipeline, or significant customization of existing tools. At a minimum, you need: a collector that understands agent framework event formats (LangChain, AutoGen, and CrewAI all emit different event structures), a storage layer with efficient querying by trace ID, and a policy evaluation engine that can classify events against your defined agent permissions in real time.
We built the Arrakis monitoring layer specifically because the general-purpose observability stack did not map well onto this problem. That does not mean it is the only approach. Teams with mature Kafka-based event pipelines can extend them to handle agent events effectively. The point is that treating agent workflow monitoring as "just add another log source to your SIEM" misses the structural requirements of trace-level correlation and real-time policy evaluation that make multi-agent monitoring actually useful.
Starting with the Boundary Events
If you are beginning to instrument a multi-agent workflow and cannot instrument everything at once, start with the boundary events: agent dispatch calls (coordinator to sub-agent handoffs) and tool calls that touch sensitive resources. Those two event types give you the highest signal density relative to instrumentation overhead. You can build out the full trace-correlated picture incrementally once the boundary events are flowing.
Audit your AI agents with Arrakis.
Arrakis gives security and platform teams a complete audit trail of every action your AI agents take, with policy enforcement that stops overreach before it reaches your data.
Request a Demo