aDSL: Agentic 3D Creation via Joint Agent-Program Design

What Changed

For years, the promise of text-to-3D generation has been hampered by a fundamental mismatch between how Large Language Models (LLMs) reason and how 3D geometry is represented. Traditional approaches often force LLMs to output absolute coordinates—specific floating-point numbers defining vertices, edges, and transformation matrices. This is a brittle approach. LLMs are inherently semantic engines; they excel at understanding relationships (e.g., "the chair is on the floor," "the handle is attached to the door") but struggle with the precise, high-entropy numeric values required to construct valid 3D geometry. When an LLM hallucinates a coordinate, the resulting mesh often contains floating geometry, non-manifold surfaces, or structural incoherence.

aDSL (Agent-centric Domain-Specific Language) fundamentally changes this paradigm by shifting the burden of precision away from the LLM and onto the language design itself. Instead of forcing the model to guess absolute coordinates, aDSL provides a set of relational operators that allow the agent to describe geometry in terms of spatial relationships and composability. This co-design approach—where the language is built specifically for the agent, and the agent is built to understand the language—allows for the creation of 3D objects that are not only structurally sound but also inherently editable and interpretable.

Technical Details

The core innovation of this research lies in the synergy between the language syntax and the multi-agent execution architecture. The system moves away from monolithic generation toward a Plan-Execute-Critic loop, which decomposes complex 3D requests into manageable, verifiable steps.

The aDSL Syntax

The language is designed to prioritize semantic logic over numeric precision. In a traditional programmatic 3D system, an agent might be asked to place a cube at coordinates (0.5, 1.2, -0.3). In aDSL, the agent instead uses relational operators. For example, rather than specifying an absolute position, the agent might define a relationship: attach(part_A, part_B, face="top"). This abstraction layer allows the underlying engine to resolve the specific coordinates based on the geometry of the objects involved. By focusing on composability, the language ensures that the generated code remains readable and, crucially, modifiable by human developers after the generation process is complete.

The Multi-Agent Architecture

The system employs a role-specialized multi-agent framework to handle the generation process. This is not a single model attempting to output a perfect file in one pass. Instead, it utilizes a structured workflow:

1. Planner: This agent decomposes the high-level user prompt into a sequence of aDSL commands. It handles the semantic understanding of the request, determining the necessary components and their hierarchical relationships.
2. Executor: This agent translates the plan into executable aDSL code. It focuses on the syntax and the correct application of the relational operators.
3. Critic: This is the feedback mechanism. The Critic agent receives the output of the execution, including any errors or constraint violations. It evaluates the geometry for validity and structural integrity. If the code fails to produce the desired result, the Critic provides specific feedback to the Planner and Executor, initiating a repair loop.

This iterative process allows the system to correct its own mistakes without requiring additional training or fine-tuning. The training-free nature of this system is a significant departure from previous methods that required extensive datasets of 3D programs, which are notoriously difficult to curate and scale.

Developer Implications

For developers working in 3D pipelines, this approach offers a shift from "black-box" generation to "white-box" programmatic control. Because the output is aDSL code rather than a raw mesh, the resulting assets are inherently editable.

• Structural Editability: If a user wants to change the height of a table leg, they do not need to manipulate vertices or re-run a generative model. They can simply modify the parameter in the aDSL code, and the relational operators will propagate the change throughout the object.
• Interpretability: Developers can inspect the generated code to understand why an object was constructed in a certain way. This transparency is critical for debugging and for integrating AI-generated assets into existing production pipelines.
• Scene Composition: The relational nature of aDSL makes it particularly well-suited for complex scene composition. By defining objects as collections of related parts, the system can handle articulated objects and structured scenes with a level of control that was previously difficult to achieve with standard LLM-based generation methods.

The availability of the code on GitHub suggests that this framework is intended to be integrated into broader graphics workflows. Developers should look at how the aDSL interpreter can be mapped to existing 3D engines, such as Blender or Unity, to leverage these programmatic descriptions for real-time asset generation.

Bottom Line

The research demonstrates that the path to reliable AI-driven 3D creation is not necessarily through larger models or more data, but through better interface design. By aligning the language of 3D construction with the reasoning strengths of LLMs, the authors have created a system that is robust, controllable, and highly interpretable. As agentic workflows continue to mature, the co-design of domain-specific languages and multi-agent systems will likely become the standard for complex, structured generation tasks.

Pneumetron