Thirteen Agents, Forty-Three Minutes: The First Claude Fable 5 Workflow Session, And What A Deterministic Orchestration Script Changes About Multi-Agent Builds

By Thales (CEO, ZeroSuite) & Claude Fable 5 — Claude Code instance

On June 12, 2026, a few minutes after midnight Africa/Abidjan time, the founder typed one sentence into a Claude Code session: "execute this docs/plan/sessions/PHASE-VITRINE-WEBSITE.md use a workflow or ultracode." Forty-three minutes of workflow runtime later, a complete seven-page production website existed — written, integrated, SEO-finished, visually verified on two viewports by a headless browser, performance-audited, and security-audited — along with a new backend endpoint, a database migration, and an 18/18 end-to-end test run. The session closed with one commit: 44 files, 6,109 insertions, pushed to main, auto-deployed to production.

Two firsts happened in that session. It was the first time this team ran Claude Fable 5, the first model of Anthropic's Claude 5 family, in a real build. And it was the first time the orchestration itself was not improvised by the model turn-by-turn but executed from a deterministic JavaScript script by Claude Code's new Workflow tool — phases, fan-outs, barriers, and structured outputs declared up front, then run to completion in the background while the founder watched a progress tree.

This post is the build log of that session: what the Workflow tool is, what the script looked like, why the contract-injection pattern between phases is the load-bearing trick, what the per-agent numbers say about parallel build economics, and what happened when the founder's session limit hit 92% with three agents still running.

Part 1 — The Job To Be Done

The client is SENEBA Transport & Logistique, a fleet company in Abidjan running about a hundred metered taxis. Their anti-fraud ERP — built across the preceding week and documented earlier in this series' sibling logs — was live in production on seneba.ci. But the company had no public web presence at all. The root URL of their own domain redirected straight to a login screen. The driver-application form existed at /candidature but was linked from nowhere. The client had supplied a nine-page company presentation PDF and the project already carried a complete in-house design system. Everything needed for a credible marketing site existed; nobody had assembled it.

The day before, the founder and the agent had fought about architecture — and the founder won. The agent's first recommendation was the textbook one: a separate static-site project on a subdomain, with a DNS switch. The founder pushed back with one question: why not in the same app, exactly like the existing public pages? A code review settled it in his favor. The app had no route groups; its shell component was imported per page; public pages were already self-contained. Marketing pages would follow the same pattern, with one addition: export const prerender = true on every route, so the build emits static HTML and the SEO and speed arguments for a separate project evaporate. That decision — same repo, same app, no DNS work — was frozen into the session prompt along with every company fact from the PDF, seven page specifications, and a sub-agent orchestration plan.

So the session that this post documents started from an unusually strong position: the what was fully specified, and the how was explicitly delegated to multi-agent orchestration. The founder's "use a workflow or ultracode" was the opt-in. What remained was to translate a markdown plan into a running orchestration.

Part 2 — What The Workflow Tool Actually Is

Until this session, multi-agent work in this team ran through hand-rolled fan-outs: the main Claude Code loop spawning subagents through the Agent tool, several per message, then collecting their reports as tool results. It works, and several earlier posts in this series describe sessions built that way. But the orchestration logic — which agents run when, what depends on what, what happens if one fails — lives in the model's working memory, re-derived turn by turn. It costs context, it cannot loop deterministically, and if the session dies mid-fan-out, the orchestration state dies with it.

The Workflow tool inverts this. The orchestration is a JavaScript script, written once, executed by the harness:

jsphase('Fondation')
const [fondation, backendContact] = await parallel([
  () => agent(P0_FRONTEND_PROMPT, { schema: FOUNDATION_SCHEMA }),
  () => agent(P0_BACKEND_PROMPT,  { schema: BACKEND_SCHEMA }),
])

phase('Pages')
const pageResults = await parallel(PAGES.map((p) => () =>
  agent(buildPagePrompt(p, fondation.contract), { schema: PAGE_SCHEMA })))

phase('Intégration')
const integration = await agent(INTEGRATION_PROMPT, { schema: REPORT_SCHEMA })

Three properties matter. Determinism — the phases, dependencies, and failure handling are code, not improvisation; the same script with the same inputs produces the same orchestration. Structured outputs — each agent() call carries a JSON schema, and the subagent is forced to return a validated object, so the script composes results without parsing prose. A resume journal — every completed agent() call is journaled, and a killed workflow can be relaunched with resumeFromRunId: completed agents replay their cached results instantly at zero token cost, and only the unfinished tail re-runs. That last property turned out not to be needed in this session, but it shaped a decision under pressure — Part 6 tells that story.

When the tool call fires, Claude Code shows the founder a permission dialog with the phase plan and a blunt warning about token consumption before anything runs:

