Restrictions

What the swarm does not support

  • No background work in bridged members. A member cannot combine background work with the agent bridge. background() raises in a bridged member, and a member that uses the bridge after starting background work ends errored.
  • No channels with tools for bridged members. A bridged member cannot use the shared-memory channel yet, and swarm() refuses one beside it.
  • No ACP agents. ACP agents wait for their caller to drive them, so they are refused.
  • No scorers that read a member’s tool state. Each member runs in its own tool-state scope, so built-in tools that keep state in the store (memory(), bash_session(), web_browser(), the skill tool) keep each member’s at keys inside its scope, which differ from the default ones. Tool state that a setup solver prepared at the default instance is not carried into the members either; they start with fresh state (Members).

Bridged members

A bridged member runs a CLI agent in the sandbox through Inspect’s agent bridge. inspect_swe agents count as bridged by default; pass member(..., bridged=True) for other agents that use the bridge. The swarm stops a bridged member by cancelling it.

The CLI’s own tool calls do not emit Inspect ToolEvents, so the tool-event evidence described here does not cover them, Inspect Sentinel does not see them, and longest_identical_tool_run is null for bridged members.

What the log records

  • Members’ ToolEvents are the record of what they did, except for bridged members.
  • The shared-memory channel’s writes, views, notices and waits are comm events (Shared Memory).
  • Files members share in a sandbox, tool instances they share, and the result record read while the swarm runs are channels the swarm observes but does not record (Channels).

Spans inside a swarm log no StoreEvents. The swarm’s span logs the net change to the store, which says what changed but not which member changed it. If an error, limit or cancellation escapes the swarm and ends the sample, the log may have no StoreEvent for the swarm’s writes. sample.store is always the record of the final store.

The store keys

The swarm owns three keys in the sample store: inspect_swarm:result, inspect_swarm:ledger and inspect_swarm:metrics. Task code must not write them. A tool that reads inspect_swarm:result while the swarm runs gives members a view of each other’s state, status and time, a channel between members that the swarm records no evidence of (Scoring).