AI & Rendering | Goals, Revisions, Rules: How to Organize Long-Running Agent Work

Near the end of the project, I set a goal shortly after midnight and went to bed. By 02:46, two interior images had finished rendering at full resolution. At 02:52, the agent presented them with a check report. The image above is one of them, exactly as it was produced that night, without any feedback from me on an intermediate state.

What makes this possible is the goal feature in Claude Code. You set a condition with /goal, and the agent works until it is met. At every stop, an automatic check called a hook tests whether the condition holds and otherwise sends the agent back to work. To me that is a blessing. I sleep, and the work continues anyway.

Getting to my acceptance still took some corrections after that.

After Part 1 and Part 2, this third part shows what must be in place so that an agent can work alone for a night and arrive at a usable result: files, rules and goal documents.

This part is more technical than the first two. If you do not work with coding agents yourself, you can skim the excerpts from the documents: the story of the last night and the final section stand on their own. The excerpts were written in German and are translated here.

#A scene is a program

The most important technical decision was made on day one. The agent never edits the Blender file by hand. It writes a Python script that loads an existing state, makes one change and saves the result under a new name. Every revision therefore consists of four things: a build script, a new scene file, one or more verification images, and a report.

My experience told me this was the right decision. For working with agents, it is the only one that matters. Programming interfaces are the alpha and the omega of working with AI, and nothing works without them. That is the new yardstick for any kind of software we work with. It is also how I now choose software when we buy it for our company. Does it have an API, does it have an MCP server, meaning an interface built for agents, or can it be addressed in some other way so that an AI can work with it? If not, it is usually out.

Like any software project, this one accumulated technical debt. After five days I called the state of things a patchwork and asked whether we had been piling it up. The answer was a list, starting with ground surfaces at three different heights on top of each other. Each individual fix had been plausible on its own. Together they produced a scene in which nobody could say anymore which object was causing a visible defect.

#Rules that come from mistakes

Out of that inventory, a new AGENTS.md came together, the rules file every agent reads at every start. I had given the agent the topics: naming, script structure, storage location, render rules and the lifecycle of an iteration. It wrote the rules itself, from the mistakes of the preceding days.

A few examples, each with the mistake the rule comes from:

Revisions are named R<number> <short purpose>, and model, scripts, images and reports carry the same identifier. Before that, files had names like “Dusk balance 16” or “Final set 82”, and an image could no longer be matched to a model state.
Files are only called “final” once acceptance is actually complete. “Final set 82” had never been accepted. Consultants who are calling their slide deck “final” for the third time are allowed a smile here. There really are systems that stick to this rule.
A script never overwrites its source. The target must be new; otherwise, the build aborts.
Objects are selected by explicit role, never by parts of their name. A name search for paved surfaces had also caught window sills, doors and furniture.
There is exactly one active version per component. No growing stack of hidden correction layers.
A linter checks every script before the build. I had asked whether something ready-made exists before we write it ourselves. It does.

Then there is a fixed sequence for every iteration. Two sentences from it: assumption and proof are recorded separately, and a passed sub-test explicitly does not count as a solved problem.

On day one I could not have written any of these rules. What made sense was to record them while the mistake was still fresh, in a file that every agent reads at every start.

#One task list

After a few days there was a work plan, a dated task plan, a progress log, and open items that lived only in the chat history. I reduced that to one file: TODO.md in the working root, with a fixed structure. Programmers know a file like that as their roadmap.

Current state: input model, active revision, last check actually passed, next concrete step.
Tasks with a stable ID, status, success criterion and a link to the verification results. Three states: open, in progress, done.
A short iteration log: hypothesis, change, checked image, result, decision.
Open assumptions and decisions that I have to make.
The next one to three steps.

Two sentences from that specification proved especially useful. The first: “A render that has been started is not done.” The second concerns the log: “Also record failed and discarded approaches, so they are not tried again blindly.” When the conversation history is condensed, the agent can lose track of failed attempts and repeat them unless they are recorded.

The list has a second purpose. When I wanted to know in the morning where we stood, I read this file and not a chat history.

#The switch from Codex to Claude

I was not satisfied with the visual results from GPT-Astra. I looked on arena.ai to see which models are rated well for visual tasks and decided on Claude Opus. The logs show two further factual reasons: four failed attempts at the same defect, and the accumulated technical debt.

The switch also exposed a documentation problem. My own inventory from that evening had a section headed: “Exists only in our context, not in a document.” Essential knowledge about the project lived only in the chat history of a single session. Switching agents forces you to write that knowledge down. I should have done that without a switch as well.

Codex wrote the handoff prompt and all later /goal prompts, because Codex had the full context of the project. So there has to be a structured handover, as with an employee. You would not put even a good apprentice on your next big task without a handover either. My instruction for it was short:

In general you have to assume that the agent starts at zero, has not worked on this project before and therefore has no context.

Two subagents reviewed the draft. One found five traps that had not been mentioned in any chat, including a build script that required a file deleted long ago.

#The goal document: guardrails for the agent

At its core the result defines guardrails, and guardrails are the essential part of agentic work. In programming, they are familiar. Here you can see how to write them for a visual task. The parts that had the most effect:

The opening says what the agent should not do.

You are taking over an existing architectural visualization for Oliver Borchers. You are working on completion, not on a new project and not on another general planning round. You have no chat context. This briefing and the local documents listed are your entry point.

Anyone who takes over someone else’s project tends to start with an analysis and a new plan. We already had both.

Freedoms and limits stand next to each other. The agent may change materials, lighting, sky, camera settings and furnishings. In the same paragraph the document names the limit: the house’s overall shape, roof, openings, scale and position must stay unchanged, and the trees must remain approximately where they are. Without that limit, an assignment to “make it prettier” would leave open whether the house itself may be rebuilt.

Known traps are named. One script was named like a harmless check but actually launched renders and changed lights and cameras along the way. Only someone who was there knows that. A new agent would have run it without suspicion.

Each work package has several acceptance criteria that must all be met. The lawn edge from Part 2 had failed four times. The conditions for that package therefore include:

No grass over or on paved surfaces.

Geometry of the house and of protected paved surfaces unchanged […].

Below that it says: “No mere score in place of the proof.” Every line of that list is a defect we had actually seen before.

A rule against piling on patches.

After no more than two unsuccessful attempts aimed at the same defect, interrupt the sequence of patches, review hypothesis and measurement, and choose a better-founded approach. Do not give up the assignment after two attempts; change the method.

Claude applied that rule three times in the first night. The first time, after two unsuccessful fixes, the agent switched from trial and error to measurement and found the error in its own script.

“Done” is defined, and self-assessment does not count as acceptance.

Do not round every image up to 85. Technically checked, actually visually checked, and accepted by Oliver are three separate states. Self-assessment is not an external award.

#After the first night with Claude

My first image critique to Claude came after a good nine hours of autonomous work. I noticed that the street lamp in the night image cast no cone of light onto the ground. The cause: a wrongly rotated spotlight that shone upward.

The lantern was literally radiant, just in the wrong direction. An AI simply does not notice something like that.

The real problem in this phase was speed. Five to ten minutes of waiting per intermediate image makes every round of image critique sluggish. It is the same everywhere in agentic work: you need fast, repeatable feedback, otherwise every feedback loop becomes a bottleneck. So I took a detour and had the whole working pipeline reworked, with a single goal: small images and fast answers.

The agent wrote a preview service that loads the model once and renders only the crop in question. 110 seconds for a full check image became just under 8 seconds for a crop. The rule went into the AGENTS.md only after the gain had been measured.

#The interior goal: two images overnight

This part is really complete nonsense. Nobody needed it, and for my original question it is entirely superfluous. I did it anyway because I thought it would be pretty cool to try. And this second goal document shows most clearly how direct the path from a goal to a result can be.

To finish, I wanted one or two interior views of a living room. My instruction to Codex was vague: high quality, modern, perhaps in a charming beige, no arbitrary stock assets, and please research first. I had no desire for a completely beige millennial room, though. There are more than enough of those already. So the room needed a few color accents.

Here too, Codex wrote the prompt for Claude and organized my brief into ten sections. Three features shaped the work.

It separates what is binding from what is a proposal. My aversion to beige became an acceptance criterion, the agent’s color idea a recommendation. The document says: “A room that is still monotonously beige does not pass the design acceptance even if all materials are technically correct.”

References have a limited purpose. For each of the three researched architecture projects, the document says what is carried over (the interplay of materials) and what is not (room layout and details that do not fit our floor plan).

It fixes the order: dimensions, placeholders and camera first, then materials and lighting. Styling only once the architecture works.

The long document stayed in place as a file. The /goal input received only a short version that points to the file. Its section on design reads:

A modern, high-quality, livable room with personality. Warm oak, sand and cream form the base. Deliberate accents in color, form and material are binding: no uniform or washed-out beige room. Proposed as a direction are petrol or smoky blue, darker wood, a light fixture with character and a small rust or wine-red accent. […] Select a few excellent pieces of furniture that suit the small floor plan. […] No arbitrary complete sets.

Put that paragraph next to the overnight image. The oak floor and sand-colored sofa follow the goal’s base palette. The rust cushion and the petrol print provide the requested color accents, and the floor lamp is the light fixture with character.

