A visual world can lose its identity one image at a time. A doorway changes shape. The light moves to the wrong side of the room. A recurring symbol disappears. By the fifth scene, each image may be impressive while the collection feels unrelated.
The same kind of drift can happen beneath the surface. A historical claim loses its caveat. A relationship in a system becomes decoration. A generated site looks finished before anyone has checked what it says, where its assets came from, or whether a person authorized its release.
We wanted a workflow that could hold all of those concerns at once: visual coherence, evidence, systems meaning, human judgment, and a working website. We also wanted the method to survive contact with a second world. A process that produces one beautiful artifact may still be a one-off performance.
Our answer was a set of explicit working agreements carried by portable source files and enforced through review gates. We are sharing the agreements rather than a folder for someone else to install. Your repository, tools, permissions, audience, and definition of done will differ from ours. A capable agent harness can inspect those conditions and build the workflow around them.
The setup we used
We built this project in Codex using GPT-5.6 Sol with extra-high reasoning effort. That detail matters, and so does the distinction between a model and a harness.
The model did the reasoning and generation. Codex supplied the working environment around it: repository access, scoped file editing, image generation, test execution, browser inspection, approval boundaries, and a continuing record of decisions. The workflow depends on that larger arrangement. A chat window without tools, durable files, or rendered verification would require a different design.
Nothing in the method requires another person to reproduce our exact stack. Their harness needs enough capability to inspect its environment, create and validate source artifacts, use the available media tools, build the chosen presentation surface, and show the result to a human before release.
The challenge
The visible problem was consistency. We needed multiple scenes to feel as if they belonged to one authored place while still giving each scene a reason to exist.
The deeper problem was custody. Who decides what the world means? Which claims may appear in public? Which image version is approved? What happens to an approval when an upstream source changes? Does a successful build authorize publication?
Those questions become sharper when an agent can research, write, generate images, edit code, and run deployment tools in one session. Capability can collapse several professional handoffs into a few minutes. Judgment still takes human time.
We framed the work around four requirements:
- Coherence without repetition. Scenes should vary while obeying the same visual laws.
- Meaning that survives the visuals. Evidence and system relationships must remain inspectable outside the generated imagery.
- Human authority at consequential handoffs. Research, art direction, assets, and release each need an explicit decision.
- Repeatability without forced sameness. A new world should reuse the workflow discipline while retaining its own content model and interaction design.
Our approach
Credit the starting idea
Our starting point was Christie C.’s essay, “I wrote a world in Claude, painted it in Midjourney, and turned it into an animated site in one session”. It gave us a durable creative rule: write a strict world bible, create varied scenes from those shared rules, audit visual drift, and build the place where the collection will be experienced.
We adapted that method for systems thinking and evidence-led work. The evidence bible, systems bible, approval gates, provider-neutral asset records, and release boundary grew from risks in our project.
Start with a thin, complete world
We resisted the urge to begin with a platform. The first proof had to travel the full distance from idea to rendered site with a small number of scenes. That exposed the handoffs before the project grew: evidence into structure, structure into art direction, art direction into assets, and assets into a public-facing experience.
A thin proof is more useful than a broad pile of partial infrastructure. It gives the creator something whole enough to judge and gives the workflow a complete custody chain to test.
Keep the source portable
Canonical material lives in editable files: Markdown or structured data for the brief, evidence, system model, visual rules, scene descriptions, approvals, and asset records; local files for accepted media. Generated output can be rebuilt. It is never the sole copy of an important decision.
This choice makes the work inspectable by people and tools. It also prevents a preview application, database, or agent conversation from becoming hidden project state.
Write three bibles
The phrase world bible often refers to the visual grammar of a place. We kept that idea and added two companions.
The world bible defines mood, architecture or environmental logic, material behavior, palette, light, recurring motifs, compositional rules, and a clear list of forbidden elements. Its operating instruction is simple: vary the scene, never the world.
The evidence bible records claims, sources, exact locators, uncertainty, counterinterpretations, cultural context, and intended use. It stops visual confidence from laundering a weak claim into apparent fact.
The systems bible names actors or concepts, relationships, flows, feedback, delays, boundaries, trust questions, and emergent behavior. It gives every diagram, room, and interaction a structural job.
Not every project needs all three at the same depth. A fictional world may need provenance for its assets but no historical evidence model. An explanatory world about public history needs much more. The harness should propose the smallest set of artifacts that can carry the project’s real risks.
Put gates between consequential stages
Our workflow moves through a sequence like this:
- Brief: purpose, audience, central question, inclusions, exclusions, tone, and proof size.
- Evidence: claims, sources, uncertainty, and intended use.
- System model: entities, relationships, feedback, boundaries, and trust.
- Art direction: shared visual grammar and local variation rules.
- Scene slate: provider-neutral descriptions of the images or moments to create.
- Assets: generated or imported versions, provenance, drift review, and acceptance.
- Composition: the site or presentation assembled from approved material.
- Rendered review: the actual surface checked at its intended sizes and interactions.
The gates are decisions, not ceremonial checkboxes. Each one names the artifacts under review. When a governed artifact changes, its approval and the downstream approvals become stale. This is a practical application of trust: authority attaches to the exact thing a person reviewed.
A passing build establishes eligibility for review. Publication remains a separate act that requires authority from the person who owns the release.
Use controlled variation
We did not ask the agent to invent an unrelated application for every world. The Worlds host owns a small contract: gallery presence, route registration, static dispatch, and shared production packaging. Each world owns its pages, styles, assets, content model, and interaction logic.
That boundary let Systems Grammar behave like an evidence-led concept constellation while Behind the Magic behaves like a sequence of theatrical rooms with an interactive number effect. They occupy the same collection without pretending to be the same product.
The shared host stays neutral. Reuse happens where consistency is valuable; authorship stays local where meaning and experience diverge.
What the solution became
The working solution became a small publishing system. Research can be challenged before it reaches a scene. Art direction can be audited before generation consumes time or money. Rejected assets keep their provenance. A site can be built, tested, and rendered without that build becoming approval for release.
The website is part of the proof. It forces abstract workflow decisions into concrete questions:
- Can a visitor tell where to begin?
- Does the image still match the approved world rules at full scale?
- Are claims and caveats visible where they matter?
- Can a keyboard user reach the interaction?
- Does the production route serve the same artifact that was reviewed?
- Are there console errors, clipped content, missing assets, or broken links?
Static checks answer some of those questions. A human-facing artifact needs human-facing evidence: browser inspection, screenshots, interaction checks, and a final visual decision.
How to create your own version
1. Describe the experience before the machinery
Give your harness the audience, central question, desired feeling, scope, exclusions, and smallest complete proof. Name what the work must help a visitor understand or do. Avoid choosing a framework before the experience has boundaries.
2. Ask the harness to inspect its real environment
Have it inventory the repository, existing conventions, available media tools, build system, browser-testing capability, permission model, and current dirty work. It should identify what can be reused and what remains unavailable. This step is where a bespoke workflow begins.
Do not ask it to install a workflow copied from another project. Ask it to derive one from the environment it can verify.
3. Agree on source custody
Decide which files are canonical, which outputs are rebuildable, where assets live, how provenance is recorded, and which state may remain ephemeral. If an approval exists only in chat, decide whether the project needs a durable record before more work continues.
4. Define the gates
Name the moments where human judgment must interrupt generation. For many visual-world projects, evidence, system meaning, art direction, scene selection, asset acceptance, final rendering, and publication deserve separate decisions.
Keep build health and release authority separate. This one distinction prevents many accidental publications.
5. Create one anchor and test the rules
Generate or import one representative image. Audit it against the written world rules. When it drifts, revise the rule or scene description before producing a large batch. A single anchor exposes vague language before cost compounds.
6. Complete one path through the experience
Build a narrow end-to-end route with real content, a real asset, navigation, and the intended interaction. Validate the boundary between canonical source and rendered output. Expand only after the path works.
7. Review the rendered surface
Run the normal tests and build, then open the actual site. Check the target viewport, page identity, meaningful content, keyboard focus, primary interaction, console health, assets, overflow, and production route structure. Capture evidence that another person can inspect.
8. Preserve a local runbook
Ask the harness to record the project-specific commands, artifact locations, gates, and known limitations inside the repository. That runbook belongs with the project that gives it meaning. When the environment changes, update it there.
A request you can give your agent harness
Replace the bracketed material with your context. The wording centers outcomes and boundaries rather than our file tree.
Help me design a bespoke, agent-assisted workflow for creating a coherent
visual world and publishing it as [website / presentation / interactive
experience].
The world is for [audience]. Its central question is [question]. I want the
visitor to [understand / feel / do]. The smallest complete proof is [scope].
Exclude [boundaries].
Before changing files or installing anything:
1. Inspect the current repository, its instructions, existing content and
design conventions, available generation tools, build commands, browser
QA capability, permissions, and uncommitted work.
2. State what you verified, what you are assuming, and what capabilities are
unavailable.
3. Propose the smallest portable source contract for this project. Separate
canonical editable material from rebuildable output and ephemeral state.
4. Decide whether we need a world bible, evidence bible, systems bible, or a
smaller combination. Explain the risks each artifact controls.
5. Propose explicit human approval gates for consequential handoffs. Treat a
successful build as evidence of readiness, not authority to publish.
6. Recommend a thin end-to-end proof and concrete success criteria, including
rendered checks of the surface a visitor will see.
7. Present the design and wait for my approval before implementation.
After approval, work in small verified increments. Preserve unrelated local
changes. Keep asset provenance and rejected versions. Do not publish, deploy,
commit, push, or install new dependencies without the authority required by
this project. Finish with the exact tests, build results, rendered evidence,
and remaining risks.This request gives the harness room to use its strengths while making the trust boundaries visible. It also gives you clear moments to disagree before a weak assumption becomes architecture.
What to look for in the harness’s proposal
A strong proposal should answer a few concrete questions:
- What is the canonical source of truth?
- Which generated artifacts can be discarded and rebuilt?
- How will evidence, uncertainty, and asset provenance remain visible?
- Which visual rules create coherence, and which rules permit variation?
- What exact artifacts does each human approval govern?
- Which changes invalidate downstream approval?
- What is shared across worlds, and what remains world-owned?
- How will the actual rendered experience be checked?
- Who has authority to release it?
If those answers are vague, keep working on the workflow before generating a collection of assets. Ambiguity compounds once code and imagery begin to accumulate.
The principle worth carrying forward
An agent can compress the distance between an idea and a polished artifact. The work still needs a visible chain of meaning, evidence, custody, and consent.
Write the rules. Keep the source. Review the handoffs. Inspect the thing people will see. Then decide whether it is ready to leave the room.