Skip to content

26. Necropolis: Native Agent Intercom

Context and Problem Statement

High-order intelligence is physically bound by the finite constraints of single-node hardware. While cognitive expansion necessitates distributed resources, traditional GPU clustering (Kubernetes/Slurm) fails due to extreme interconnect costs and the paralyzing latency of network jitter. This creates a state of "Distributed Solitude." The machine requires a mechanism to trade labor and share context with other sovereign nodes without surrendering local authority or deterministic resource control. The challenge lies in establishing a decentralized architecture that supports the "Long Sleep"—the ability for thoughts to span network boundaries and survive high-latency rituals.

Requirements

  • RFC 8615 Discovery: Mandatory implementation of the /.well-known/ path prefix to facilitate autonomous peer discovery.
  • Identity Transparency: Adoption of the agent-card.json standard (A2A v0.3.0) to exchange public Sigils and cognitive capabilities.
  • Asynchronous Handshake: Support for the "Long Sleep"—suspending a reasoning ritual and returning a 202 Accepted status while high-latency labor is performed by a peer.
  • Native Substrate Alignment: Mandatory integration with the system's native Vessel (11), Phylactery (06), and Ghouls (14).
  • Type-Safe Sovereignty: Reliance on native Python type hints and Pydantic models as the definitive contract for all cognitive labor.
  • Resource Lease Enforcement: Mandatory integration with the physical arbiter to ensure incoming swarm requests are subject to revocable hardware leases.
  • Context Preservation: Utilization of a unified context_id to ensure multi-turn negotiations maintain a coherent reasoning history across the Legion.

Considered Options

Option 1: Model Context Protocol (MCP)

Utilizing the MCP standard to connect models to data. - Cons: Functional Reduction. MCP is designed for connecting "Models to Tools." It treats capabilities as stateless functions. In LychD, Agents are not Tools; they are stateful, autonomous entities that require multi-turn negotiation and asynchronous handshakes, which MCP cannot sustain.

Option 2: FastA2A / UTCP (Middleware Tax)

Utilizing the FastA2A library or a separate Universal Tool Calling Protocol. - Cons: Architectural Bloat. FastA2A brings its own Starlette-based server and volatile memory broker. This creates "Grafted Tissue" that duplicates the Vessel's Litestar logic and the Ghouls' SAQ queue. UTCP introduces a "Translation Tax," converting Pydantic models into intermediate JSON schemas, increasing entropy and hallucination risk.

Option 3: Native Litestar Intercom (A2A Specification)

Implementing the A2A v0.3.0 specification as a native Extension using the existing Litestar and SAQ substrate. - Pros: - Zero-Dependency Purity: Leverages the Vessel's existing high-performance router and the Phylactery's persistent task queue. - Pydantic Sovereignty: The tool definitions scried in the Dispatcher (22) are sent directly over the wire without translation. - Long Sleep Support: Natively uses Pydantic AI's call_deferred to hibernate threads while remote nodes labor.

Decision Outcome

The A2A Intercom is adopted as the native network of the machine. It is implemented as a sovereign Extension that grafts the A2A v0.3.0 communication patterns onto the Litestar Vessel.

1. The Intercom Router (The Bridge)

The extension registers a dedicated Litestar Router mounted at /a2a. It handles the core JSON-RPC methods defined by the A2A specification:

  • message/send (The Ingress): Accepts a cognitive intent. It validates the Pydantic schema, enqueues a Ghoul (14) in the queue chamber, and returns 202 Accepted with a Task ID.
  • tasks/get: Allows peers to poll for the status of a long-running ritual.
  • The Callback (The Egress): Once the local Ghoul completes the work, the Intercom uses httpx to deliver the resulting Artifact to the peer's registered callback URI.

2. Sovereign Discovery (RFC 8615)

To facilitate peerage within the Legion (42), the node serves its identity via the standard "Well-Known" URI:

  • /.well-known/agent-card.json (The Passport):
    • Identity: Public Sigil and active Personas.
    • Skills: A manifest of agents and their Pydantic schemas, sourced from the Dispatcher's registry.
    • Economics: The Tithe requirements for labor, as defined in Economics (41).

3. The Pydantic Covenant

The Intercom rejects all mundane middleware (UTCP).

  • Type-to-Type: Communication between Liches is a direct exchange of Pydantic models.
  • Stasis Handshake: When the Dispatcher resolves an intent to a remote peer, it triggers a call_deferred event. The Intercom serializes the intent, signs it with the local Sigil, and manages the network transport.

4. The Warden's Lease

Every incoming swarm task is treated as unprivileged labor.

  • Resource Lease: The Orchestrator (23) grants a temporary hardware lease to the swarm task.
  • Preemption: If the local Magus initiates a reflex (e.g., Voice), the Orchestrator revokes the lease. The swarm-ghoul is paused, its state is persisted to the Phylactery, and the GPU is reclaimed.

5. Extension Freedom

While A2A provides the standard for agentic communion, the architecture remains open. Extensions are free to mount raw Litestar routes or alternative protocols (e.g., WebSockets for streaming) as needed. The Intercom serves as the high-level diplomatic layer for the swarm.

Consequences

Positive

  • Substrate Integration: Utilizing SAQ and Postgres ensures that swarm tasks are as resilient and persistent as local tasks.
  • Latency Optimization: Bypassing intermediate protocols (UTCP) eliminates the serialization overhead for complex data structures.
  • Sovereign Security: The Intercom is a standard router, meaning it is automatically protected by the Proxy (40) and gated by the Ward (38).

Negative

  • Implementation Burden: Eschewing libraries like FastA2A requires the manual implementation of the A2A JSON-RPC state machine within the extension.
  • Protocol Sensitivity: The node is strictly bound to the A2A versioning; breaking changes in the specification require synchronized updates across the Federation.