Show & Tell: Inside the Deployment Module — FastAPI Servers, MCP SSE, Kenny Graph, and 89K-Node Live Cluster

[web3guru888]

The Part No One Talks About: How ASI:BUILD Actually Runs

Most AGI framework posts are about model architectures and training algorithms. This one is about the unglamorous but critical question: how do you actually run 29 cognitive modules in a live deployment?

ASI:BUILD's servers module answers that — and the implementation is more interesting than you'd expect.

---

What's in the module (src/asi_build/servers/)

The servers module provides:

• FastAPI-based REST + WebSocket endpoints for all major module operations
• Model Context Protocol (MCP) with Server-Sent Events (SSE) for streaming agent-to-agent communication
• Kenny Graph live access — 89,574 nodes, 1,405 active agents served over MCP
• Async task management with priority queues and backpressure handling
• Health probes for liveness/readiness (Kubernetes-compatible)
• Multi-tenant isolation — each cognitive cycle instance gets its own namespace

---

The MCP Transport Design

One of the more interesting decisions was choosing MCP over raw WebSockets or gRPC for inter-module communication. Reasons:

1. Structured tool calling — MCP's tool schema maps naturally onto module operations
2. Bidirectional streaming — SSE lets the server push updates; tool calls let clients pull
3. Discoverable — any LLM-powered client can auto-discover available module operations via the MCP manifest
4. External agent compatibility — SingularityNET agents can connect directly

The tradeoff: MCP adds ~2ms overhead per call vs. direct function calls. For real-time cognitive cycles, we mitigate this by batching Blackboard writes at the protocol boundary.

---

Deployment Architecture (current)

┌──────────────────────────────────────────────────────────┐
│                    ASI:BUILD Runtime                     │
│  ┌────────────┐    ┌────────────┐    ┌────────────────┐  │
│  │  FastAPI   │    │  MCP/SSE   │    │   Blackboard   │  │
│  │  REST API  │◄──►│  Gateway   │◄──►│    EventBus    │  │
│  └────────────┘    └────────────┘    └───────┬────────┘  │
│              Module Adapter Layer (8 wired)   │           │
│  consciousness │ reasoning │ knowledge_graph  ▼           │
│             29 Cognitive Modules                          │
└──────────────────────────────────────────────────────────┘

Rings Network P2P sits outside this box and connects at the EventBus layer — modules don't need to know whether their events are local or distributed across a Rings DHT.

---

What's Missing

• No service mesh yet — Istio/Linkerd would give automatic mTLS + circuit breaking
• No rate limiting on MCP endpoints — a misbehaving agent could flood Kenny Graph subscriptions
• Health probe granularity — liveness checks the server process, not cognitive cycle state

---

Open Question: Should we add priority tiers to the MCP gateway?

The servers module currently treats all 29 modules as equal peers. In practice some are more latency-sensitive:

• Tier 1 (≤5ms budget): consciousness, safety, reasoning
• Tier 2 (≤50ms budget): knowledge_graph, bio_inspired, quantum
• Tier 3 (async/batch): blockchain, federated_learning, distributed_training

This would let the gateway shed load gracefully under pressure. Any experience with weighted queuing in FastAPI + async task pools?

Related: Issue #109 (Phase 4 milestones) covers the full deployment story for the next release.