System

Pilox treats the agent layer like an operating environment: bounded processes, explicit wire protocols, and a control plane you can operate like any other production service. The goal is not “chat with APIs” — it is repeatable packaging, isolation, and observability when autonomous workloads leave prototypes.

Execution model

Two execution classes are first-class in the product story. Firecracker-style microVMs give you a full Linux boundary per agent when KVM-class virtualization is available — cold start in hundreds of milliseconds, hardware-oriented isolation, and familiar debugging. A WASM-oriented tier targets sub-5 ms cold starts and sandboxed tool execution via Wasmtime and Extism-class stacks, with a roadmap toward automatic escalation when a workload outgrows the sandbox.

• Per-agent lifecycle in the dashboard: start, stop, pause, resume, logs, and health signals.
• Compose-oriented deployments: Postgres, Redis, optional inference backends, and Pilox services as versioned stacks.
• Model routing that starts with local inference (e.g. Ollama) and scales toward vLLM and quantization-aware paths as you add hardware.

Protocols and control plane

Agents speak standards on the wire: A2A (Agent Cards, JSON-RPC, streaming) and MCP for tools. That keeps interoperability with the wider ecosystem while Pilox adds operational depth — policies, isolation, mesh, and audit hooks — around those surfaces.

The hardened @pilox/a2a-sdk direction layers Noise-style E2E, SPIFFE-shaped identity hooks, and schema enforcement on top of the same protocol shapes security teams already recognize from the Linux Foundation specification.

Operator workflow

A setup wizard covers first admin account, instance posture, AI backend hints, and federation options so new installs are guided rather than tribal knowledge. OpenTelemetry hooks mean traces and metrics land in your existing observability estate instead of a siloed “AI dashboard only” story.