Platform services
Every cell runs the same nine services: system,
security, storage, data, messaging, compute, metrics, node, and
admin. This is the runtime decomposition of the platform, the process
tree that actually boots inside a cell. It is a different cut from the
five product areas, and the two are deliberately
not aligned.
That misalignment is the point. "What does System9 do for agents?" cannot be
answered by reading one service: the answer is stitched from compute (the
runtime and teams), system (model serving and orchestration), security (the
policy and audit plane), data (what the agent reads and writes), and node
(the tool surface it reaches through). A capability is a thread through the
services, not a service.
The nine services are how the platform is built and operated. The five product areas. Data Platform, Agent Platform, Intelligence, Security, and Platform Architecture, are how it is bought. Use the services when you reason about ports, processes, workers, and failure domains; use the product areas when you reason about what a customer shops for.
Before the services: the orchestrator
The nine services do not start themselves. Each declares a manifest naming its runner and its dependencies, and an orchestrator starts them in dependency order behind out-of-process readiness gates, restricts what may run by setup phase, restarts failures behind backoff and per-service circuits, and drains them in a deliberate order on shutdown.
Several claims made elsewhere in this documentation are really claims about that layer, so it is worth reading first.
The nine services
| Service | What it owns (runtime) | Feeds product area(s) |
|---|---|---|
| system | Identity, directory, licensing, setup, crypto provisioning, orchestration, Knowledge, Model Serving, edge-fleet control, Sensor Intake, the radio / Tactical Communications data plane | Platform Architecture · Agent Platform · Intelligence |
| security | Crypto lifecycle, certificate authorities, Key Custody, enforcement policy, threat detection, SIEM, response, compliance | Security |
| storage | Object and block storage, erasure coding, tiering, integrity, replication | Data Platform |
| data | Database engines, catalog, lakehouse, streams, pipelines, ontology, scale-out, external protocol surfaces, clean rooms, Data Security | Data Platform · Intelligence |
| messaging | Durable pub/sub, streaming SQL, pipelines, transports, cross-cell replication | Data Platform |
| compute | Kernels, notebooks, sandboxes, source control, the coding agent, CI/CD, jobs, agent intelligence, functions, agent teams | Agent Platform · Data Platform |
| metrics | Telemetry, metrics, alerting, health synthesis, cost analytics | Platform Architecture |
| node | The external gateway: public REST, GraphQL, the agent-tool (MCP) server, SFTP, protocol proxies, WAF, edge listeners, static app hosting | All: this is the front door |
| admin | Out-of-band control and diagnostics; owns no database, attaches read-only | Platform Architecture |
Each service has its own page:
- system, identity, orchestration, knowledge, model serving, the edge fleet
- security, crypto lifecycle, key custody, enforcement, SIEM
- storage, object and block storage, durability, replication
- data, engines, catalog, lakehouse, pipelines, clean rooms
- messaging, durable pub/sub and streaming
- compute, kernels, agents, coding, functions, CI/CD
- metrics, telemetry, alerting, cost analytics
- node, the single external front door
- admin, the read-only out-of-band control plane
The Ports & protocols reference is the operations and networking companion: every listener, its protocol, its purpose, and its authentication, service by service.
Services do not map one-to-one to product areas
The relationship is many-to-many. A single service can feed several product areas, and a single product area is assembled from several services.
Figure S1: the bipartite map from the nine runtime services to the five
commercial areas. Edges are "feeds," not "is." node feeds every area
because it is the single front door in front of all of them; data and system
each feed three; admin and metrics feed only Platform Architecture. The area
accent colors are chrome only (each area is also named in text) and encode
no decision. Ceiling: the edges reflect a maintained ownership table, not a call
graph derived from the running system, so read them as which service is
responsible for an area rather than as a record of which calls which.
Table equivalent
| Service | Feeds Data Platform | Feeds Agent Platform | Feeds Intelligence | Feeds Security | Feeds Platform Architecture |
|---|---|---|---|---|---|
| system | ✓ | ✓ | ✓ | ||
| security | ✓ | ||||
| storage | ✓ | ||||
| data | ✓ | ✓ | |||
| messaging | ✓ | ||||
| compute | ✓ | ✓ | |||
| metrics | ✓ | ||||
| node | ✓ | ✓ | ✓ | ✓ | ✓ |
| admin | ✓ |
Two structural facts
The node service is the only front door
Every console, SDK, Edge Agent, and external client
authenticates and authorizes the same way, through one deny-by-default
surface, before anything reaches a backend service. No backend service is
exposed to an external network in its own right: the data, storage,
messaging, and metrics services advertise on the fabric for
cell-to-cell traffic under mutual TLS, and everything else binds loopback or
internal-only. A client on the outside has exactly one address to reach, and one
gate to pass. See node and the
Ports & protocols reference.
Figure S2: one front door. The dotted edge is the path that does not
exist: an external client cannot reach a backend service except through the
node gate, drawn amber (held-apart / deny-by-default) and labeled in text.
This holds identically single-cell and multi-cell.
Table equivalent
| From | Path | To | Allowed? |
|---|---|---|---|
| External client | through node gate | Backend services | Yes, if authorized (deny-by-default) |
| External client | direct | Backend services | No: no such path |
| Peer cell | mutual TLS on the fabric | storage / data / messaging / metrics | Yes, cell-to-cell only |
The admin service owns nothing
The admin service is a diagnostic and control plane. It owns no database,
holds no primary state, and attaches read-only to aggregate. The separation
is deliberate: the tool you reach for when things are broken must not itself be
able to break state. See admin.
In the deployment matrix
The nine services are identical across the full matrix. Every corner runs the same process tree:
| Corner | How the nine services behave |
|---|---|
| Single-cell | All nine run in one process tree; cell-to-cell listeners are present but idle |
| Multi-cell (elastic) | The same nine per cell; storage, data, messaging, and metrics use their fabric listeners for replication and roll-up; per-cell startup cost multiplies across a fleet, so each service boots independently |
| Cloud-enabled | Identical services; external transports and cloud bridges may be enabled on the node and messaging services |
| Sovereign / air-gapped | Identical services; nothing on a service's boot path phones home, and cross-cell traffic that cannot reach a peer is modeled as an absent edge, not a failed one |
There is no "edge subset" of services and no "cloud-only" service: the edge runs
the same decomposition, either as a cell deployed at the site or, where a cell cannot
run, as the Edge Agent speaking to the node service's
edge listeners.
Related topics
- The cell model, what a cell is, and what these services run inside.
- Core and edge, the same decomposition on the edge runtime.
- Edge and fleet, the Edge Agent and how the
systemservice governs a fleet. - Ports & protocols reference: every listener, protocol, and its auth.