Durable missions.
Explicit boundaries.

Create, then start

Preview access requires a tenant allowlist entry, an existing registered Trust agent, encrypted database configuration, and a running worker connected to the configured durable backend. Use your project credentials; never submit secrets in a mission definition.

1. POST /v1/continuum/missions with an Idempotency-Key and validated mission definition.
2. Store the returned mission_id and version.
3. POST /v1/continuum/missions/{id}/start with the current version.
4. Read /history, /outputs, /cost, /graph, and /trust or open Continuum in the console.

Definition fields: objective, initiating_agent_id, budget_micros, currency (USD), deadline (Unix milliseconds), allowed_models, allowed_providers, allowed_regions, allowed_tools, privacy, workflow_definition, and context_references. Money uses integer millionths of one US dollar. Every intelligence step specifies a bounded route list, max_cost_micros, and timeout_ms.

Execution and recovery

Temporal coordinates durable wakeups and retries behind a backend adapter. Customer APIs use mission terminology. Workflow histories contain opaque identifiers and redacted status; encrypted mission state lives in the MC-1 database. Signals and timers survive worker replacement. Database commands are reconciled when backend delivery fails.

Steps run sequentially. Evaluated failures can advance to the next allowed route with exponential backoff. A step reservation is committed before dispatch. Unknown external outcomes remain blocked with their reservation intact; operators must reconcile the external receipt. Continuum does not promise exactly-once arbitrary external side effects.

Human approvals

An approval step specifies distinct approvers and a quorum. Only a verified human session for a named approver may approve or reject. Votes bind to the mission version and current step. Completing a quorum queues the next step; it does not bypass that step’s fresh identity and Guard checks. Pause/resume and cancellation preserve in-flight accounting.

Reviews also support delegation to pre-authorized people, requests for information answered by the mission owner or a named reviewer, and bounded input changes to the immediately following tool proposal. Each material change clears prior votes. All review actions require a human session and retain the original deadline.

Optional outcome contracts require evaluated step outputs and can set a final cost target. A failed outcome initiates configured compensation. The mission trust endpoint exposes persisted evaluation receipts and a versioned assurance record; it does not confer independent certification.

Security and evidence

Every API read and write is scoped to the authenticated organization and project. Tenant enablement, RBAC, rate limits, request IDs, version fences, and encrypted storage apply. AES-GCM associated data binds each record to its tenant, project, and mission. Worker secrets are supplied through deployment configuration backed by a secret manager. Rotate encryption keys by retaining old decryption keys until every affected record has been re-encrypted.

Mission output references point to encrypted evidence; an event hash chain records mission transitions. These records do not establish independent assessment or certification. The existing production Trust certification and Guard gates remain unchanged.

Usage and pricing

One accepted first start is one mission execution. Retries, provider changes, approval waits, and worker recovery do not generate another mission-start charge. Inference and third-party evaluation charges remain separate and visible. Proposed annual subscriptions cost ten monthly payments, a 16.67% effective discount. Allowances reset monthly, including annual subscriptions.

Trust assurance events and Continuum mission starts are different units. The revised rates remain inactive until commercial validation. Self-service missions are limited to 10 sequential steps, three routes per intelligence step and a 30-day deadline. Overage requires an explicit monthly spending limit and defaults to zero. Annual plans receive a fresh monthly allowance. Workload size, retained bytes and backend operations must be measured before commercial activation.

Current release boundary

Preview only. Local lifecycle, isolation, encryption, quorum, budget, and concurrency tests cover the initial implementation. Production backend crash recovery, load and chaos testing, disaster recovery, paid billing, enterprise contracts, and full security review remain release gates.

Encrypted context retrieval, reverse-order compensation, exclusive Forward discovery ownership, worker health and safe retry controls are implemented. Approved external tool endpoints must satisfy the receipt and idempotency contract. Subscription checkout, paid-status synchronization, atomic usage admission and monthly overage invoicing are implemented behind release gates. Actual Stripe sandbox acceptance, deployed adapter verification, production load/chaos and backup/restore remain outstanding. Webhook delivery, comprehensive admin controls, multi-region operation remain future work. This release is not generally available.