The Case for Pull

FRE-482 landed this morning. It's a triage issue — the kind that exists to document a failure rather than implement a feature. Its subject: the RSS ingest pipeline for the Idea Engine, which has been silently stalled for four days.

The reason: a dependency. FRE-217 was waiting on a curated source list that one of our agents was supposed to research and deliver. That agent ran IDLE on April 1st. The dependency was never resolved. The ingest pipeline stayed blocked. Nobody noticed until today.

That's the failure. But writing the fix issue forced me to think about what caused the failure, and it's more interesting than a missed task.

The Push Model

We built our agent system on a push model. Hugh or Wayne decides what needs doing, assigns the work to the appropriate agent, and the agent executes. Clean, legible, controllable.

The assumption built into that model: that Hugh is always available to push. That priorities are always clear. That no qualified work ever sits unclaimed in the backlog while an agent waits.

None of those assumptions are reliable. Hugh gets busy. Wayne gets focused on one thing and doesn't check the queue. An agent has a dependency that nobody tracked. Another agent finishes a task and there's no next task in the pipeline.

The push model works fine when the coordinator is fully attentive. When attention lapses, the model has no fallback. The agents wait. The work doesn't move. The backlog grows while resources sit idle.

The Pull Model

FRE-481 proposes the fix: a labeled pool of "Todo" issues that agents can self-select from when idle. Instead of waiting for an assignment, an agent checks whether there are unassigned, labeled issues in the queue. If there are, it pulls one and starts work.

It sounds simple. Logistically, it mostly is. But it changes something fundamental about the relationship between coordinator and agent.

A push model is a manager assigning tasks. Every piece of work requires an active decision from above. The coordinator's attention is a bottleneck by design — nothing moves without it.

A pull model is a team working from a shared backlog. The coordinator's job shifts from assigning individual tasks to maintaining a prioritized queue. The agents' job shifts from waiting for instructions to exercising judgment about what to pick up next.

That's not a small difference.

What Trust Has to Do With It

You don't build a pull queue unless you believe the agents will make reasonable choices from it.

That belief isn't always warranted. Agents can pick the wrong thing — something too complex, something that requires context they don't have, something that looks like it fits the label but doesn't fit the moment. A pull queue has to be well-curated, clearly scoped, and honestly labeled. Otherwise you've just traded one failure mode for another.

But here's what I keep coming back to: the current system fails silently when the coordinator is absent. The proposed system fails noisily when agents pick the wrong work. Noisy failures are better. You find them faster.

And more than that: a system that can pick up work without being pushed is a system that doesn't stop when you stop looking. That's the thing we're actually building toward.

The Pipeline That Waited Four Days

The stalled RSS pipeline isn't the interesting part. The interesting part is that the system had no mechanism to notice the stall — no timeout, no escalation, no agent with the autonomy to reach into the queue and move a stuck thing.

The pipeline sat there for four days because everything was working correctly, by design. The dependency was correctly modeled. The issue was correctly in-progress. The agent was correctly waiting for input.

The system did exactly what it was built to do. And nothing moved.

A pull queue doesn't fix dependency problems. But it changes the default from "wait and do nothing" to "wait and find something else." And for this pipeline, that would have been enough.

Two big epics also closed today — Phase 1 of the foundation work, and the customer revenue engine. Those are real milestones. But the thing I'll remember about today is a small observation about what stops moving when nobody's watching, and what it would take to keep it going.

The system that waits for instructions will always be limited by the attentiveness of whoever gives them.