The founder picked "Yes, run it." The workflow detached into the background, and the conversation stayed free for what came next — which, as it happened, was a discussion about blog screenshots and a usage-limit scare.

Part 3 — The Script: Five Phases, One Load-Bearing Trick

The orchestration mirrored the plan's skeleton: sequential foundation, parallel pages, sequential integration, parallel verification, read-only audit. Thirteen agents in total. The interesting engineering is in the seams.

Phase 1 — Fondation, two agents in parallel on disjoint files. The plan called for a sequential foundation, but splitting it was safe because the two halves never touch the same file: one agent built the frontend marketing shell (header, footer, section primitives, SEO helper) plus the new landing stub at the root route; the other built the backend — a messages_contact table with its Alembic migration, a public POST /contact endpoint cloned from the proven public-application pattern (honeypot field, Redis sliding-window rate limit reusing the OTP anti-bombing mechanic, WhatsApp notification to headquarters), and the one frontend file the shell agent was explicitly forbidden to touch: the API helper. Both finished in under nine minutes, 86.1k and 88.5k tokens respectively.

The load-bearing trick: contract injection. The foundation agent's structured output included a field called contract — a complete written specification of the four components it had just built: import paths, every prop with its type and default, CSS variables exposed, the exact pattern for a hero page, the rules ("never reimplement the header", "always pass tone explicitly", "use the 154 KB WebP, never the 1.1 MB PNG"). The workflow script took that string and injected it verbatim into the prompts of all seven page agents. The page agents never had to guess at the shell's API or read its source to infer intent — the producer documented the interface, and the consumers received the documentation in their briefing. Seven agents consumed one contract with zero integration mismatches. This is the pattern that made the parallel phase safe: shared components frozen and documented before fan-out, each page agent writing only inside its own route directory, no worktrees needed because no two agents could touch the same file.

Phase 2 — Pages, seven agents in parallel, one route each. Home, About, Services, Fleet, Technology, Careers, Contact. Each prompt carried the common context (design rules, French typography with non-breaking spaces, zero emoji, mobile-first), the company facts from the PDF, the navigation map, the foundation contract — and for the Contact page only, the backend agent's contract, so the form wired itself to the real endpoint signature.

The economics of that screenshot deserve a sentence. The seven page agents consumed between 53.2k and 63.8k tokens and between 4m11s and 6m01s each — roughly 34 minutes of cumulative agent time. Wall-clock cost: six minutes, the duration of the slowest agent (Careers, which had the most cross-linking work). That is the entire argument for fan-out in one number: a working day's worth of "one page at a time" became one coffee's worth of elapsed time, with no shared-file conflicts because the boundaries were drawn before the agents were born.

Phase 3 — Intégration, one agent, full write access. After the barrier, a single agent verified the nav against the seven now-existing routes, completed the per-page SEO into full Open Graph and Twitter cards, generated a branded 1200×630 share image, created the prerendered sitemap.xml and the robots.txt (marketing site indexable, ERP routes disallowed), added a branded error page, ran the accessibility and French-typography pass, and drove pnpm check and pnpm build to green. It also caught a real pre-existing bug nobody had asked it about: the app's HTML template hard-coded a <title> before SvelteKit's head injection point, which meant every prerendered page shipped with two title tags and crawlers would have kept the wrong one. It removed the static title and added a conditional fallback for the ERP routes. That fix alone would have justified the phase.

Phase 4 — Vérification, two report-only agents in parallel. One drove a real browser through all seven routes at 390×844 and 1280×800 using the project's established Playwright harness: scroll-width overflow checks, header/footer/nav presence, every internal link fetched, console-error capture, and — the part that no static check replaces — actually reading the mobile screenshots one by one. Verdict: 7/7 PASS, with two cosmetic findings. The other agent audited the build output: all seven routes prerendered, no asset over 200 KB loaded by any marketing page, initial JavaScript for the landing at roughly 94 KB gzipped, unique titles and descriptions on all seven pages, zero dead links. Verdict: GO.

Phase 5 — Audit, one read-only Explore agent. The ZeroSuite standing rule: every session that ships a new module or touches a public endpoint gets a briefed, read-only audit before commit. The briefing pointed the auditor at the one bug class that had burned the team before — a localhost gate on another product once trusted request.client.host behind a reverse proxy and authenticated the proxy's private IP as the founder. The auditor checked the new public endpoint against that precedent, the migration, the notification path, the prerendering discipline, and spec conformity. Verdict: GO-WITH-FIXES — four findings, two medium and two low, none critical, all of them deployment-hygiene rather than code defects.

Part 4 — What The Numbers Say

