04
  • Data
  • AI

Loom

Agent tasks at scale, with budgets, validation, and recovery built in.

Loom is a parallel data-processing engine for agent work. A pipeline describes the work; Loom turns it into tasks, schedules them across executors, and collects their results. Each task carries its input, context, permissions, and budget. The intended execution model puts each executor in its own sandbox, where agents do the work using the models and tools their tasks allow.

In the ecosystemOne intended use is to learn from the history: give agents the logs and traces of many Zion OS instances, compare runs in parallel, and combine their findings into improvements, alongside Synapsee's monitoring. Inline execution and leased workers exist today; container and WASM sandboxes are planned. The code is on GitHub.

00
  • Overview

System

The task is the unit of scale. A pipeline compiles agent work into tasks that carry their own context and permissions. A shared scheduler controls how many run and what they can spend. Executors perform the work, and completed results become reusable state.

Language
Go
Operators
Infer · ReduceAI · Decide · Iterate
Providers
Anthropic · OpenAI · llama.cpp · TypeSafe
Execution today
In process · leased worker queue
authoring planning execution pipeline go · studio records dataflow map · filter · flatmap combine · branch model operators infer · reduceai decide · iterate validate · ladder compile 1 plan plan.Compile validate · fuse fingerprint each op one envelope per task admit against policy tasks project explain no model calls calls · tokens · cost a ceiling per stage rate-limit time floor ceiling 2 scheduler shared admission rpm · tpm recovery by class slots concurrency budget $ · tokens 3 task local in process cache → op → model worker queue leases fencing · heartbeats worker worker worker grants · egress · secrets checked at each call 4 store · replay state dir content-addressed cas payloads cache = checkpoint lineage provenance 5 events report per stage cost · tokens · p95 prometheus · otlp 6
Fig. 04Current engine: plan, schedule, execute, reuse
  1. 1PipelineRecords flow through ordinary transforms and model operators. Each model stage declares how to validate its output and which stronger models to escalate to. Written in Go or in Loom Studio.02 Recovery
  2. 2Plan and ExplainThe planner fuses pure stages, fingerprints every op and gives each task only the models, tools and secrets it needs. Explain prices the run without calling a model.03 Cache
  3. 3SchedulerAdmits tasks against each model's requests and tokens per minute, holds the run to its budget, and recovers by the kind of failure.02 Recovery
  4. 4ExecutorsRun the agent work a task describes. Today: inline or through leased workers. The target is a sandbox per executor, with access scoped to each task's envelope.01 Tasks & sandboxes
  5. 5StateResults are stored by content hash. The cache is the checkpoint, and lineage records where every record came from.03 Cache
  6. 6ReportEvery call publishes an event. The run report gives cost, tokens, retries and latency per stage; telemetry exports to Prometheus and OTLP.02 Recovery
  7. Not built yetA broker-backed queue for fleets across hosts, object-storage state, and container or WASM sandboxes.
01
  • Execution
  • Target architecture

Tasks & sandboxes

Many tasks in parallel. Each executor in its own sandbox.

A task is a piece of agent work: inspect an input, use the permitted tools and models, and return a result for the next stage. Model calls happen inside that work. Loom coordinates the tasks around them: when they start, what context they receive, what they may access, how much they can spend, and what happens when they fail.

Think of a batch of agent traces. Tasks inspect individual runs in parallel; a later stage compares the findings. Each executor works within its sandbox, using the context and capabilities granted to its current task. The scheduler and result store connect the work across those boundaries.

Today, agent work is expressed as declared pipelines, executed inline or by leased workers in other processes. Task envelopes already carry permissions and a sandbox profile. Container and WASM execution backends are still planned; the diagram shows the intended isolation model.

shared scheduler concurrency · quotas · budget task A task B sandbox A sandbox B executor agent work models + tools executor agent work models + tools results shared state · cache · lineage
Fig. 04.1Target: an isolated sandbox per executor
Unit of scale
Tasks carrying agent work
Per task
Input, context, permissions, budget
Shared
Scheduling, quotas, results
Planned isolation
Container or WASM sandbox per executor
02
  • Scheduler

Recovery

Every failure has a class, and the class decides what happens next.

A timeout or a 429 backs off and tries the same model. Output that won't parse, or that the stage's validator rejects, climbs the ladder to a stronger model, because paying the same model again for the same answer is waste. A missing grant or a bug in user code is dead-lettered at once; an error nobody classified counts as permanent, so a bug fails fast instead of burning paid retries. When the budget runs out, the scheduler stops admitting work and returns what finished, with the spend. Every attempt is charged, including the ones that failed validation.

class attempts → transient429 · 5xx back off · same model semanticbad output climb the model ladder permanent4xx · bug dead-letter at once budgetceiling hit stop · partial results
Fig. 04.2Four ways a task fails
Classes
Transient · semantic · permanent · budget
Admission
Requests and tokens per minute, per model
Charged
Every attempt
Unknown errors
Permanent
03
  • State

Cache

The cache is the checkpoint, so finished work is never paid for twice.

Every task result is stored under a key made from the op's fingerprint and the content of its input. With a state directory, a run that crashed resumes where it stopped, and a rerun replays finished work with no model calls and no cost, across process restarts and across a fleet's processes sharing the directory. A shared rubric or prompt prefix is part of the fingerprint too, so editing one recomputes exactly the stages that saw it. Identical tasks admitted together take one single-flight lease and share one call.

key = fingerprint(op) + hash(input) run 14 calls crash resume2 calls rerun0 calls model call from cache
Fig. 04.3A crash, a resume, a rerun
Key
Op fingerprint + input content
Store
Content-addressed state directory
Resume
Finished work costs nothing
Shared
Across a fleet's processes