An Animated Assembly from One Astra Task
The agent found an export defect between the poses our planned review would have checked
Astra built the animated crank-slider below from one brief, then found a defect that our planned review would have missed. The rod separated from its pin between saved frames even though the key poses looked right. The agent corrected the export and checked it again.
The task put the delegation idea into a concrete assignment: deliver an editable scene and a working browser viewer, with the production steps left open. The handoff included USD, materials, a Blender source and the viewer.
My coordinating assistant prepared the brief and ran the fresh tool-using task. The producer took 16 minutes 7 seconds, including its inspections and corrections. Preparing the environment and reviewing the submission took additional work outside that time.
Watch the recorded orbit insteadHide the recorded orbit
Open the interactive assembly to orbit, zoom, play, pause and scrub the motion. The source and delivery bundle includes the editable scene and local viewer. The source and recorded evidence are on GitHub. The public bundle includes portable launch instructions and documented privacy changes to local paths and file metadata; the evaluated USD and GLB are unchanged.
The brief left the production choices open
The task asked for a rotating crank driving a connecting rod and a slider on a straight guide. It specified a 35 mm crank radius, 110 mm rod pin spacing and one full turn every four seconds. Blue structure, metallic linkage, an orange moving component and dark rubber feet made the material choices visible.
USD stands for Universal Scene Description. It provides a common way to represent and exchange a scene’s objects, geometry, material relationships and properties that change over time. The OpenUSD introduction explains that scene model and its editing and composition capabilities.
The brief required a scene I could revise:
An editable USD scene with named parts, materials, animation, explicit metre scale and timing metadata. Keep the working source file and generator so I can revise it.
The exact brief also required a local viewer, an actual scene render, rebuild instructions and a record of the checks. It explicitly asked the agent to inspect and correct its work. Geometry beyond the stated dimensions, lighting, modeling method and browser implementation were left to the producer. No finished 3D asset or prepared scene was supplied.
The coordinating assistant supplied the detailed brief, installed tool environments and assessment plan. The producer received those inputs in a fresh workspace, without the earlier articles or harness source. The run record identifies the requested model as gpt-6-astra, with high reasoning effort, on September 20, 2026. The service did not report an immutable backend model snapshot.
One task included failed exports and corrections
The first USD export had an angle-interpolation problem halfway through the cycle. Blender had exported xformOp:rotateXYZ angles that wrapped from positive to negative values near 180 degrees. Interpolating those scalar values made the crank take the long way around between neighboring frames. A saved pose could look right while an intermediate pose separated the rod from its pin by about 70 mm.
The producer found that during subframe readback. It changed the USD rotation values to a continuous 0-to-360-degree sequence and reran the check. Its final script sampled 961 times. The initial failure and final report are retained in the delivery notes.
That repair applies to the authored Euler-angle sequence. USD uses spherical interpolation for quaternion values, but changing representation alone cannot recover an omitted full turn. Intermediate orientations still have to encode the intended motion.
There were other corrections: the USD display rate and time-code rate were made consistent, and three separately exported animation clips were replaced with one synchronized GLB clip. The viewer’s own check had rejected the three-clip export.
The retained export failures let me trace these problems to tools and representation choices during production. I would diagnose those causes before calling them hallucinations. The record covers one agent task, including its internal corrections. The coordinator made no edits to the submitted scene, generator or viewer and did not need a second producer attempt.
What the separate acceptance step established
Before generation, the coordinator fixed nine inspection times, every half second from zero through four seconds, and a 0.5 mm tolerance for the specified relationships. After submission, it froze the files and checked the saved delivery against those requirements. These are separate checks within the same coordinated exercise, not independent validation.
The measurement report retains the samples and tolerance. Those half-second samples land on authored frames, which explains why they would have missed the intermediate rotation-wrap defect. A separate review was useful, but its sampling plan was less thorough at that point than the producer’s own check.
Scroll sideways for more columns.
| Requirement | Observed result | Boundary |
|---|---|---|
| Editable scene and clock | USD opens with metre scale, named parts and a four-second range. Source and generator are present. | The coordinator inspected the source handoff; it did not reproduce the entire build in a second clean installation. |
| Distinct material delivery | Seven materials resolve; the four requested surface categories are visibly distinct in the render and viewer. | Full USD shader compliance remains incomplete because the checker environment lacks the standard shader definitions it needs. |
| Specified motion | Radius, pin spacing, guide alignment, rod endpoints and phase passed at the nine planned times. Loop endpoint poses match. | Those samples do not certify the whole path, collisions or physical behavior. |
| Browser handoff | The delivered GLB loads; orbit, zoom, play/pause and timeline controls work at desktop and mobile sizes without runtime CDN requests. | USD and GLB pin positions agree at the sampled times after accounting for their different up axes. That does not establish full equivalence between exports. |
I also ran a selected Scene Acceptance profile against a copy of the frozen USD. Composition and stage metadata, four material bindings and the four-second duration passed. The harness report says ACCEPT_FOR_USE for that selection. It does not include the separate kinematics and browser checks, and it does not clear the unresolved full shader-compliance check. The profile used the version 0.4 development timing pack; its mapping to the delivered part names was configured after submission.
What the USD and the rest of the delivery contained
The corrected motion was part of a handoff I could inspect and revise. The source files and named scene structure matter because the next request may change a dimension or require another export.
In this delivery, the USD held 107 polygon meshes under named assembly parts, seven bound materials and animated transforms for the crank, rod and slider. It declared metre scale and Z as the up axis. Its time range was 0 to 240 at 60 time codes per second, giving the required four-second cycle. The scene was delivered as both binary .usdc and text .usda; the producer checked that they described the same scene.
I can address a named part, read its saved position at a time, resolve its material and compare those values with the brief. The text USD makes the authored structure inspectable, while the saved-scene readback records what the coordinator found in the binary delivery.
Scroll sideways for more columns.
| Delivered artifact | What it is for |
|---|---|
crank_slider.usdc and .usda, with the referenced environment file | Editable scene handoff: named geometry, material bindings, units and saved motion. Keep the dependency with the scene. |
crank_slider.blend, generator and USD finalizer | Working source and rebuild path. The finalizer preserves the corrected timing and angle representation. |
crank_slider.glb and local viewer | Browser delivery. The viewer plays the exported animation and lets a reader inspect it from different angles. |
| Render, README and diagnostic logs | Visual review, launch/rebuild instructions, producer checks and a record of unresolved issues. |
The browser on this page loads GLB. Checking that view therefore cannot establish that the separate USD handoff is correct. Both exports need checks appropriate to their use. The Blender overview also uses different lighting from the browser, so matching material assignments does not imply pixel-identical appearance. The USD contains editable polygon geometry; this delivery was not a CAD solid model or a physically validated assembly.
The tools behind the handoff
Astra used Blender 4.5.12 LTS to model and render the assembly, then exported USD and GLB. OpenUSD 25.11 supplied the saved-scene readback that exposed the angle problem. Three.js supplied the browser viewer; Playwright exercised its controls, and the glTF validator reported zero errors or warnings, with 105 informational unused-UV notices. The workflow record retains the commands and versions.
Python, Blender/OpenUSD, Node and browser automation were available at the start. The producer fetched Three.js and the validator into its workspace and chose how to use them. Provisioning the whole environment was not part of its autonomous work.
The source includes a specialized generator, so I can change a dimension and rebuild. That gives me a usable handoff even if I choose to handle the next request with a script instead of another agent task.
Follow this assembly through the evaluations
- Geometry: the 35 mm crank radius and 110 mm rod spacing passed the sampled reference-point comparisons. Mesh interference and manufacturing clearance remain untested.
- Materials: four selected bindings passed. Appearance and physical contact properties require different evidence.
- Motion: duration passed; the producer found and corrected an interpolation defect between our planned samples.
- Physics: a later inspection found no authored rigid-body simulation configuration in this delivery. A dynamics task would need additional modeling and evaluation.
The small tray, panel and block fixtures in those articles remain the runnable controls for specific evaluator behavior. They are separate from this recorded producer delivery.
What I would change in the review
The coordinator’s nine planned times all landed on authored frames. The producer’s subframe check found a defect those samples would have missed. I would keep the separate acceptance step, but change what it measures: named attachment points at times that exercise interpolation, with deliberately broken motion beside the valid delivery.
The later connection check, now included in release 0.5, used the unchanged assembly at 481 times per connection. Its largest gaps were about 0.003005 mm and 0.000955 mm against a 0.5 mm allowance. A separate copy with an injected 1 mm rod offset failed. That offset was an evaluator control, not a defect in Astra’s final submission; the public bundle remains the September delivery.
This is one recorded production task, including its own corrections. It gives me an editable artifact and a weakness the later connection check addresses. It does not yet tell me how often this workflow succeeds or whether it costs less than a dedicated mechanism script.
Disclaimer: The views and opinions expressed in this account are those of my own and do not represent those of my employer, NVIDIA.