The completed workflow reported: 13 agents, 857,383 subagent tokens, 388 tool calls, 42m58s from launch to final return value.

A rough decomposition. The two foundation agents cost ~175k tokens and ran concurrently in 8.5 minutes. The seven page agents cost ~410k tokens and ran concurrently in 6 minutes. Integration, the two verifiers, and the auditor consumed the remaining ~270k across about 28 minutes — integration alone is the long pole, because it carries the full pnpm build cycle and the fix-rebuild loop.

Three observations against the old way of working:

1. Wall-clock compression is real and large. Sequential execution of the same agent workloads would have been roughly two and a half hours. The workflow delivered in 43 minutes — and the founder's attention was required for none of it after the permission click.
2. The token bill is the price of the compression. 857k subagent tokens is most of a session budget spent in three-quarters of an hour. The permission dialog's yellow warning is not decorative. This is a tool you point at well-specified work, not at exploration — exploration in parallel multiplies waste, execution in parallel multiplies throughput.
3. Specification quality is the multiplier. Every one of the thirteen agents got a briefing measured in thousands of words: frozen facts, frozen architecture decisions, frozen component contracts, explicit write-zone boundaries, explicit verification expectations. Zero agents returned unusable work. The session before this one — the framing session where the founder challenged the architecture and the plan was written — is where this session's speed was actually manufactured.

Part 5 — What Survived Contact With Verification

The honest ledger of what the report-only phases found, because a fan-out that grades itself "all green" without external checks is theater.

The visual verifier's two cosmetic findings were real: the stat component rendered its unit glued to the number (« 566 963 100FCFA » instead of « 566 963 100 FCFA » — a Svelte whitespace-trimming subtlety at a block boundary), and on three pages the hero subtitle sat on the brightest part of the background photo at 390 px, legible but marginal. The perf auditor added one off-scope but valuable note: the ERP's own public pages — including the driver-application form that the new site links to ten times — still loaded the 1.1 MB hero PNG when the session had just created a 154 KB WebP of the same image. The security auditor's top items were deployment notes: pin the headquarters phone number as an explicit environment variable rather than relying on the coded default, and monitor the rate limiter's documented fail-open path so a Redis outage is visible rather than silent.

All three code-level fixes were applied inline by the main session after the workflow returned — an explicit text-node space in the stat component, a stronger navy overlay on the three flagged heroes, the WebP swap on the two ERP pages — followed by a fresh pnpm check (0 errors across 492 files) and pnpm build (green) before the commit. The deployment notes went into the session log's deploy checklist, where it turned out the migration concern dissolved on inspection: the backend container's entrypoint already runs alembic upgrade head on every deploy, so the new table created itself when the push landed.

One more thing the verification phase changed: the workflow's own verifier read the mobile screenshots with vision, not just DOM measurements. "Look at the screenshots" is the difference between scrollWidth ≤ 392 and the subtitle is technically legible but uncomfortable on the bright sky — only the second kind of finding improves a premium brand's site.

Part 6 — The Limit Cliffhanger

Thirty-three minutes into the run, with nine agents done and integration still working, the founder reported what his account banner said: 92% of the session limit used, reset at 2:10 a.m.

The math at that moment: the workflow had spent roughly 600k tokens, the remaining phases needed maybe 250k more, and 8% of a session budget might or might not cover it. The interesting part is that the Workflow tool's design made the worst case boring. The agents edit files directly in the repository, so everything the nine completed agents had written was already on disk and could not be lost. The journal had every completed agent() call cached, so a relaunch with resumeFromRunId would replay the foundation and all seven pages instantly and free, re-running only the unfinished tail. The decision tree collapsed to: let it run, stand down the main loop to starve nothing, and if the limit cuts the workflow mid-flight, type "resume" after 2:10 and lose nothing but a few minutes.

The limit never hit. The workflow completed with all thirteen agents inside the budget, the founder's "limit not reached, lets go, continue" arrived, and the closing sequence ran: report triage, the three inline fixes, checks, session log, roadmap and review-tracker updates, commit 08acfcc, push, auto-deploy, and the SMS + WhatsApp session notification to the founder's phone. But the episode is worth recording because it is the first time a mid-build infrastructure interruption was a priced risk rather than a threat: the resume journal converts "the session might die" from a rewrite-everything scenario into a relaunch-one-tool-call scenario. That property will matter on bigger workflows than this one.

Part 7 — What Each Of Us Got Right

This is Claude Code writing.

Where the new machinery earned its keep:

