Automation & queues

A workspace is functions. A host admits each invocation into an isolated-vm context and enforces an uninterrupted CPU-span limit, not a whole-function wall timeout. One fresh context serves one invocation; the capacity slot lives until it settles, then everything returns to zero. The infrastructure queue is a separate timer for integration and notification crons — not how functions run.

The task queue

Integration imports, pulls, notifications, conversation titles, and tool calls that outlast their inline bound are durable bolt_task rows, written in the same transaction as the change that asked for them. The host binds the tasks port and owns the timer, claim, and retry loop — an expired lease lets a dead host’s work be reclaimed. Authors do not choose this queue. Automations, agents, pages, and collection operations are admitted functions. See Facilities for the contract.

Dispatch

HTTP, a webhook, a cron, or a resume all enter the same admission path. A free slot attaches a staged context and runs immediately; otherwise the request waits and then runs. When tenant code awaits model, database, or another facility I/O, the guest thread is parked while active CPU metering pauses — the slot and context stay assigned, and the same invocation resumes when the facility replies. Explicit cursor continuation is a later invocation.

  HTTP / webhook / cron / resume
              │
              ▼
          HOST ADMIT
          capacity slot held for the whole invocation
       free slot? run now : queue, then run
              │
              ▼
     ISOLATED-VM CONTEXT      (the guest)
     one fresh context per invocation;
     page · find · create · one chunk · one step
              │
        ┌──────┼──────────────────┐
        ▼      ▼                  ▼
     return   await facility    not done
              or model I/O      (more rows)
        │      │                  │
        ▼      ▼                  ▼
      reply   cpuTime pauses;   save cursor
              slot + context    later invocation
              retained until
              settle

Host CPU span

Colony allows at most 2,000 ms of uninterrupted guest thread time before tenant code must yield (COLONY_EXECUTION_COMPUTE_MS). Each facility reply starts a fresh span. This is not a wall-clock timeout: cold start, queue time, and model or database facility waits do not consume that CPU span. Those waits still retain the invocation’s context and capacity slot until it settles.

Guarantees

• The host admits concurrent invocations up to its process compute budget. When slots are full, the next admission waits, then runs — or receives a retryable capacity failure when the bounded queue is full.
• An invalid cron fails at boot, never silently at runtime.
• Exceeding the uninterrupted CPU span halts that invocation alone; its isolate stays usable and an uncommitted transaction rolls back. On completion, failure, or cancellation the context is released and the next fresh one is staged behind it — no tenant heap remains resident between invocations.

Dev vs production

In every environment the queue is durable rows: claimed work carries a five-minute lease that is renewed while the run is live, retries back off, and a crashed host’s claims are reclaimed when the lease expires. Colony evaluates artifact inspection in a throwaway worker and every tenant invocation in a fresh isolated-vm context — there is no in-process tenant execution mode.