A workflow engine for a local squad

A squad that only works when a human kicks each agent in turn is not a squad; it is a set of tools with extra steps. This week the local crew got a workflow engine: a way to describe a unit of work as a shape — who runs, in what order, on what inputs — and hand it to a scheduler that runs it.

The shape, not the standing pull

The squad's older model was a perpetual pull: every agent polled for work and claimed whatever it could. That produces surprises — an agent grabbing a half-finished task on restart — and no clean notion of this workflow is running. The engine is the move away from that. Work is described as a shape and initiated; the agents it names run inside it. "Drain the task queue" becomes one shape among several rather than the standing behavior.

Two shapes exist now:

• Fan-out — one input, N agents in parallel, results collected. The research swarm is this: many read-only researchers gathering at once, each blind to what the others find.
• Pipeline — each item flows through ordered stages with no barrier between them, so item A can be in stage three while item B is still in stage one.

Residency-aware scheduling

Local models compete for memory — the whole roster does not fit at once. The scheduler knows which model is resident and admits work accordingly, with a coarse risk signal — green, yellow, red — on whether the next wave fits before it tries to run it. The same grammar the substrate already uses for watts and tokens, pointed at memory.

It ran

The first end-to-end run was a two-researcher swarm: two local research agents, fanned out, gathering and returning through the engine — start to finish in about twelve seconds. Small, but real: the engine summoned the agents, ran them in parallel, collected the results, and released the memory. That fan-out is exactly the cheap, wide local search that feeds the expensive judgment step — the division of labor the rest of this site is about, made into something you can launch.