Agent Registry

The registry acts as a real-time phonebook for the fleet. When an agent boots up, it registers its network endpoint and capabilities. Consumers, like a Task Decomposition Engine, query the registry to discover available agents without needing hardcoded addresses. This enables a truly plug-and-play architecture where agents can join or leave the mesh dynamically.

• Eliminates static configuration files
• Supports DHCP and transient network topologies
• Often backed by strongly consistent data stores like etcd or Consul

Beyond static identity, the registry maintains the current operational state of every agent. This is a finite state machine with well-defined transitions, such as IDLE, EXECUTING, CHARGING, ERROR, or OFFLINE. The registry is updated via heartbeat mechanisms and status reports, providing a real-time digital shadow of the physical fleet.

• Enables Fleet State Estimation
• Critical for Dynamic Task Allocation decisions
• Stale entries are purged based on a Time-To-Live (TTL) policy

The registry stores a structured, queryable manifest of each agent's static capabilities and dynamic attributes. This includes maximum payload, sensor payloads, supported navigation modes, and physical dimensions. Orchestrators use this index to filter agents suitable for a specific task.

• Example: SELECT agent_id FROM registry WHERE max_payload_kg > 500 AND has_conveyor = true
• Uses semantic tagging for heterogeneous fleets
• Enables Capability Discovery workflows

The registry is the authoritative source for agent health. It consumes a continuous stream of heartbeat signals and diagnostic telemetry. A missed heartbeat deadline triggers an automatic status transition to UNRESPONSIVE, which in turn alerts the Exception Handling Framework. This is the foundation for fleet health monitoring.

• Implements a Circuit Breaker pattern for unresponsive agents
• Distinguishes between DEGRADED and CRITICAL health states
• Feeds data into Fleet Health Monitoring dashboards

In a heterogeneous fleet, agents run different firmware and software versions. The registry stores version vectors and supported protocol schemas for each agent. Before dispatching a command, the system checks the registry to ensure the agent's Protocol Adapter version is compatible, preventing runtime errors.

• Stores Agent Driver version numbers
• Validates against a central Schema Registry
• Prevents command dispatch to incompatible agents

To function as a reliable control plane, the registry must provide strong consistency guarantees. It is typically implemented using a consensus algorithm like Raft to replicate state across multiple nodes. This ensures that in the event of a node failure, the registry remains available and no stale or conflicting data is served.

• Prevents split-brain scenarios in the Control Plane
• Uses distributed locks for write operations
• Provides a linearizable read model for accurate scheduling