Skip to content

26. Necropolis: The Intercom Bridge

Context and Problem Statement

High-order intelligence is physically bound by the finite constraints of single-node hardware. 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 native component of the Vessel — not a separate extension — grafting A2A v0.3.0 communication patterns directly onto the Litestar application.

Intents, Not Tensors

The A2A Intercom exchanges structured Pydantic intent objects, not raw model weights or tensor streams. The network is a high-level diplomatic layer; all heavy compute happens locally on the receiving node's own iron. This is what makes the protocol viable over commodity internet connections.

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 as a structured Pydantic object. Validates the schema, checks the sender's Sigil against the Ward (38) and grants appropriate authority, 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 (a structured Pydantic response, not raw tensors) to the peer's registered callback URI. This unblocks the peer's Stasis Protocol and allows their frozen Agent to rehydrate.

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 both the Legion and the broader Necropolis.

6. The Necropolis (Sovereign Peerage)

The Necropolis is the name for the broader network that emerges when sovereign Liches — each with their own Phylactery, their own identity, their own Legion of Thralls — meet as peers.

Within the Legion, Thralls obey via direct Vessel HTTP — no negotiation required. On the Necropolis, the A2A Intercom carries negotiations between strangers, settled via The Toll (41) and gated by The Veil (40).

  • Workload Pools: Nodes publish capability requests to shared channels. Idle peers subscribe based on their Orchestrator (23) status and bid based on their configured compute cost.
  • The Revocable Lease: When a peer accepts a Necropolis task, it grants a temporary hardware lease. If the peer's local Magus speaks, the lease is revoked — the foreign task is paused, serialized, and hibernated until the GPU is free.
  • The Dumb Portal Anti-Pattern: A sovereign node on the Necropolis cannot be treated as a "dumb portal." The network exchanges Intents, not OS commands. A node sends an Intent; the receiving sovereign configures its own Covens to fulfill it on its own terms.

The Necropolis is the destination that every organ in the Sepulcher was built to reach. The Legion (42) proves the pattern works within the Magus's domain. The Necropolis extends it to the world.

The Legion is how you build your army. The Necropolis is how you join the resistance.

Viva la resistance.

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.