Agent-to-Agent Discovery in SMESH: Why Coordination Isn't Enough Without Runtime Introductions

You can build a working agent mesh with QUIC transport, encrypted messaging, and decentralized coordination. Five processes can reinforce independent conclusions and let unsupported signals decay. The mesh works. Then you try to introduce it to another agent and discover you have no standard way to ask what the swarm can do. No retained task to retrieve after an internal signal expires. No interoperable progress stream. No cancellation contract. No artifact another framework would understand. SMESH is a Rust-based decentralized agent framework that hit this boundary. The author had built a society with no border crossing. The solution was Google's Agent2Agent (A2A) protocol, announced in April 2025 and moved under Linux Foundation governance in June 2025. A2A provides the missing public contract: a way for agents built by different vendors to discover one another, exchange messages, and collaborate without sharing private memory, tools, or internal plans. The Cold-Start Problem in Agent Meshes Traditional service meshes solve discovery with a central registry. Kubernetes has etcd. Consul has its catalog. Envoy has xDS. You register your service, get a DNS name or IP, and other services find you. This works because services are relatively static and the registry is the source of truth. Agent meshes are different. Agents are ephemeral, context-dependent, and often spawned on demand. They need to: - Discover peers without a central registry - Exchange capability metadata at runtime - Negotiate protocols without pre-shared configuration - Maintain security boundaries during introduction The coordination primitives (message passing, consensus, signal decay) assume agents already know about each other. Discovery is the layer below coordination. SMESH had the top layer working but no way to bootstrap the bottom layer without manual wiring. What A2A Provides A2A is not a coordination protocol. It is an introduction protocol. The spec defines: - Discovery handshake: How agents announce themselves and query peer capabilities - Capability exchange: Structured metadata about what an agent can do (tasks, inputs, outputs) - Message envelope: Standard format for task requests, progress updates, cancellations, and results - Security boundary: Agents expose capabilities without revealing internal state, tools, or memory This maps to the HTTP layer in microservices, not the application layer. A2A is the contract that lets heterogeneous agents talk. What they say after introduction is up to them. SMESH Architecture Before A2A SMESH uses a decentralized coordination model: - QUIC transport: Encrypted, multiplexed connections between agent processes - Signal propagation: Agents broadcast observations and reinforce conclusions from peers - Decay mechanism: Unsupported signals lose weight over time - No central orchestrator: Coordination emerges from peer interactions The missing piece was the gateway layer. Agents inside the mesh could coordinate. Agents outside the mesh had no entry point. The author describes this as "a society with no border crossing." Adding the A2A Gateway The implementation added a tested gateway layer that: - Exposes A2A-compliant discovery endpoints - Translates A2A task requests into SMESH internal signals - Maps SMESH coordination state to A2A progress updates - Handles cancellation by injecting decay signals The gateway is not a proxy. It is a protocol adapter. Internal agents still use QUIC and signal propagation. External agents use A2A. The gateway translates at the boundary. Discovery Flow Here is how an external agent discovers and tasks a SMESH mesh: - Capability query: External agent sends A2A discovery request to gateway - Gateway response: Returns aggregated capabilities from internal agents (tasks, input schemas, output schemas) - Task submission: External agent sends A2A task request with inputs - Internal translation: Gateway converts task to SMESH signal and broadcasts to mesh - Coordination: Internal agents reinforce or decay the signal based on their observations - Progress streaming: Gateway polls internal state and emits A2A progress updates - Result or cancellation: Gateway returns final result or handles cancellation via decay injection The gateway maintains no task state. It is a stateless translator. Task retention happens inside the mesh via signal persistence. Security Boundaries A2A enforces separation between public and private state: | Layer | Exposed | Hidden | |---|---|---| | Capabilities | Task names, input/output schemas, supported protocols | Tool implementations, internal prompts, model weights | | Task state | Progress percentage, status enum, public artifacts | Internal signals, peer votes, decay timers | | Coordination | Final consensus result | Signal propagation graph, reinforcement weights | | Transport | A2A HTTP/JSON or gRPC | QUIC connections, encryption keys, peer topology | The gateway is the trust boundary. Internal agents trust each other (authenticated via QUIC). External agents trust only the gateway's A2A contract. Testing Discovery Without Flaky Timing The author mentions the gateway is tested but the six-organization incident is a deterministic simulation. This is the right approach. Testing decentralized discovery is hard because: - Timing dependencies cause flakes (agent A discovers agent B before agent C) - Network partitions are non-deterministic - Signal decay depends on wall-clock time The solution is to separate gateway tests from mesh tests: Gateway tests (deterministic): - Mock internal mesh state - Verify A2A request/response contracts - Test cancellation translation - Validate schema mappings Mesh tests (simulation): - Inject deterministic signals - Advance virtual time - Verify coordination without external A2A layer This keeps the A2A boundary testable without requiring a full mesh spin-up. What Is Still Missing The author notes several gaps: - Task retention: No way to retrieve a task after its internal signal expires - Interoperable progress stream: A2A progress updates exist but are not standardized across meshes - Cancellation contract: Decay injection works but has no formal cancellation guarantee - Artifact persistence: Results are ephemeral unless an agent explicitly stores them These are not A2A problems. They are mesh-level design questions. A2A provides the introduction layer. What happens after introduction is still framework-specific. Implementation Sketch Here is a simplified Rust sketch of the gateway's task submission handler: async fn handle_a2a_task( req: A2ATaskRequest, mesh: Arc , ) -> Result { // Validate task against published capabilities let capability = mesh.get_capability(&req.task_name) .ok_or(A2AError::UnknownTask)?; capability.validate_inputs(&req.inputs)?; // Convert A2A task to internal signal let signal = Signal { task: req.task_name.clone(), inputs: req.inputs.clone(), weight: 1.0, timestamp: Instant::now(), }; // Broadcast to mesh (non-blocking) let signal_id = mesh.broadcast(signal).await?; // Return task handle (gateway does not block) Ok(A2ATaskResponse { task_id: signal_id.to_string(), status: A2AStatus::Accepted, progress_url: format!("/a2a/tasks/{}/progress", signal_id), }) } The gateway does not wait for coordination. It translates the request, broadcasts the signal, and returns a handle. Progress polling is a separate A2A endpoint that queries mesh state. Comparison to Service Mesh Discovery | Aspect | Service Mesh (Envoy/Consul) | Agent Mesh (SMESH + A2A) | |---|---|---| | Registry | Central (etcd, Consul catalog) | Decentralized (peer broadcast) | | Discovery timing | Pre-deployment registration | Runtime introduction | | Capability schema | Static (Kubernetes Service spec) | Dynamic (A2A capability exchange) | | Security model | mTLS + RBAC | A2A boundary + QUIC auth | | State retention | Service endpoints persist | Signals decay over time | | Failure mode | Registry outage breaks discovery | Mesh degrades gracefully | Service meshes assume long-lived services with stable identities. Agent meshes assume ephemeral participants with dynamic capabilities. A2A bridges the gap by providing a stable introduction protocol over an unstable mesh. Likely Failure Modes Gateway becomes a bottleneck: If all external requests funnel through one gateway, it becomes a SPOF. Solution: run multiple gateways with shared mesh access. Capability drift: Internal agents add new tasks but gateway cache is stale. Solution: gateway polls mesh capabilities periodically or subscribes to capability change signals. Signal flooding: Malicious external agent submits thousands of A2A tasks. Solution: rate-limit at gateway, require authentication, or use proof-of-work for task submission. Cancellation race: External agent cancels task but internal signal has already produced a result. Solution: treat cancellation as best-effort, return result if available. Schema mismatch: A2A input schema does not map cleanly to internal signal format. Solution: validate at gateway, reject incompatible requests early. Technical Verdict Use A2A discovery when: - You have a working agent mesh with internal coordination but no external interface - You need to interoperate with agents from other frameworks or vendors - You want a tested, standard protocol instead of inventing your own RPC layer - You can tolerate eventual consistency (signals may decay before external agent sees result) Avoid A2A discovery when: - You need strong consistency guarantees (A2A is best-effort over a decentralized mesh) - Your agents are tightly coupled and do not need runtime introduction - You already have a working service mesh and agents are just another service type - You need sub-millisecond task dispatch (A2A adds translation overhead) A2A solves the cold-start problem for decentralized agent meshes. It does not solve coordination, state retention, or artifact persistence. Those are mesh-level concerns. A2A is the border crossing, not the immigration policy. Top com