#014 - Your Failed Experiments Have Expired
July 8, 2026
Enjoying this newsletter?
Subscribe to get future issues
July 8 2026
I’ve been trying to make one agent run a crew of other agents for over a year. With Opus, with GPT-5.5, more attempts than I can count. The setup worked. The first couple of tasks worked. Then somewhere past the halfway mark, the lead agent would start to slip: forget a decision we’d made an hour earlier, misremember what one of its workers had shipped, sign off on something that didn’t match the plan. No crash, no error. I’d find the damage only at the review stage and spend an evening tracing it back and cleaning up.
Every time, I shelved the idea and went back to running/orchestrating tasks myself, one at a time.
This week I unshelved it. I’ve been running Fable 5 as the lead agent on real multi-task work, and it holds up so much better: long runs, a pile of tasks, and it doesn’t lose the thread. So I turned the whole workflow into a skill. An orchestrator and its subbies.
One orchestrator, many subbies
The pattern is similar to a general contractor. One lead agent owns the job: it researches the tasks, asks me the questions only I can answer, splits the work into waves, and hands each piece to a worker agent. I call those workers subbies, because that’s what they are: subcontractors. Codex frames the walls, a cheaper model does the drywall, and several inspectors walk through and review before anything ships.
Two rules make it work.
The lead never writes code. Its job is planning, briefing, routing, judging, and integrating. When the lead starts implementing, its context fills up with diffs and it loses the ability to judge the rest of the job.
Nothing gets dispatched until the plan is blessed. The lead researches everything first, resolves what it can defensibly resolve on its own, and brings me only the decisions that are mine to make. I sign off once, then get out of the way. Depending on how far along my planning is, sometimes I do this as a dedicated session, and sometimes I do it in line in the same session that will orchestrate everything.
Where the old models fell over
Orchestration is surprisingly challenging for LLMs to get right. The lead has to hold the plan, every decision we made, what each subbie was briefed on, and what each one actually returned. No single piece is hard but together they add up. With Opus and GPT-5.5, once a run got past a handful of tasks, the bookkeeping outgrew the model.
The failures were subtle. The orchestrator kept going, confidently, with slightly wrong state. A decision from the morning quietly inverted. A subbie’s report taken at face value when the diff said otherwise. Those bugs are hard to diagnose because the transcript looks fine; every step reads as reasonable. You only see the drift when you read the code and test the system against your expectations (and yes, you should still glance at the code!).
I did a lot of that type of cleanup with previous models. It was slower and more error-prone than doing one small task at a time, so I stopped orchestrating big chunks of work. Until now.
What changed
Fable 5 is the first model I’ve run as an orchestrator that keeps the bookkeeping straight. It led several long sessions on real project work this week. In one, it scoped a gnarly multi-part build: researched the codebase, walked me through the open design decisions one question at a time, and kept every settled decision settled across hours of back and forth. In others, it ran crews of CLI agents (Opus, Codex, Amp, GLM; multi-perspective is best!): briefing each one, collecting the results, and reconciling where they disagreed.
The subtle drift hasn’t shown up. Decisions stay decided. Subbie reports get checked against the actual diff instead of taken on faith.
So I codified the workflow into a skill: /orchestrate. It takes a list of tasks from anywhere (my task system, GitHub issues, plain text), researches everything first, checks with me on any unknowns, assumptions, and open questions, and dispatches nothing until I bless the plan. The fun part: I built it by having the AI interview me about how I delegate. My management style is now a markdown file.
The takeaway
If a workflow failed on earlier models, that result has expired.
Anthropic did say Fable was built for longer-horizon, multi-agent work. But every model release claims something like that, so I didn’t believe it until my own shelved workflow ran clean on it. Whatever you shelved (multi-agent runs, bigger slices of autonomy, whole-feature delegation) deserves a re-run.
And when you re-run it, write your routing rules down first. Which model gets which work. What the lead may do and what it must never do. Mine: the expensive model plans, briefs, judges, and integrates, and it never implements; cheap models get the well-specified tasks; review always gets multiple perspectives. Rules in a file beat vibes in a prompt. It’s the same conventions argument from issue 013, one level up: the delegation itself is now something you encode.
I’m also curious whether GPT 5.6 Sol will hold up as an orchestrator. Can’t wait to find out once OpenAI releases it (any day now!).
Cool stuff from the web
A Field Guide to Fable: Finding Your Unknowns
On surfacing the unknowns in your task before the model runs off with the wrong assumptions. Pairs well with the bless-the-plan gate above; the interview is where those unknowns get found.
A proper guide to Fable
A full tour of working with Fable day to day. If you’re re-running your shelved experiments, start here.
Until next time
If Sol lands before the next issue, I’ll put it through the same orchestration runs and share what happens.
Keep shipping, Joey
P.S. What’s the workflow you shelved because the model couldn’t hold it? Hit reply and tell me; I’m curious to hear what you’re working on!