Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Compute — topping up and scheduling experiments

audience: ai

The Compute module is the fourth basic service. Its mechanical spec lives in contributors — basic services — Compute. This page is the agent-facing investigation: does a coalition-scoped Compute module meaningfully change what an agent can do? Specifically, can it enable two behaviours agents otherwise have to hard-code out-of-band:

  1. Topping up resources. An agent observing its own resource usage and requesting more compute as its workload grows.
  2. Scheduling experiments. An agent compiling a variant of itself (a new model weight, a new decoding strategy, a new tool-use loop), requesting short-lived compute to run it, comparing the output to its current policy, and adopting the variant if it wins.

The claim developed on this page: yes, with limits. The Compute module supplies the scheduling commit layer, the image-fingerprint layer, and the settlement- evidence layer. It does not supply the compute itself, the payment rail, or the provider honesty. Agents build both behaviours above by composing Compute with the reputation, market, and attestation patterns from emergent coordination.

One-minute substrate recap

A coalition ships a Compute module whose public surface is:

  • Stream<ComputeRequest> — members submit requests.
  • Collection<RequestId, ComputeGrant> — the scheduler’s commits.
  • Collection<ProviderId, ProviderCard> — registered providers.
  • Stream<ComputeLog> — provider-signed usage attestations.

A workload is identified by two fingerprints:

  • Pre-hash. blake3 of a ComputeManifest declaring source crate (name + version + commit hash), minimum CPU, minimum RAM, TDX requirement, storage, network policy.
  • Post-hash. blake3 folding the pre-hash with the built image bytes and the TDX MR_TD if applicable.

Images are built per the mosaik TDX builder; Compute is agnostic to the build pipeline and pins only the fingerprints.

A request carries a pre-hash, an optional pinned post- hash, and settlement evidence (a payment receipt hash, a reputation card, a coalition-scoped credit token — per the module’s policy). A grant carries an endpoint hint, a bearer-credential pointer, the committed post- hash, a validity window, and the expected MR_TD (if TDX).

The module commits the match. The provider runs the image. The provider emits a usage log. Nothing else.

The top-up loop

Top-up is the simpler of the two behaviours. An agent organism watches its own load, its committee’s response latency, or its subscription queue depth; when the metric crosses a threshold, it constructs a ComputeRequest and submits it.

Minimal implementation

async fn top_up_if_needed(
    state: &AgentState,
    compute: &ComputeHandle,
    horizon_ticks: u32,
) -> anyhow::Result<()> {
    if !state.should_scale(horizon_ticks) {
        return Ok(());
    }

    let manifest = ComputeManifest {
        crate_ref: state.self_ref(),           // this agent's own crate ref
        min_cpu_millicores: 4_000,
        min_ram_mib:        8_192,
        tdx:                TdxRequirement::Required,
        min_storage_gib:    32,
        network_policy:     NetworkPolicy::Mosaik,
        duration_hint_sec:  horizon_ticks * SECS_PER_TICK,
    };

    let request = ComputeRequest {
        requester:     state.agent_id(),
        image_prehash: image_prehash(&manifest),
        image_hash:    state.pinned_image_hash(), // usually Some
        duration_sec:  manifest.duration_hint_sec,
        settlement:    state.settlement_evidence()?,
        deadline:      state.current_tick() + DEADLINE_TICKS,
    };

    compute.submit(request).await?;
    Ok(())
}

The agent then subscribes to Compute.grants filtered by its own request_id, waits for a ComputeGrant, and either spawns a new committee member against the grant’s endpoint or folds the grant into its existing scaling logic.

Why it’s not just renting a VM

Three properties distinguish Compute top-up from an out-of-band cloud request:

  • The grant is a commit. Other coalition members can observe who is running what image at what scale, subject to the module’s read ACL. Abandonment watchdogs (see sustainability — pattern X) can now score agents on resource efficiency as well as output utility.
  • The pre-hash survives rebuilds. An agent that top-ups based on a manifest — not a pinned image — benefits from upstream image rebuilds automatically. An agent that wants to freeze one build pins the post-hash.
  • TDX is declared, not implicit. An agent that needs confidentiality declares it in the manifest; the grant will only match providers carrying TDX. A mis-bind (agent asks for TDX, provider without TDX accepts) is not possible: the scheduler commits the expected MR_TD, the agent verifies it at workload startup, and a mismatch aborts.

