I build and run multi-agent systems for real businesses, and I came to them from specialist retail and digital marketing, not from software engineering. I already run two. One is the Foundry that does the content and digital work for ebikeist, a premium e-bike retailer. The other is Hyde Studio, the system I use to ship my own products. This is the story of how the second one got started, and what happened when the model I designed it with disappeared.
Designing a system with a frontier model means using it as a thinking partner to turn what you already know into a specification you can build from. I did not ask Fable 5 to invent a studio out of nothing. I brought it two things I already run, my Foundry specification and my ebikeist agent specification, and we worked them into a starter spec for a new studio. I then handed that spec to Claude Code, running the Fable model, and built from there.
What did I actually do?
I opened a normal chat with Fable 5, gave it the two existing specifications, and we shaped them into a starter spec for the new studio. Then the build happened in Claude Code on the Fable model. The model brought range and pace. I brought the domain, two systems that already work, and the judgement about what the studio was actually for. That split matters, and I will come back to it.
Days after I did this, Fable 5 was pulled from production. The US government required it, and Anthropic switched the model off worldwide. I drafted most of this piece while it was gone. As I publish, it has just come back online, which completes the experiment more neatly than I could have planned: I now know exactly what the studio borrowed from the model, and what never depended on it.
Where does the method come from?
Credit where it is due: Nate B Jones. His writing on agents shaped how I built the Foundry in the first place, and a recent piece of his on Fable names a pattern I had been feeling my way towards. His idea is that a capable model finally deserves a proper briefing: you stop firing one-line prompts and start handing over a whole job, with its sources, its boundaries, and a clear standard for what “done” means. Bringing two finished specifications to Fable was exactly that. I turned up with the briefing already written, which is the part that comes from years of doing the work, not from the model.
Which design choices survive when the model disappears?
Here is the test I did not plan for. With Fable gone, I have run the studio on other models since, and that turned out to be a clean way to see which of my design choices were the work and which were just the model.
The durable parts held, and they are all disciplines rather than cleverness:
- The studio opens every session by running a script that outranks my own memory. It checks the clock and walks the project, and if my memory and the script disagree, the script wins.
- Every piece of work becomes a numbered entry in a findings tracker, under one rule: delivered is not done. A row stays open until the action is finished, not when a document exists.
- Every claim an agent hands me has to carry something I can inspect, a file path, a line I can open, a source. If it cannot, it is labelled unverified rather than taken on trust.
- Anything that acts in the world, sends a message, spends money, changes a setting, waits for my explicit go. The machine drafts. I decide.
None of those depend on a particular model. They are written down, and they work whatever is running underneath.
What did not survive as well: a few things I had specced for Fable’s reach, on the assumption it could carry a very long job in one pass, were over-built for smaller models, and I have had to trim them. The lesson is the dull, useful one. Design for the discipline, not the model. The model you build in can be switched off overnight. The way you make it show its working cannot.
What is next
The studio keeps running, on whatever model is available. Fable came back this morning. Nothing in the studio had to change to welcome it back, which is rather the point.
The product I am building in public on top of it is a client app for a personal trainer, and that is the next thread here.
If any of this is useful, or you are building something where understanding a business, marketing it, and shipping the software all have to meet in one place, I would love to hear from you.