The compute service
The compute service is the execution and agent plane of a cell. It runs
kernels and notebooks, isolates work in sandboxes, hosts source control and
CI/CD, schedules jobs, and (most distinctively) runs the agent intelligence,
the coding agent, functions, and agent teams. It is the service that turns "run
this" into governed, metered, recorded work.
Feeds: AI Platform · Data Platform.
What it owns
- Kernels and notebooks: interactive and batch execution.
- Sandboxes: isolated execution environments.
- Source control and CI/CD: code hosting, build, and pipelines.
- Jobs: scheduled and triggered work.
- Agent intelligence: the cognition and runtime behind agents.
- Functions: one function object with multiple call sites, core and edge.
- Agent teams: multi-agent coordination.
What the compute service carries
Compute is the second-largest service, and it carries two commercially distinct things on one substrate: the workbench an analyst or engineer works in, and the intelligence engine agents run on. They share one sandbox, one metering path, one audit trail and one security model, which is the whole reason they are together.
The execution substrate
Everything else on this page runs on this.
| Area | What it does |
|---|---|
| Kernels | Python, SQL, GraphQL and Gremlin controllers with a warm pool, seccomp-BPF confinement, a builtins sandbox, import hooks for module filtering, network restriction, and row and column security enforced inside the kernel rather than in front of it |
| Sandboxes | Leased warm pools, sub-agent spawn and supervision, isolation-tier admission, shared blackboards, and a key broker deliberately held outside the sandbox |
| Functions | One function object reachable from five call sites, with an isolation tier computed from code trust, data classification and cell regime |
| Notebooks | Immutable server-hashed versions on named branches, pipeline binding, scheduling, and publication as an API endpoint |
| Scheduled jobs | Cron parsing and due evaluation, a persisted priority queue, converged schedule locking, kernel-backed dispatch, and a governed admission gate |
| Distributed query execution | SQL split into per-cell fragments, dispatched with tickets, circuit breakers and retries, then collected with signature-verified fragment results |
The agent runtime
The largest area inside the service, and the substance behind most of the Agent Platform.
| Area | What it does |
|---|---|
| Agent runtime | Where an agent actually executes, with its grant, budget and tool ceiling |
| Orchestration | The workflow graph, its registered executors, placement and the durable journal |
| Agent teams | Crews, formations, billets and the blackboard peers coordinate over |
| Cognition and reasoning | Goal decomposition, strategy selection and learning, plan execution with checkpoint and rollback, and post-execution reflection |
| Metacognition | Confidence calibration against outcomes, knowledge-gap detection, resource estimation, a self-model, and an escalation protocol |
| Memory | Trust-weighted semantic memory typed episodic, semantic, procedural and working, with consolidation, decay and contradiction detection |
| Context and conversation | A working-set manager with an explicit compaction policy, and the chat surface |
| Inference | The call path, its transparency records and its cost attribution |
| Placement | Scoring candidate cells on clearance and topology as hard constraints before cost and locality |
| Introspection | An agent inspecting its own state, plus a model of the platform it runs on |
| Deliverables | So an agent's output can be a finished rendered artifact rather than a transcript |
| Marketplace | Agent and template catalogs |
| Alignment | The decision organ every consequential action crosses |
| Guardrails | Prompt-injection defense at the agent boundary, with verdict parity against the edge runtime |
Software engineering
| Area | What it does |
|---|---|
| The coding agent | Governed coding runs with signed diff receipts and a fail-closed pre-commit scan |
| Source control | Git sync over three transport backends, SSH commit signing, credentials, pull-request execution, webhooks, and clean and smudge filters so notebooks diff sensibly |
| CI/CD | A stage-by-stage runner with manual approval gates, dev to staging to prod promotion, and rollback |
| Libraries | Per-workspace library and virtual-environment management with CVE scanning on dependencies |
| Workspace files | A registry, tree and validation pipeline, with governed workspace-to-workspace transfer |
Machine learning
Training and experiments, AutoML, pluggable backends, the export gate and artifact packer, and the federated training worker path all live here.
The operational plane
| Area | What it does |
|---|---|
| Policies and quotas | Resource policies evaluated per request, distributed quotas enforced against synced prices |
| Capacity governance | Rate limiting, an overage accountant, noisy-neighbour verdicts, and a compensation coordinator |
| Metering and pricing | Compute meter records collected through a write-ahead log, with storage cost tracked continuously |
| Secrets | Scope-scoped storage over local, AWS, Azure and GCP backends, with a master key, scoped key-encryption-keys, secure in-memory buffers and scheduled rotation |
| Governed egress | A broker binding a workload's outbound request to an attenuated grant |
| Coordination | Leader elections for singleton work, remote dispatch, and startup recovery that reconciles in-flight work |
| Reliability | Graceful shutdown, startup recovery sequencing, reliability events, and a fault-injection harness: chaos engineering as a shipped feature group rather than an external tool |
| Replication | Applying remote compute events locally with per-object-type resolution and timestamp conflict checks |
| Clean-room execution | The room-scoped compute path, with its approval, signing and aliasing machinery |
Some areas above carry internal names that are deliberately not product names, so they are described by what they do. Where a capability has a cleared public name, it is used and linked.
APIs and surfaces
compute is not externally exposed. Its HTTP and gRPC surfaces bind loopback
(clear) and an internal mutual-TLS interface; every console, SDK, and agent tool
reaches compute through the node front door, in particular through
the node agent-tool (MCP) server, which is how an agent invokes a tool that
runs here. See the Ports & protocols reference.
Workers
Background workers cover job scheduling, sandbox lifecycle, CI/CD runners, agent-run supervision, worker-policy reconciliation, and capacity governance. Each runs per cell.
The governed run
Figure: a governed run. A request carries an attenuable grant and a budget; the refusal gate (amber) can refuse at the decision boundary; whatever happens, run or refusal, is written to a signed, replayable journal (green). Ceiling: the refusal gate is shown at the decision boundary; the diagram is the governance path, not a scheduler trace.
Table equivalent
| From | Relationship | To | State |
|---|---|---|---|
| Agent / job request | arrives with | Capability grant + budget | neutral |
| Capability grant + budget | is evaluated by | Refusal gate | refusal-capable |
| Refusal gate | authorizes | Sandboxed run | core |
| Refusal gate | when it refuses, records to | Workflow journal | verified |
| Sandboxed run | records to | Workflow journal | verified |
In the deployment matrix
compute runs identically everywhere. Single-cell, all execution is local.
Multi-cell, jobs and agent runs distribute across cells under one grant and
budget model, and the workflow journal is per-cell and hash-chained. Sovereign /
air-gapped, the coding agent and the runtime work disconnected: functions run at
both core and edge, and the same governance applies with no external call.