Struct OperatorSpawnerFactory 

pub struct OperatorSpawnerFactory { /* private fields */ }

Factory for AgentKind::Operator. Looks up the Arc<dyn Operator> pre-registered under spec.operator_ref and wraps it in an OperatorSpawner.

Spec shape:

{ "operator_ref": "main_ai" }     // Operator id pre-registered with the factory

Split of responsibilities with OperatorDelegateMiddleware

The two axes exist for different reasons:

• This factory (OperatorSpawnerFactory → OperatorSpawner) — the AgentSpec axis. Bakes a separate Operator backend into each AgentDef. A kind = Operator AgentDef names its backend through spec.operator_ref; at compile() time the Arc<dyn Operator> is baked into routes[agent_name]. Because the agent.md loader (agent_md_loader) defaults kind to Operator, agents that flow in through agent-profiles land here.

• OperatorDelegateMiddleware — the Blueprint-global (session) axis. Delegates every agent to the same Operator backend. At session-attach time you call engine.register_operator(id, op) plus attach_with_ids(.., operator_backend_id = Some(id)) to bind it session-wide, and declare spawner_hints.layers = ["operator_delegate"] to opt in. ctx.agent is ignored; the operator handles every spawn in that session (a MainAI-wide driver, a human-wide console, that sort of thing).

Exclusivity (a double fire is structurally impossible)

When both are effective — the hint is declared, the session has an operator backend, and the Blueprint has a kind = Operator AgentDef — OperatorDelegateMiddleware sits at the outer end of the stack and completely bypasses inner.spawn. The OperatorSpawner is never reached, so under those conditions this factory’s routes entry is inert. This is not a double fire — the session axis is overriding the agent axis. Consistent usage means picking one axis per use case.

Interior mutability is provided by an Arc<RwLock>. Even after the factory has been stored as Arc<dyn SpawnerFactory> in SpawnerRegistry, a caller holding an Arc clone can still add Operator backends dynamically via register_operator(&self, id, op). Typical uses: registering a WSOperatorSession under the session id on WebSocket connect, binding agents that arrive via the agent.md loader to arbitrary backends, and so on. build() performs a read() lookup each time.

Implementations

impl OperatorSpawnerFactory

pub fn new() -> Self

Start with no registered Operator backends.

pub fn register_operator( &self, id: impl Into<String>, op: Arc<dyn Operator>, ) -> &Self

Register an Operator backend dynamically through &self. Overwrites are allowed — later wins. Callers can still reach this after the factory has been stored as Arc<dyn SpawnerFactory> in SpawnerRegistry, as long as they hold an Arc clone; interior mutability is provided by the inner RwLock.

pub fn unregister_operator(&self, id: &str) -> &Self

Dynamically unregister an id (used to clean up when a WebSocket disconnects, for example). A missing id is a no-op.

Trait Implementations

impl Default for OperatorSpawnerFactory

fn default() -> Self

Returns the “default value” for a type.

impl SpawnerFactory for OperatorSpawnerFactory

fn build( &self, agent_def: &AgentDef, _hint: Option<&Value>, ) -> Result<Arc<dyn SpawnerAdapter>, CompileError>

Build the concrete SpawnerAdapter for one AgentDef. hint is the matching entry (if any) from Blueprint.hints.per_agent.

impl SpawnerFactoryKind for OperatorSpawnerFactory

const KIND: AgentKind = AgentKind::Operator

The AgentKind this factory handles — used as the HashMap key by SpawnerRegistry::register.

type Worker = OperatorWorker

The concrete Worker type produced by this AgentKind — this binds the type chain all the way from AgentKind down to Worker. Every factory declares it so the AgentKind → Worker mapping is explicit across all four layers. It is the source of truth for preserving the concrete type right up until SpawnerAdapter::spawn erases it into Box<dyn Worker>.