I increasingly judge an agent session by what remains after it ends. An answer can resolve today’s uncertainty. A working SaaS feature, animation library or video pipeline can keep producing value after the original inference has been paid for.
I am buying both today’s output and, sometimes, the means of producing tomorrow’s. I use capital assets here to mean retained productive capability. Saving a file is only the beginning: it needs a useful purpose, a way to find it, and a dependable way to use it again.
Reviewing my local repositories from the last month made that distinction concrete. The clearest examples span Octospark’s product state, Trace Learn’s Blender library, animation configuration and automated video production.
A useful asset can be small
In Octospark, image enrichment generates an editable description and saves it with the media asset. Later publishing adapters can reuse that alt text, apply destination limits and respect an explicit override. I do not need to ask a model to describe the same image on every publication. The retained value lives in useful product state and the code that handles it.
I also ported an Agent SDK content engine from Trace Learn to Octospark. The runner, queue and bounded repair stages are machinery. The 23 markdown articles subsequently committed are outputs. Their existence demonstrates production and reuse, not readership or commercial success.
A finished feature can be a better investment than another generator. I still need to judge descriptions, correct mistakes and maintain the product. Durability comes from continued usefulness.
Blender makes the conversion visible
Blender is unusually suited to this loop because its Python interface turns structured instructions into inspectable geometry, materials, rigs and animation. I can retain the recipe, export the asset, inspect the result and improve the same source.
Trace Learn now has registered asset packs with candidate builds, exported-geometry checks and source hashes. Its 10 September delivery report records 55 new scene configurations using seven new GLBs alongside existing characters and props. That is composition doing useful work. The boundary matters: these are prototype configurations, 27 received developer visual review, and measured learning benefit remains unproven.
The asset base also preserves options. Blender exports glTF, and Bevy has a glTF scene loader. I can target React Three Fiber now and investigate Bevy later. Portability still requires compatible materials, rigs, units and clip conventions; a GLB does not transport application behaviour. I have not validated these assets in Bevy. (Blender exporter, Bevy loader)
I keep geometry and performances in the authoring layer. The runtime owns state, interaction, lesson rules and sequencing. The retained investment includes the contract between them.
Animation configuration is authored knowledge
A locomotion contract is more than a bag of tuning numbers. It records what a movement means and which physical cues should express it. This shortened excerpt comes from the current library:
{
"id": "walk.slowly",
"strideDistanceM": 0.54,
"durationSeconds": 1.8,
"cues": [
"unhurried even steps",
"neutral upright body",
"continuous ground support"
]
}
I can reuse that performance across compatible characters and scenes. The source also distinguishes pace from emotion: quickly does not automatically mean frantically, and stomping does not automatically mean anger. Those decisions are durable domain knowledge.
Configuration becomes valuable when a real consumer interprets it consistently. Otherwise I have only moved ambiguity from prose into JSON. I want a catalogue entry to retain the source recipe, accepted version, compatible rig, named clips and review scope. That makes reuse an informed choice instead of another investigation.
Spend inference before playback
My video lab follows the same pattern: agent drivers create and repair bundles, while saved narration, scene configuration, components and review records survive the run. The renderer can consume accepted inputs without asking an agent to rediscover the lesson every time.
For notebook-based course videos, I want to execute the demonstration first, retain its outputs, then compose narration and visible actions against a fixed timeline. That notebook pipeline is still a design direction in the inspected course repository. The working video lab is a separate implementation.
A saved timeline turns an expensive creative decision into a repeatable production input. A narration change may require new timings, and a layout change may require another render. Neither should automatically require repeating every upstream model call.
A small Codex SDK loop
I added a runnable companion example that composes a six-second animation manifest. This is the central SDK call, with the surrounding schema and validator kept in the full file:
const thread = codex.startThread({
workingDirectory: outputDir,
skipGitRepoCheck: true,
sandboxMode: 'read-only',
approvalPolicy: 'never',
webSearchMode: 'disabled',
networkAccessEnabled: false,
})
const turn = await thread.run(prompt, { outputSchema, signal })
const manifest = validate(JSON.parse(turn.finalResponse))
The host checks clip names, frame coverage and the final hold. It permits one repair turn, shares a deadline across both SDK turns, and saves accepted JSON with a receipt. I ran it against a live Codex session, then replayed the resulting 180-frame schedule with zero model calls. It demonstrates timing validation, not a rendered character or a teaching-quality assessment. (Codex SDK, runnable example)
For such a tiny fixed lesson, I could write the JSON myself. The example demonstrates the boundary: inference authors a candidate; ordinary code validates, stores and reuses it.
Let real deliveries earn the machinery
The tempting mistake is to rank every factory above every asset. A general generator can cost more to understand, maintain and repair than the next ten finished outputs.
My video lab already has a sensible promotion rule: extract a component when a second video uses or clearly needs it, or when it is already generic within the domain. I would apply that discipline to props, SaaS tooling and agent scripts too.
I fund machinery when I can name the next consumers and the repeated work it removes. I favour direct asset work while requirements are still moving. I fund maintenance when an existing lesson, export or workflow becomes unreliable.
The useful comparison is expected reuse savings and added capability against build cost, upkeep, integration and delayed delivery. File counts and tokens spent cannot settle it. The measures I care about are accepted outputs, actual reuse, repair time and time to the next useful release.
Every machinery improvement should name the next asset it will help deliver. Every asset should reveal whether more machinery is warranted. That balance lets today’s inference improve tomorrow’s production without turning preparation into the product.