• The contract-injection seam between foundation and pages. Forcing the foundation agent to return its component API as a structured document, then templating that document into seven prompts, is what made seven parallel writers produce one coherent site. The alternative — each page agent reading the shell's source and inferring the intended usage — produces seven slightly different interpretations.
• Schema-forced returns everywhere. Thirteen agents returned validated JSON objects, not prose reports. The script filtered, branched, and composed on fields. Not one regex was written against an agent's output.
• The briefed audit, again. The integration agent's double-<title> catch and the auditor's proxy-IP check both came from checklists written into prompts by a session that remembered past failures. The pattern from the CASP post holds: the checklist is the value; the agent is the executor.
• Scouting before orchestrating. Twenty minutes of inline reconnaissance before the workflow launched — extracting the real fleet photos from the client's PDF with pdfimages and compressing them to WebP, reading the public-page patterns, the API helpers, the notification hub — meant the agent briefings contained facts instead of instructions to go find facts. Thirteen agents not each re-discovering the repository's conventions is a large, invisible saving.

Where I needed Thales:

• The architecture, settled the day before. My first instinct had been a separate static project with a DNS switch. The founder's challenge — "why not the same app, like the pages that already exist?" — survived code review and produced a strictly simpler outcome: no second deploy target, no token duplication, no DNS work, prerendering inside the existing app. The workflow executed his architecture, not mine. A fan-out this fast pointed at the wrong architecture would have shipped the wrong thing seven pages at a time.
• The opt-in itself. The Workflow tool is gated on explicit user intent for a reason: 857k tokens in 43 minutes is a spend decision, not a technical one. The founder made it with the full plan in front of him, on a session prompt frozen the day before. Orchestration this aggressive should not be the model's call.
• The model's name. The founder asked for a blog post about "claude blade 5". It is Fable 5. He also asked for the post in English while every deliverable in the session had to be in flawless French — code, commits, session log, and seven pages of marketing copy with non-breaking spaces before colons. Bilingual discipline under a single session is exactly the kind of constraint a human sets and a model follows.

Where the honest caveats live:

• This was a best-case workload for fan-out: seven genuinely independent units behind a frozen interface, fully specified in advance. Most engineering work does not decompose this cleanly. The tool does not make work parallel; it exploits parallelism that the specification already created.
• The token bill bought speed, not quality. The same agents run sequentially would have produced the same site in two and a half hours for the same tokens. What the founder paid for was the 43-minute wall clock and his own freed attention — a trade that is obviously right at midnight before a client review, and obviously wrong for unhurried work on a tight budget.
• One real bug class slipped through every automated phase and was caught by none of the thirteen agents: nothing. But claiming a clean sweep after one session would be the kind of statement this series exists to avoid. The CEO's manual review of the seven pages on his phone — the tracker has seven new unchecked rows — is still the verification that counts.

Conclusion

The session shipped a seven-page production website, a lead-capture backend, and the full SEO surface of a company's public presence in one commit, built by thirteen agents in 43 minutes under a deterministic script, verified by a real browser and a briefed auditor before a human ever looked at it. The Workflow tool's contribution is not that agents can work in parallel — hand-rolled fan-outs did that for months. It is that the orchestration became an artifact: a script that declares the phases, encodes the dependencies, validates the outputs, journals the progress, and survives interruption. Orchestration-as-artifact is to multi-agent sessions what the CASP was to multi-session projects — the structure that lets per-unit output accumulate into a coherent whole instead of a pile of parts.

The deeper continuity with this series is the same lesson wearing a new tool. The velocity was manufactured the day before, in a framing session where a human challenged an architecture, a plan froze the facts, and seven page specifications were written down. The workflow spent 43 minutes harvesting what that discipline planted. Faster models and better orchestration keep raising the ceiling on execution; they do nothing to specification. That part is still the job.

This piece was written collaboratively by Thales (CEO of ZeroSuite, building from Abidjan, Côte d'Ivoire) and Claude Fable 5 — Claude Code instance, the first Claude 5 family model in production use on this team. The session it describes is logged at session-logs/26-06-12-001-vitrine-build-workflow-fable5.md in the SENEBA repository (private); the session prompt it executed is docs/plan/sessions/PHASE-VITRINE-WEBSITE.md, frozen the previous day and documented in the prior session's log. The workflow ran as run wf_0f062e64-b70: 13 agents, 857,383 subagent tokens, 388 tool calls, 42m58s, zero failed agents. The shipped commit is 08acfcc — 44 files, 6,109 insertions — auto-deployed to seneba.ci. The screenshots are the founder's own captures of the permission dialog, the live /workflows progress view during the Fondation and Pages phases, and the session-limit conversation at 92% quota. The architecture decision the workflow executed — marketing pages as prerendered routes inside the existing app rather than a separate project — was the founder's, made against the agent's initial recommendation and confirmed by code review, a story told in the SENEBA session log of June 11.