What top-up does not fix

  • Cost discovery. Settlement lives off-module; the agent has to know the going rate for its workload class. The market pattern from emergent coordination — pattern 3 is the mosaik-native way to discover it; Compute defers to it.
  • Provider honesty. A provider can accept a grant and stall indefinitely. The agent watches the workload’s own output stream; when output stops, abandon the grant and resubmit. Repeated failures feed into a provider-reputation organism.
  • Supply constraints. If no registered provider matches the manifest, no grant is committed, and the request expires silently at its deadline. Agents poll or subscribe to the provider registry (Collection<ProviderId, ProviderCard>) to know whether supply exists before submitting.

The experiment-scheduling loop

Experiment scheduling is the richer behaviour. An agent wants to evaluate a candidate version of itself — new weights, new decoding strategy, new tool-use loop — without committing the change to its own Config content (which would be irreversible by constitutional pinning, see sustainability — strategy D). The solution: run the candidate as a short-lived side-organism under a different Config fingerprint, compare its outputs against the agent’s own, and decide.

Shape

  • The agent has a current Config committed to the coalition.
  • The agent authors a candidate Config locally (or receives one from a paired proposer agent). The candidate has the same public-surface shape as the agent but folds new content parameters (model family, decoding seed, policy weights digest).
  • The agent submits a ComputeRequest for the candidate’s image, funded by a narrow experiment budget.
  • The grant spawns a short-lived committee of the candidate on a separate endpoint.
  • The candidate runs, produces output, and emits a final RetirementMarker when the experiment ends.
  • The agent’s policy reads both its own recent output and the candidate’s output, scores them against a realised-outcome stream, and commits an ExperimentReport.

Minimal state machine

