Module operator 

Operator abstraction.

Roles

• Spawners (SpawnerAdapter) do not know about Operator kinds. Ordinary dispatches are handled by ProcessSpawner / InProcSpawner / etc.
• OperatorSpawner is the SpawnerAdapter that routes dispatches through an operator. It holds an Arc<dyn Operator> and does one thing: hand every spawn request to that operator’s execute. It still does not know the operator’s kind (MainAi / Human / Automate / Composite).
• The Operator trait itself returns a WorkerResult, as a synchronous backend. Implementations are free per kind — a MainAi operator might round-trip through Claude via an HTTP callback, a Human operator might prompt on a CLI, an Automate operator might delegate to a different spawner, and so on.

Which dispatches go through the OperatorSpawner is decided at the flow.ir layer (designer + hints + Swarm compiler). The algocline strategy side never says “hand this to the operator” — a firm separation of concerns.

Re-exports

pub use render::render_system;

pub use render::slots_from_prompt;

pub use render::RenderError;

Modules

render

system_prompt template rendering for the Operator path.

Structs

OperatorSpawner

A SpawnerAdapter implementation that hands the dispatch off to an Arc<dyn Operator>.

OperatorWorker

Concrete Worker type for the Operator kind — wraps the async Operator::execute call. This represents the handle for a task backed by an operator (SDK, WebSocket bridge, direct LLM call, etc.) and embeds a WorkerJoinHandler that carries the async signal.

Traits

Operator

The Operator trait: takes a spawn request and returns a WorkerResult. The backend for OperatorSpawner. Implementations are free to differ per kind; the spawner just calls execute and stays out of the internals.