Designing the pipeline

Last week I decided the real problem isn't picking agents, it's context and trust. This week I drew what that looks like as a system. On paper, everything works. I've been burned enough times to know it only fails once you actually use it. So this post is the design plus the reasons behind it, and I'll flag what's still unproven.

The shape, left to right

Spec writer turns a PRD into numbered builder specs.

Work packet queue turns those specs into packets and holds them.

Approval gate means nothing gets touched until it's approved. Review is required by default.

Kernel dispatcher picks the agent and the model for each packet.

Coding agents build packets in parallel.

Test and review runs the tests and reviews the output.

Merge and ship creates the PR.

If tests or review fail, the packet goes back with feedback. If the direction itself was wrong, the loop goes all the way back to the spec.

Two things sit around the flow instead of inside it. LoopBrake watches the dispatcher and the agents, and Slack notifications hang off the end. They're constraints on every packet, not steps a packet passes through once.

Where the time went (and where it didn't)

The dispatcher, the coding agents and the review agents were the easy part, because they already exist in my harness, Pebble. I wrote Pebble earlier this year and have been tuning it since.

The time went into three places: what a packet looks like, why I wanted a cost brake from day one, and how the system survives a subscription limit.

The packet is the whole game

I redrew this more than anything else. If a packet is vague, the agent spends tokens working out what the job is and how to do it, and that's exactly the tax I'm trying to remove.

So a packet is self-sufficient. It carries:

A reference to the builder spec, so the intent is never lost.

Repo context, so the agent doesn't have to explore to get oriented.

Acceptance criteria, which are also what my tests check against.

The files it may touch, so the work is scoped.

A model tier (small, medium or high), saying how heavy the job is.

The design rule I held hardest was that packets shouldn't depend on each other. I want a lot of parallelism: many agents working at once, not one agent walking down a list. Sometimes that isn't possible. Packet 5 may genuinely need packet 3's infrastructure work first. But I want dependencies to be the exception I deliberately declare, not the default shape of the queue.

The dispatcher: rules today, smarter later

Right now the dispatcher follows rules in a config file. Specs and tech design go to the top tier, code and review to the mid tier, documentation to the light tier. That's deliberately simple.

I've kept it flexible, though. Later it could learn from outcomes: if a packet keeps failing on a mid-tier model, bump it up automatically. I'm not building that yet. I want real failure data before I teach it anything.

The 5-hour wall

This one comes from lived pain. I'm deep into a complex, multi-file change in Claude, and halfway through I hit the 5-hour limit. So I switch to OpenCode or Codex and ask it to resume. Then it spends a pile of tokens working out what the previous agent was doing, and only after that does it continue. Some days I burn through all three subscriptions within a couple of hours and just wait for the cooldown.

gFactory's answer is a fallback chain: if an agent hits its limit mid-packet, another agent picks it up, and if every subscription is exhausted, a direct API call takes over. I shouldn't be the one managing any of it.

I'll be honest that the handoff is the part I trust least. A self-contained packet should make it much cheaper for a second agent to continue than for me to re-explain things, but I haven't run a single packet through it yet.

Why LoopBrake wraps the pipeline

Anyone who has built with agents has seen them go in circles: same call, same wrong answer, over and over, while the bill climbs. Every call costs money, and the loss piles up slowly enough that you notice late.

I tried LoopBrake and it's good at exactly this. It detects when an agent is going haywire and stops it spending in a loop, and it enforces cost limits, retry limits and timeouts. I decided to build it in from the start instead of bolting it on after the first expensive surprise. It wraps the dispatcher and the agents because it applies to every packet.

Why Slack

Mostly because I've used it for years and it was the quickest to get working. WhatsApp is where I actually spend my time, but configuring it was slow, and Telegram isn't a place I'm active. The notification layer is extensible by design, so Discord, Telegram, WhatsApp or email can plug in later without touching the pipeline.

The approval gate: how long to trust

I'm biasing toward slow but trusted. My rough plan is that gFactory runs 8 to 10 real projects with every gate on before I loosen any of them.

I'm not guessing at that number, I'm copying a process. I wrote Pebble in March 2026 and kept every gate switched on. I used it, found problems, fixed them, and repeated until I trusted it. Now it runs on autopilot, and I only review once in a while. It earned that trust slowly, and gFactory has to earn it the same way.