Skip to content
Pilox
Access

Structure

Architecture

Interactive layer ladder: foundation services up through GPU and swarm surfaces — the same model we use in security reviews and onboarding.

Jump to this topic on the homepage

Deep dive

Pilox’s architecture is usually explained as a ladder: metal and virtualization, data and memory, execution tiers, wire protocols, mesh, GPU paths, swarm abstractions, and observability. The same ladder is what security reviews and onboarding decks reference — not a different diagram per audience.

Layers in plain terms

  • Foundation: Linux hosts, optional Firecracker / KVM, container runtimes, and storage (Postgres, object stores, vector indexes).
  • Control plane: API services, dashboard, job orchestration, and policy enforcement hooks.
  • Agent runtime: microVM or WASM worker, tool adapters (MCP), and A2A endpoints.
  • Mesh: local bus, federation, registries, gateways — same semantics from laptop lab to multi-region.
  • Intelligence & scale: GPU scheduling (MIG, HAMi-class schedulers), swarm patterns, semantic supervision.
  • Observability: OpenTelemetry-first traces and metrics feeding your existing backends.

Data and memory

PostgreSQL anchors relational state; pgvector and LanceDB-class stores support retrieval and agent memory. CRDT-style shared state (e.g. Loro) is on the roadmap for concurrent agent collaboration without a single writer bottleneck.

The interactive layer diagram on this page is the same conceptual model as the homepage architecture block — expanded here with room for narrative, while the visual gives reviewers a single anchor image.

Related documentation

Architecture

System architecture

Neural-mesh topology: each node runs independently under collective Pilox control-plane logic. The ladder is the map; the accordion is the briefing — L0 through L8, repo is source of truth.

AMD SEV-SNP / Intel TDX style confidential execution and future CXL pooling: hardware roots of trust for the most sensitive agents.