Just under three hours after the start, both images were ready, along with a check report and the agent’s own critique.

That night, a check script written by the agent caught errors I would never have seen in the images, because they were fixed before rendering. Because of an import error, the doors of a sideboard were lying several meters away in the garden.

When I woke up, the work was essentially done. My feedback in the morning concerned details: a ceiling beam that does not exist in the real architecture, cushions that intersected each other, plus wishes such as a small coffee corner and a folded blanket on the sofa. The first blanket the agent downloaded for that was called an alpaca blanket and turned out to be a toy figure.

Getting to acceptance then took four more passes of the final render. I stopped the first one myself because I noticed a black window lintel I had overlooked before.

#The mistake in my goal condition

In both goals, technical completion and my approval were to be reported separately, but the goal conditions still depended on my approval.

For the exterior set, Claude presented six previews and asked for my visual approval before the expensive final render. That is exactly what I had ordered. The hook only saw that no final images existed yet and sent the agent back to work seven times. It refused seven times, on the grounds that my instruction takes precedence over continuing automatically.

During the overnight interior work, the same loop repeated eleven times. The images were ready for review at 02:52, but the condition required my approval, and I was asleep. The first time, the agent pointed out that it could not give itself that approval. It sent a single notification, changed nothing more in the model after that, and waited. It was more patient about it than I would have been.

I think the agent behaved correctly and the mistake was mine. A goal condition should only contain what the agent can produce itself and a machine can check. A human’s approval belongs in the process that follows.

#The numbers

All figures come from the session logs and the project files.

Metric	Value
Active agent time, Codex	about 30 hours, of which about 19 after the research
Active agent time, Claude	about 21 hours
My messages	more than 300
Last revision number	R166
Final images	7 exterior, 2 interior
Purchased assets	none

All assets were free. Some of them may be shown in renderings but not passed on, which is why I cannot publish the editable scene.

Both agents ran on my existing subscriptions. The project itself incurred no further costs. I did not measure my own time. For the rework after the criticism I estimate it at three to four hours, spread across many short pieces of feedback.

#What this shows and what it does not

The images turned out well. I have not compared them with a specialized studio’s work. A 3D artist with 17 years of experience wrote under my second post that every generation of tools has been mocked by the previous one, and that he had long since set up an agent of his own for exactly this kind of work. To him and to everyone else who commented positively and constructively: thank you. That is exactly how it should work.

What counts for me is that this visualization would never have existed without agents. There was a private project for which commissioning someone would not have paid off, and now there are images. That is what AI is about.

Toward its end, the second research report contains a sentence that describes my role in this project well:

The bottleneck is therefore increasingly no longer access to the technology, but taste, selection, observation and art direction.

That week I looked at images, named defects, found standards to measure against, stopped work, had goals written down and recorded rules. Responsibility for the result stayed with me the whole time. I first spotted the backward-facing patio chairs, the street lamp without a light cone and the knee intersecting a table strut in the images, before any check existed for them.

At its core, this project is a study in how to structure your work with AI. It is always an iterative process: hypothesis, test, next step, feedback.

If you hand longer work over to an agent, I would start with these things:

Research first, especially when you are trying something new with AI. Someone has very likely done something in that area already.
Choose your tools so that they make it easy for the agent, whether through the software itself or through its interfaces.
Establish clear, concrete workflows: a rules file, a task list, traceable revisions.
Have the goal document written by the agent that has the context, and write it for a reader with no history. Everything that exists only in the chat is lost when agents change.
Separate what is binding from what is a proposal, and name freedoms and limits in the same paragraph.
Name known traps, especially tools that work differently than their name promises.
Define quality criteria alongside acceptance criteria, as you would in software development, each one from a defect you have already seen.
Whatever can be bounded by static analysis, bound it that way. One example is the share of black in an image, which must not exceed a threshold.
Always use a different agent for reviews than the one that did the work.
Include a rule against piling on patches. Two unsuccessful attempts, then change the method.
Put into the goal condition only what the agent can produce itself. Your approval is not part of that.

#Tools and sources

Software: Blender 5.2.1 LTS with the Cycles renderer; Blender MCP; Ruff as the linter for the scene scripts. Everything was computed on a MacBook Pro M1 Pro with 16 GB.

Agents: Codex with GPT-Astra for the setup and the first rework, Claude Code with Claude Opus for the polish and the interior.

Geodata: OpenGeodata.NRW with parcel geometry, digital orthophotos and LoD2 building models.

Assets: Poly Haven and ambientCG for HDRIs and materials, BlenderKit for individual models.

Research: Two deep research reports on architectural visualization in Blender (Claude and ChatGPT), plus shorter reports on individual questions.