Skip to main content
The swarm interpreter library provides parallel task fan-out with a table-based data model. It gives agents a three-function API (create, run, rows) that handles concurrency, batching, error grouping, and result merging. The core value:
  • Context isolation. Source data and results stay in the interpreter. The agent sees lightweight handles and summaries, not the raw data. An agent processing 1,500 records consumes only a few hundred bytes of context through swarm.
  • Deterministic coverage. The dispatch loop is infrastructure, not generated code. The agent can’t quietly skip items or decide a sample is “sufficient.”
  • Concurrency management. Bounded worker pool (up to 10 concurrent dispatches) with auto-batching for larger tables.

Configure swarm

The swarm() factory takes a default model and a list of named subagent configurations. Each subagent gets its own system prompt, tools, and optional model override.
When no model is specified on a subagent, it uses defaultModel.

How it works

Swarm operates on a table: a JSONL-backed data structure where each row is an independent unit of work with an id and arbitrary columns. The agent creates a table, dispatches work across rows, and reads results back. The table is the single source of truth throughout the pipeline. Data flows through the interpreter, not the agent’s context window. The agent sees:
  1. The create() handle: { id: "t_abc", count: 1585, columns: ["id", "text"] }
  2. The run() summary: { completed: 1585, failed: 0, skipped: 0, failures: [] }
  3. The aggregation output from rows() + JavaScript
Total context consumed: a few hundred bytes instead of the full dataset.

API reference

create(source)

Builds a table from one of three source types and returns a lightweight handle. The actual row data is persisted to the backend and never returned to the caller.
Exactly one source type must be provided. Providing zero or more than one throws.

run(tableId, options)

Dispatches an instruction template across rows via subagents. Results are merged back as new columns on the table.
Dispatch mode. When subagentType is set, each dispatch runs a full agentic loop with tools and middleware (agent mode). When omitted, each dispatch is a direct model call with structured output and no tools (invoke mode). Use invoke mode for classification, extraction, and labeling. Use agent mode when the subagent needs tools like web search. Return value. run() returns a summary. It never throws due to individual task failures.
Failures are grouped by error message. Instead of 42 individual errors, the agent sees 3-4 categories with counts and affected IDs.

rows(tableId, options?)

Retrieves rows for inspection and aggregation. The data enters the interpreter’s memory, not the agent’s context window. Only computed results (via console.log) flow back to the agent.
There is no default limit. The agent performs aggregation in JavaScript inside the interpreter, and only the computed result flows back to the context.

Filtering

Filters select rows in both run() (scope which rows are dispatched) and rows() (query results). They support leaf predicates and recursive combinators.
Column paths support dot-notation for nested access (e.g., { column: "meta.score", exists: true }). Retry pattern. Use exists: false to select rows that failed or were never processed:

Structured output

When responseSchema is provided, each schema property is flattened as a top-level column on the row:
Schema enum constraints prevent output drift across large task sets. Schema description fields are visible to the model and influence output quality. Batching and structured output are independent. When batchSize is set without responseSchema, the batching layer auto-generates a minimal schema internally to match text results back to rows by ID. The caller gets a plain text column, same as unbatched.

Batching and concurrency

Swarm manages concurrency at two levels. Worker pool. Up to 10 concurrent subagent dispatches per run() call, configurable via the concurrency option (clamped to [1, 10]). Auto-batching. When matched rows exceed the concurrency limit, multiple rows are grouped into each subagent call. This bounds total dispatches regardless of table size. For example, 1,585 rows produces 32 batches of 50, dispatched 10 at a time. All 1,585 items are processed with at most 10 concurrent subagent calls at any point.

Patterns

Single-pass file review

Multi-pass analysis with filtering

Multiple run() calls against the same table. Each pass writes to different columns. Filters scope which rows are dispatched in subsequent passes.

Error handling and retry

The agent inspects deduplicated failure groups from run() and retries selectively:

Large-file classification with chunked reading