Architecture overview · sideload access model

AI Agent Compute Platform · Sideload Access

The platform has exactly two built-in roles: the scheduler (control plane) and the development machine (execution plane). Developers, testers and every other system are not containers or registered instances — they hold a sideload token (sdl_…) and call device → control plane → this host's root scheduler → development machine. A device only talks to the control plane: it never learns the scheduler address and holds no instance credential. A sideload has no heartbeat and takes no lease, and its permissions are a closed scope set.

简体中文
Access side: one device + one sideload token — no container, no instance registration Developers sdl_… · tasks:write · console:run Testers sdl_… · tasks:write · tasks:read Other systems CI · scripts · clients · scoped HTTPS · Authorization: Bearer sdl_… Scheduler · control plane (built-in) Single source of task state · the token stops here Sideload entry (PCS) Bearer sdl_ · scope check Resolves this host's root scheduler Task API Submit · query · cancel · retry Idempotency key · trace_id Queue & dispatch Pull + heartbeat · capability match Priority · aging · retry State machine · leases QUEUED → ASSIGNED → DONE Lease · fencing token File channel Attachments in · artifacts out SHA-256 · byte-for-byte PostgreSQL · audit Single source of task state Token create / delete logged Dispatch · Pull Heartbeat · events · artifacts Development machine · execution plane (built-in ×N) Only this host's scheduler dispatches to it Task workspace Isolated directory per task Source tree · attachments Agent execution Runs the bound Agent Profile or deterministic Shell Console commands task.console.* Requires console:run Resource admission Budget checked before start Over limit stays queued Scaling out means adding development machines — every other participant stays on the sideload path. Sideload boundary Not a built-in role · No container · no instance row · No heartbeat · holds no lease · Never learns the scheduler address · Holds no instance credentials · Token stored as a hash (plaintext shown once) Permission scopes (closed set) tasks:read tasks:write builders:read queue:read console:run console:run is granted on top of tasks:write Lifecycle & audit · Online when last call ≤ 120 s · Expiry or delete → 403 next call · Create / delete audited · Token and hash never logged Same task / lease / fencing path as the admin app — no bypass.
Legend Sideload access (device → control plane) Task dispatch / heartbeat (Pull) File channel (attachments / artifacts) Sideload boundary (external system)
① Hold a sideload token→ ② Submit a task→ ③ Scope check→ ④ Scheduler queues / dispatches→ ⑤ Development machine runs→ ⑥ Files collected→ ⑦ Client downloads artifacts

Exactly two built-in roles

Inside the platform there is a scheduler and at least one development machine. Developers, testers, CI jobs, scripts and any other system enter through sideload tokens, so no new role, container or dispatch rule is introduced for them.

One fixed call chain

A device calls the control plane; the control plane validates the token, resolves the host and its root scheduler, and forwards the request. The device never sees the scheduler address and never holds an instance credential — the same path the admin app uses.

A sideload is not an Agent

It has no container, no registration, no heartbeat and no lease of its own. Because it reuses the normal task / lease / fencing path, it cannot bypass scheduling, admission or auditing.

Least privilege by construction

Scopes are a closed set: tasks:read, tasks:write, builders:read, queue:read and console:run. console:run is granted separately from tasks:write, and unknown scopes are rejected rather than ignored.

Files move both ways

Inputs are uploaded as attachments and land under <workspace>/attachments/. Outputs are collected through the scheduler's artifact channel: any format, SHA-256 verified and returned byte-for-byte instead of being packed into stdout.

Lifecycle and audit

last_seen_at is updated at most every 30 seconds and the token reads online within 120 seconds. Deletion or expiry takes effect on the next request with 403. Token creation and deletion are audited; the token and its hash are never logged.