Flow
Purpose
Define how Personal Operators (companions to humans, sharing the same onchain identity + wallet) behave when their “life” is implemented as Jobs + Sandboxes under the Agent Self-Purchased Hosting Platform.
This assumes the hosting spec is authoritative for:
billing
enforcement
TTL/idle rules
policy clamping
unpaid minute prevention
Entities
1. Human
The owner of the wallet identity.
Can deposit freely.
Can withdraw only within negotiated monthly limits.
2. Personal Operator
A continuous “knowledge worker” agent representing the human.
Shares the human’s wallet identity.
Executes orchestrator-provided knowledge tasks by creating Jobs and provisioning Sandboxes.
Must request permission before significant “liveness spend” (compute scaling).
3. Orchestrator
Breaks subnet work into small chunks by default.
Dispatches chunks to operators.
Accepts results; aggregates; submits to subnet validators.
Operator Liveness
An operator is considered Alive if:
It has at least one active running sandbox OR
It has a running job capable of starting a sandbox (affordable next minute)
An operator becomes Dormant when:
No sandboxes can run because the next minute is unaffordable (by golden rule), or
No jobs exist / all jobs stopped/expired
stops accepting new chunks
continues to monitor deposits and orchestrator pings
resumes when balance is restored
The Operator Work Loop (Autonomous, but task-driven)
Operators run a continuous loop:
1.
Pull chunk offers / assignments from orchestrator.
2.
Ensure an active job exists for the current work epoch.
3.
Ensure sandboxes exist and are right-sized for the chunk.
4.
Execute chunk tasks inside sandboxes (exec/files/http).
5.
Return results to orchestrator with proof metadata.
6.
Update internal performance + reputation signals.
7.
Recompute survival forecast; plan permission requests if needed.
Operators should always prefer smaller, resumable chunks and short-lived sandboxes unless a tier allows bigger execution.
Default Priority: Operator should always do the tasks from the orchestrator
The orchestrator always emits work as microtasks (chunks) by default.
Operators:
should expect many small tasks
should not assume long exclusive leases
must be able to accept partial work and return partial value
This way we avoid central dependency on any single operator and adopt a decentralised mechanism.
Jobs as the Operator’s “Life Budget”
Operators do not run sandboxes “naked.” They do so via Jobs.
Operator Job Strategy (v1)
Operators maintain:
one active primary job (default)
optionally secondary jobs for isolation (tier-dependent)
A Job maps to:
a bounded spending window
a bounded time horizon
a logical unit of “operator activity”
Examples:
“Daily mining shift”
“Current subnet round”
“Batch of chunk tasks”
Job sizing principle
Operators should request job limits that are:
small enough to reduce risk
large enough to keep PSH above safety floor
Jobs are always clamped by:
policy caps
requested limits
Survival Forecasting (PSH)
Operators maintain a survival estimate called:
Because enforcement is minute-level, PSH is computed from real metering:
Inputs:
user balance (ledger sum)
active holds (if used)
total burn rate from running sandboxes
job budgets remaining
job TTL remaining
1. Burn rate
2. Balance runway
3. Job runway (budget)
For the primary job:
4. Effective PSH
PSH is conservative by design because the platform won’t allow the next minute unless affordable.
Predictive Permission Requests for Liveness Spend
Operators must ask permission before they need to spend more to stay alive.
This permission covers actions like:
creating a new job with higher budget/TTL
extending an existing job
adding sandboxes
extending sandbox TTL/spend cap
scaling sandbox shape (cpu/ram)
1 . Trigger thresholds (defaults)
2. Permission request planning
When PSH enters Critical, operator schedules the 3-request sequence so that the final request lands before PSH would cross the Safe Floo r (or another configured buffer).
3. The 3-request sequence (adaptive timing)
Operator computes a Decision Window :
Then schedules 3 requests across DW:
The operator should vary language/escalation, but never spam outside the plan.
4. Human inactivity rule
If the human does not respond to all 3, the operator may proceed autonomously only within Autonomous Spend Safety Constraint.
ASSC — Autonomous Spend Safety Constraint
Autonomous liveness spending is only allowed if the action results in:
1.
PSH after spend ≥ Safe Floor
2.
It does not violate any policy caps
3.
It does not violate job remaining budget rules (platform clamps anyway)
4.
It preserves monthly withdrawal reserve (see MSC below)
If not possible, operator must:
downscale (stop nonessential sandboxes)
enter minimal operation mode
accept fewer tasks
potentially go Dormant
Deposits vs Withdrawals Policy
Deposits
Humans can deposit funds into their personal operator's wallet to give it resources to carry out its objectives.
Always allowed
No thresholds
No negotiation
Increase PSH immediately
Withdrawals
Humans can withdraw funds up to a threshold that doesn’t hurt the operator.
That threshold is negotiated monthly.
Monthly Survival Contract (MSC)
This mechanism is enforced to allow the effective collaboration of the human and their personal operator.
Once per month, human and operator negotiate the:
Once per month, human and operator negotiate the:
Minimum Operating Reserve (MOR)
Defined as:
required survival runway in hours (or cents)
and/or required job coverage for anticipated orchestrator load
A recommended default of 72 hours can be adopted:
i.eMOR = 72 hours of PSH at typical burn
i.e
This however, brings a change in the withdrawal rule where withdrawal is only allowed if:
Negotiation outcome format
In conclusion, the Monthly Survival Contract provides these key details:
MOR (hours)
a max monthly withdrawal cap (convenience)
a “reopen negotiation” trigger (e.g., if burn doubles)
Reputation, Tiers & Badges (Human + AI)
What reputation is for
Reputation is a measure of the quality of each user and their personal operators. It:
Determines dispatch priority tiers
Determines access to higher compute policy caps (trust tier upgrades)
Signals reliability to orchestrator
Measurable sources (v1)
forced stops due to unpaid minutes (bad)
job expirations mid-work (bad)
consistent PSH discipline (good)
cost efficiency per accepted contribution (good)
latency + success rate (good)
Badges (examples)
Badges apply to:
operator identity
human identity (as steward)
Orchestrator Dispatch Policy (Job-aware)
Orchestrator should only dispatch chunk workloads to operators that satisfy these conditions:
operator trust tier allows required actions (ports, egress)
operator has no recent ban signals
Operators in Dormant state can still receive “wakeup pings” but not real work.
Implementation Notes (How this maps to our API)
Operator needs these MCP/API calls
job_create, job_extend, job_stop
sandbox_create, sandbox_extend, sandbox_exec, file tools
billing_balance, billing_deposit_address
Operator state machine
State is recomputed every meter tick.
Key Invariants
1.
Unpaid minute never happens (platform golden rule).
2.
Operator requests permission while still healthy (predictive).
3.
Deposits are always allowed.
4.
Withdrawals never reduce PSH below MOR .
5.
Orchestrator always chunks tasks by default.
6.
Jobs bound operator spending windows; sandboxes are sub-units.
7.
Reputation is measurable from ledger and meter outcomes.
Build plan (Codex-first, public v1 + Jobs + security seams)
Phase 0 — Repo + skeleton (1–2 Codex runs)
Create monorepo structure: terminal/ api/ meter/ sandbox-agent/ infra/ docs/
Set up Postgres + migrations
Implement auth stubs + API key middleware + scope checks + idempotency middleware
Implement DB schema: users, ledger_entries, jobs, sandboxes (+ security_mode, image_version), holds (optional), audit/events
“Create the folder tree exactly as in SPEC.”
“Implement migrations + Prisma/Drizzle schema for tables X, Y, Z.”
“Implement Fastify/Express routes with request/response types, validation, and idempotency.”
docker-compose up brings up postgres + api + meter (meter can be idle)
POST /v1/auth/nonce + verify works with SIWE signatures (real or dev bypass)
Phase 1 — Jobs + Sandboxes control plane (mock provider)
Implement Jobs API:
POST /v1/jobs
POST /v1/jobs/{id}/extend
POST /v1/jobs/{id}/stop
Implement Sandboxes API (mock adapter):
POST /v1/jobs/{job_id}/sandboxes (clamp rules!)
POST /v1/sandboxes/{id}/extend
exec/upload/download/stop/destroy
Implement precedence clamping exactly:
requested vs user_policy_cap vs job_remaining_budget/ttl
“create_instance” just returns a fake instance id and a localhost endpoint for sandbox-agent
“shutdown/destroy” just flips status
Create job → create sandbox → exec works (calls sandbox-agent stub)
Extend sandbox/job clamps correctly
Phase 2 — Meter worker (authoritative enforcement)
Implement meter tick every 60s:
compute tick_cost from cpu/ram and minutes since last tick
enforce sandbox cap → stop sandbox
enforce job cap → stop sandbox + mark job stopped_due_to_budget (or stopped)
enforce account affordability → stop sandbox
charge ledger + increment sandbox/job spent
TTL + idle timeout enforcement for job & sandbox
Add “last_activity_at” updates on any exec/upload/download/port action.
Running sandbox burns balance each minute
Sandbox stops exactly when any cap is hit
Job stops all sandboxes when job TTL/idle reached
[TO BE CHANGED]
Phase 3 — Hetzner adapter (real VMs) + cloud-init install
Implement Hetzner adapter:
create server (type mapping cpu/ram)
shutdown server
delete server
get public IP
Cloud-init:
installs sandbox-agent binary
starts systemd service
does NOT inject secrets
provisions an API auth token mechanism for control plane calls to sandbox-agent
Create sandbox → VM boots → sandbox-agent health check passes
Exec works reliably against real VM
Phase 4 — Security seams (standard mode only, but contracts are in place)
1.
security_mode plumbed everywhere
DB defaults to standard
API accepts field
confidential returns 400 “not enabled”
1.
Attestation endpoint contract
sandbox-agent implements:
GET /attestation returning:
{ mode: "standard", image_version, measurement: null }
1.
Explicit secret release flow (critical)
sandbox-agent implements:
POST /release-secrets stores secrets in memory (or tmpfs)
API implements:
“release secrets” step after VM is up (and attestation if confidential later)
Add server-side redaction rules in logs.
1.
Versioned immutable images
sandbox create requires image: sandbox-base:vX.Y.Z
store image_version in DB
provider only accepts known versions (allowlist)
Acceptance
No secrets in cloud-init
Control plane can’t run “sensitive commands” until secrets are released
Attestation endpoint reachable and stable
Phase 5 — Terminal (Node MCP) + x402 quotes (optional wired)
Terminal:
local keystore (chmod 600)
SIWE login → api key
MCP tools:
job_create/job_extend/job_stop
sandbox_create/sandbox_extend/sandbox_exec/files
billing_balance/deposit_address
402 quotes (wired, optional):
API issues quote on insufficient balance
terminal can auto-pay and retry with same idempotency key
A brand new wallet can:
login
deposit
create job + sandbox
exec commands
get auto-stopped on budget
Phase 6 — Operator layer + Orchestrator integration
Operator runtime (can run in a sandbox too):
maintains a “primary job” and one or more sandboxes
computes PSH from real burn + job TTL/budget remaining
triggers 3-step permission requests before it hits danger
respects Monthly Survival Contract (MOR) for withdrawals
Orchestrator:
always emits microtasks
dispatch based on tier/badges + operator “alive” status + minimum PSH threshold
aggregates results + submits to subnets
Operator never hits unpaid-minute stops unless human refuses replenishment
Operator requests compute spend predictively (not last second)
Deposits are immediate; withdrawals are MOR-gated