When Multiple AI Agents See One Vehicle Differently

The Federated Context Challenge in AI Agent Coordination

In context engineering, Semantic Divergence is the primary obstacle to multi-agent coordination. Take Vehicle-123, a standard delivery van. To the various AI agents reasoning about it, the vehicle exists across multiple independent contexts, and these contexts rarely align. This isn't a bug; it's a structural failure in context architecture.

The Trinity of Entities: Physical, Person, and Temporal

Effective context engineering must account for three interlocking entity types:

1. Physical (The Vehicle): Hardware state, location, and diagnostics.
2. Person (The Driver): Duty status, certifications, and real-time availability.
3. Temporal (The Journey): Ephemeral lifecycles (like a delivery route) that track "work in progress" rather than permanent objects.

Coordination fails when these are siloed. If Dispatch thinks the driver is assigned to Vehicle-123 on Journey-456, but the Insurance agent's context shows the vehicle as "Idle," the agents cannot collaborate effectively.

Operational Divergence: A Case Study in Contextual Fragmentation

Each agent maintains independent context updated at different temporal resolutions:

• The Asset Management Agent: Tracks the vehicle as a capital asset (TCO, lease utilization, and residual value projections). It typically updates on a monthly cycle.
• The Dispatch Agent: Sees an active resource assigned to Sarah on Journey-456. It updates continuously.
• The Maintenance Agent: Monitors health (mileage since last service and specific diagnostic codes). It updates daily.
• The Insurance Agent: Calculates risk (driver patterns and route-specific hazard probability). It updates weekly.
• The Telematics Agent: Streams raw data (GPS and sensor readings). It updates in real-time.

At 10:15 AM, Vehicle-123 runs over a spike, causing an immediate drop in tire pressure. Telematics flags the event instantly. However, Dispatch observes the stop but assumes the driver is taking a break. Asset Management won't see this impact on "asset health" until the next reporting cycle.

Without a shared grounding layer, resolving this becomes context archaeology, an expensive, manual reconstruction of "truth" from disconnected systems.

The Solution: A Three-Layer Federated Context Architecture

We solve this by separating Shared Grounding from Private Reasoning.

The Context Layer Map

Grounding the Coordination
The Operational State layer is the "Common World Model". When the flat tire occurs, the event "Vehicle-123: Disabled" propagates immediately to the shared layer. Because the Journey and the Driver are linked to that vehicle, their statuses update to "Paused" and "On-Site" respectively. Every agent sees the same state change at the same timestamp.

Engineering Considerations

• Event-Sourced Context: Engineer context as a stream of immutable events. This ensures a definitive audit trail for causality and compliance.
• Latency vs. Consistency: Not all agents need real-time updates. Use reactive subscriptions so agents only consume updates relevant to their specialized reasoning.
• The Boundary Rule: If disagreement indicates a data error (e.g., location), it belongs in the Operational State. If it is a matter of interpretation (e.g., risk), it belongs in Relationship Context.

Summary: Designing for Federated Context

To move from siloed agents to a coordinated system, engineers should:

1. Define the Shared Layer: Identify the minimum set of "observable facts" (location, status, assignments) required for all agents to stay grounded.
2. Decouple Reasoning from State: Ensure agents publish their decisions (e.g., "Assigning Driver") as state changes to the shared layer, rather than keeping the result private.
3. Implement Temporal Audit Trails: Use event-sourcing to allow any agent to query the state of an entity (Vehicle, Person, or Journey) at any specific point in time.

Tom Foster explores context engineering patterns for AI agent coordination.