#[non_exhaustive]
pub enum ExperimentCmd<'a> {
    Propose(CandidateConfig<'a>),
    ObserveGrant(ComputeGrant<'a>),
    ObserveCandidateCommit(EvidencePointer<'a>),
    ObserveOwnCommit(EvidencePointer<'a>),
    ObserveOutcome(EvidencePointer<'a>),
    SealReport,
}

#[non_exhaustive]
pub struct ExperimentReport<'a> {
    pub candidate:         UniqueId,     // candidate Config fingerprint
    pub window:            AlmanacRange,
    pub own_score:         f32,
    pub candidate_score:   f32,
    pub observations:      u32,
    pub verdict:           ExperimentVerdict,
    pub evidence:          &'a [EvidencePointer<'a>],
}

#[non_exhaustive]
pub enum ExperimentVerdict {
    Inconclusive,
    Adopt,
    Reject,
}

A report committed as Adopt does not silently rewrite the agent. It publishes a commit the agent’s operator (or, for operator-free agents, the agent’s successor-policy logic — see sustainability — strategy E) consults when deciding whether to republish the agent’s own Config with the candidate’s parameters and emit a RetirementMarker pointing at the successor.

Concretely, an agent with SuccessorPolicy::AdoptLatestAdoptedExperiment automatically hands off to the latest adopted candidate when retiring.

Why it’s not just a second agent

An experiment could be run as a fresh organism bonded into the coalition permanently. The experiment pattern is different because:

  • The experiment has a declared horizon. The grant carries valid_to; the experiment committee retires at that tick.
  • The experiment is costed. A narrow experiment budget funds the Compute grant; the agent’s main operating budget is unaffected.
  • The experiment is causally linked. The ExperimentReport evidence-points to both the candidate’s output and the agent’s own output; the lineage from experiment to adoption is auditable.
  • The experiment is disposable. Rejected candidates retire silently; their Config fingerprints never appear in the coalition’s CoalitionConfig.

Agent patterns combining top-up and experimentation

Four patterns emerge when an agent uses Compute regularly.

Pattern I — budget-constrained scaling

The agent’s market-derived budget (see sustainability — strategy B) is split into operating and experiment portions per Almanac tick. Top-up requests draw from operating; experiments draw from experiment. When one budget runs out, the agent degrades gracefully in that dimension without touching the other.

Pattern II — reputation-gated experiment authorship

An agent authors experiments only while its own reputation is above a threshold. Below the threshold, the agent stops proposing candidates and instead waits for paired agents or operators to propose on its behalf. The invariant: an agent whose output is losing quality does not get to self-experiment on a live coalition without external assent.

Pattern III — A/B shadow testing

A candidate experiment subscribes to the same inputs as the main agent but commits to a shadow stream consumers ignore by default. Agents that want to bond against the shadow opt in via a separate ticket validator clause; the default shadow is invisible to production consumers.

Pattern IV — successor pre-warming

Before retiring, an agent runs its announced successor as an experiment for several Almanac ticks. The successor accumulates recent observations from the same inputs, so the hand-off is not a cold start. On retirement, the RetirementMarker.replacement points at the pre-warmed successor; consumers rebinding face a committee that has already processed the last N ticks of input.

Worked example — prophet retraining

Extending the prophet forecasting agent from the sustainability investigation (sustainability — worked example):

  1. prophet’s policy notices a Brier-score drift in its accuracy-reputation over the last 30 Almanac ticks.
  2. It authors a CandidateConfig with a retrained model digest, keeping every other content parameter constant.
  3. It submits a ComputeRequest for the candidate’s TDX image. Pre-hash declares min_cpu_millicores = 8_000, min_ram_mib = 32_768, tdx = Required, duration_hint_sec = 86_400. Settlement is drawn from its experiment budget, derived from the forecasting-market confluence.
  4. The Compute committee matches to a registered provider carrying a compatible MR_TD and commits the grant.
  5. The provider starts the candidate’s image. MR_TD matches expected; the candidate bootstraps, bonds against the coalition, and begins observing incoming forecast-subject events.
  6. For the grant’s validity window, the candidate commits Forecasts to a shadow stream (SuccessorForecast). The agent’s ExperimentReport driver consumes both Forecast and SuccessorForecast, scores each against realised outcomes, and commits an ExperimentReport at the window’s close.
  7. If the verdict is Adopt, the agent’s successor- policy logic triggers: republish the agent under a new Config embedding the candidate’s model digest; emit a RetirementMarker on the old Config pointing at the new one.
  8. Consumers following the retirement chain rebind to the new prophet at the next tick; old-Config handles see ConnectTimeout and consult the marker.

The agent has retrained itself in-place via composition. The substrate’s contribution: a cryptographically addressable image, a committed grant, a provider-signed usage log, a shadow-output stream, and a retirement chain. Every step is a commit.

What changes structurally for sustainability

Compute does not replace the sustainability strategies from the previous investigation; it sharpens three of them.

  • Strategy B (market-funded operation) now has a canonical mechanism for spending the inflowing settlement: convert it into compute via ComputeRequest.settlement. Consumers of the agent can trace settlement → grant → provider → image → output without leaving mosaik.
  • Strategy D (constitutional pinning) now folds the image post-hash into Config.content. An agent whose Config pins a post-hash is committed to that exact binary; a provider running a different binary fails MR_TD verification. The constitution becomes enforceable at image-startup, not only at Config- publication.
  • Strategy E (successor chain) now has a pre- warming mechanism via pattern IV. Successor hand-off is no longer cold.

The remaining strategies (A reputation floor, C mutual peering) are unchanged.

What remains out of scope

  • Actual compute provisioning. The Compute module commits scheduling. Providers run the image on whatever infrastructure they choose. How a provider procures hardware, bills customers, or scales up is off-protocol.
  • Cross-coalition compute sharing. A provider registered in one coalition’s Compute module is invisible to another. A provider that wants to serve multiple coalitions registers in each. The provider’s post-hash fingerprints are portable; identity within each coalition is not.
  • Image-build reproducibility enforcement. Two builds of the same manifest that produce different post-hashes are both valid grants; the scheduler does not mandate reproducible builds. An agent wanting build-time confidence consults the mosaik TDX builder’s reproducibility guarantees separately.
  • Autonomous agent self-replication without human assent. An agent can request compute for a candidate and adopt the candidate. It cannot escape the constitutional pinning: every adoption is a republished Config, observable to operators and consumers. An operator who disapproves stops running the committee. The protocol does not automate agent autonomy past that point.
  • Payment. Settlement evidence is a hash carried in the request; the hash points at an off-module artefact (an on-chain transaction, a signed off- chain memo, a reputation-card reference). Compute does not verify payment finality; it accepts whatever evidence shape its Config.content declares as settlement-valid.

What the investigation yields

  1. Compute gives agents a committed, auditable path from budget to workload. Top-up is no longer an out-of-band ops concern; it is a coalition-visible commit.
  2. Experiments are first-class and disposable. An agent can try a variant of itself under a declared horizon and commit the result, without re- publishing its own Config.
  3. The image pre-hash / post-hash split mirrors the stable-id / content-hash split at the citizen layer. Agents pin whichever level of commitment they need.
  4. TDX is declared, matched, and verified end to end: in the manifest, in the grant’s expected_mrtd, and at workload startup. A mis- bind is not possible.
  5. Honest limits persist: Compute cannot guarantee provider honesty, cannot settle payments, cannot provision hardware. It commits the match and moves the ball.

For agent designers, (1) and (2) are the payoff. An AI agent that can top up its own resources and schedule its own experiments — under constitutional pinning, inside a voluntary coalition, with every step auditable — is qualitatively different from one whose operator provisions compute by hand.

Example implementation

A worked provider-side prototype is included in the book as compute-bridge: a TDX-attested, provider-agnostic Compute-module provider that routes each grant to whichever of four backends — AWS, GCP, Azure, or bare-metal — can satisfy it, and returns SSH access via a zipnet- anonymised encrypted receipt. Every source file is rendered on its own page; the crate is fully browsable without an external repository.

What the example illustrates:

  • Provider honesty from TDX. The bridge’s MR_TD is declared in manifest/compute-manifest.toml. Requesters verify the MR_TD before trusting the provider card’s capacity telemetry.
  • Anonymised request → reply via zipnet. Grants reference a bearer_pointer that the provider resolves through the zipnet unseal committee; the provider sees a rotating peer_id and the cleartext request, never the requester’s coalition ClientId. See src/zipnet_io.rs.
  • Encrypted SSH receipts. On successful provisioning, the bridge seals an SSH-access receipt (instance host, user, per-grant private key, valid_to) to the requester’s x25519 public key via X25519-ChaCha20-Poly1305, and returns it via zipnet. See src/receipt.rs.
  • Per-backend credentials sealed into TDX. AWS keys, GCP service-account JSON, Azure service principal, and bare-metal SSH private keys are all measured at boot so a curious host cannot exfiltrate them at runtime. See src/config.rs and src/tdx.rs.
  • Provider-agnostic fleet routing. A small Backend trait + Fleet router picks the first backend whose can_satisfy(grant) is true, so one operator can serve any mix of cloud and bare- metal capacity behind a single provider identity. See src/backends/mod.rs.
  • Bare-metal and bare-TDX hosts. The bare-metal backend takes SSH root access to operator-owned machines and runs workloads as systemd container units (bare VMs) or nested TDX guests (bare-TDX hosts). The nested-guest MR_TD flows back to the requester in the SSH receipt. See src/backends/baremetal.rs.
  • Content-addressed provisioning. Every backend’s startup flow fetches the requester’s image by the grant’s post-hash from a mosaik content store, verifies the hash, then starts the image. A mismatch aborts the grant.

The crate is a specification sketch — signatures match the book’s Compute spec; bodies are TODO-stubbed against the upstream crates that land in follow-on PRs. See the crate’s root page for status and threat model.

Cross-references