Your AI agent still needs a babysitter.
Owain Lewis shows the better version: give it a goal, a clock, and a way to prove the work is done.
Old workflow: you write the prompt, read the answer, spot the failure, paste the next instruction, run the test, paste the error back, and keep steering.
You are still the engine.
His setup uses three primitives:
A goal gives the agent a finish line. Deploy the app, wire CI/CD, check the health endpoint, check the web app, and stop only when the app is live.
A loop gives it a clock. Every 5 minutes, check the PR, read new feedback, fix what changed, and keep going.
A scheduled automation gives it a recurring job. Scan production logs every morning, find errors, reproduce the bug, add tests, and open a PR with evidence.
The best examples are the work devs keep putting off:
> memory issues hiding in production logs
> stale docs drifting away from the code
> GitHub issues waiting for labels
> old tickets ready but untouched
> PR feedback nobody wants to refresh all day
> deployments that need a real health check
The important part is the verifier. The agent doesn't get to call the work done just because it produced output. Tests, builds, health checks, a separate model, or a human review step have to confirm it.
Otherwise you don't have a loop. You have an agent shipping confident garbage on a schedule.
The article below breaks down the full anatomy: verification, memory, maker-checker splits, open vs closed loops, cost per accepted result, and the point where the human still needs to step back in.
The included Fable 5 window ends on July 7, but Johnny Nel's warning is bigger than the timer.
Frontier AI is moving behind gates, meters, caps, and reroutes.
Fable came back with a 50% weekly cap, safeguards that can reroute some requests, and paid-credit usage after July 7.
His play is to use the included slice to build the setup you keep using after the gate drops:
1. Point Fable at your projects and find the few jobs actually worth Fable
2. Stress-test your strategy with your real goals, numbers, tools, and data
3. Make a product ship-ready before users find the bugs
4. Have Fable plan the phases, risks, architecture, and decisions
5. Hand the execution to cheaper models
6. Clean up the repos and scripts that have drifted for months
The line that stuck with me:
frontier for thinking, local for doing.
Use Fable for the expensive thinking:
the plan, the router, the agent blueprint, the architecture, the hard review.
Push the repetitive work to Sonnet, Opus, local models, or anything cheap enough to run without watching the meter.
That is why routing matters now.
Some requests get rerouted. Some jobs are too small for Fable. Some need the full model before July 7 because after that they become paid-credit work.
The article below is the Claude-side setup for that:
the routing rule, the big-job kickoff template, the safeguard warnings, the common mistakes, and the 15-minute plan for getting Fable-quality output without spending the cap on work Sonnet can handle.
@jason_haugh This is useful, appreciate it. I haven’t wired my setup that tightly yet, but the fallback alert idea makes a lot of sense. Going to think through how to apply it.
Fable 5 is back, but the included-in-subscription window ends on July 7.
That changes how you should use it.
The guy is delivering surprisingly useful Fable advice into what looks like a stapler, but the point is solid:
Fable is like the expensive brain in the stack, not the model that touches every cheap step.
His setup is simple:
> use cheaper models to clean up the context first
> turn messy documents into Markdown before Fable sees them
> let Opus 4.8 build the first prompt instead of burning Fable on setup
> use Fable 5 to build or review the plan
> send the execution to Opus, Sonnet, Haiku, or cheaper agents
> keep Fable for the parts where judgment and review actually matter
He says the one day he had access before the shutdown, he pointed Fable at his largest codebase and it found things that had been missed in multiple previous passes.
That is the type of work where the expensive model makes sense:
big context, old decisions, hidden bugs, messy files, and enough surface area for cheaper models to miss something.
I wouldn’t spend the July 7 window on quick chats or random prompts.
I’d spend it on the work that has been sitting in the drawer because it was too annoying to split into twenty sessions:
> the migration
> the giant document pile
> the multi-stage project
> the answer that needs to be checked hard
> the problem Opus kept failing
The article below turns that into the full checklist.
Five Fable 5 use cases worth trying before every serious run starts feeling like a credit decision.