GEAR: Feature-Based Configuration and Code Generation for Agentic Systems

Introduction

Nowadays, developers and researchers increasingly build multi-agent applications using frameworks such as CrewAI [9], Google ADK [8], and AutoGen [5]. Although these frameworks provide similar capabilities (like definition of agents, memory, reasoning, or orchestration), they expose them through different abstractions, terminology, and APIs [3, 18, 6]. As a result, developers and researchers must both navigate a large configuration space and continuously learn framework-specific concepts and implementation choices making the design process time-consuming, error-prone, and difficult to reason about.

Software engineering has addressed similar problems in highly configurable systems through variability modeling [11]. In particular, fms provide explicit representations of configuration spaces and their constraints, together with automated reasoning capabilities for validating configurations [12, 10]. However, to the best of our knowledge, no existing tool has leveraged fms to explicitly design and manage the variability of mass.

In this paper, we present GEAR, an open-source tool that provides a common, framework-independent language for describing configurable mass. Users specify their agents, modules, workflows, and configuration choices once, and GEAR validates this specification and generates executable implementations for selected target frameworks. This allows developers to reuse the same mas specification when exploring different target frameworks. GEAR connector-based architecture also separates the common specification from the implementation logic, enabling the integration of emerging frameworks and capabilities. A preliminary assessment across the $10$ supported frameworks identifies translation strategies for $271$ of $320$ evaluated feature–framework pairs ($84.69$%).

Envisioned users: GEAR targets both developers building or prototyping LLM-based mass and researchers studying agentic system designs. Developers can use GEAR to explore configuration choices, detect invalid configurations before implementation, and generate executable implementations for different frameworks from the same specification. Researchers can use the common representation to systematically vary mas designs, compare their implementations across frameworks, and reproduce experimental setups without manually reimplementing each system.

Related Work

Specification of mas. Recent LLM-based multi-agent frameworks, such as CAMEL-AI [4], AutoGen [5], MetaGPT [7], CrewAI [9], and Google ADK [8], provide abstractions for orchestrating agents through prompts, tools, and communication protocols. However, these frameworks primarily rely on code-level definitions, embedding system design decisions into implementation artifacts and offering limited support for reuse or systematic exploration of alternative configurations. More recently, specification-oriented efforts, including Open Agent Specification [13], Agent Definition Language (ADL) [14], AgentSPEX [15], and Härer [16], have introduced more declarative representations of agents and workflows. While these approaches contribute toward separating design from execution, they primarily describe individual system configurations or execution flows, with limited support for explicitly modeling variability across alternative mas designs.

Variability Modeling. Variability modeling has been widely used to capture and manage configuration choices in software systems, and has also been applied to machine learning systems [1]. More recently, it has been also used to study the configuration of llms [2]. Yoshimura et al. study variability in industrial AI agents for root-cause analysis, illustrating the value of explicitly managing variations across equipment, models, data, and operational contexts [17]. While their work focuses on adapting a domain-specific agent to different operational contexts, GEAR addresses variability at the mas level through a common, framework-independent representation that supports configuration, validation, and generation across heterogeneous agentic frameworks.

The GEAR Framework

GEAR Core Features and Workflow

GEAR provides a five-step workflow from mas configuration to execution across different target frameworks, as shown in Figure 1. We illustrate this workflow with a log-analysis system comprising two agents: LogParser, which parses logs, and LogAnalyzer, which analyzes them to identify potential causes.

Configure. Users define a framework-independent specification through GEAR Studio. The specification comprises three main elements: (i) agents, with properties such as their model, task, tools, memory, and execution controls; (ii) modules, which define reusable orchestration structures such as parallel or iterative execution; and (iii) workflows, which connect agents and modules and define their execution flow. In our example, the user configures the two agents and groups them into a DiagnosisLoop module used in the workflow.

Validate. GEAR automatically validates agents, modules, and workflows, reporting errors such as references to undefined agents or incompatible configuration options. Users can then correct these errors before proceeding to framework selection. In our example, the user selects both parallel and loop execution for DiagnosisLoop. Because these strategies are mutually exclusive, GEAR reports the conflict and asks the user to select a single strategy.

Select Target Frameworks. Users select one of the ten target frameworks supported by GEAR for each generation. The same specification can then be reused to generate implementations for other frameworks. In our example, the user first selects CrewAI and then repeats the generation with Google ADK, obtaining two implementations from the same log-analysis specification.

Generate. GEAR generates a separate executable project for each selected framework from the validated specification using templates. Each project contains source code, a configuration file and an execution entry point. In our example, the same log-analysis system can be generated for both CrewAI and Google ADK using the same specification.

Inspect and Execute. Users can inspect the generated project to determine whether it meets their application requirements. They can then execute it through the command line or through GEAR when execution is available.

GEAR Architecture and Implementation

Figure 2 presents the architecture and processing pipeline supporting the workflow described above. GEAR separates the common specification of a mas from the mechanisms required to transform it into framework-specific implementations.

Specification Layer. The specification layer (highlighted in blue in Figure 2) relies on feature modeling to represent the configurable properties of agents, modules, and workflows. A feature model organizes these properties hierarchically and specifies whether they are mandatory, optional, or alternative, together with dependencies and constraints governing their combinations [12]. Figure 3 illustrates an excerpt of GEAR’s common variability representation. In particular, $32$ features encode mas concepts identified through a review of the literature and an analysis of ten agentic frameworks, selected based on their availability, documentation, active maintenance, Python support, and ability to compose agents into workflows [3, 18, 6]. In addition, the feature model covers agent identity, model and task configuration, tools, memory, reasoning, execution controls, and orchestration. Overall, it exhibits $53$ features and encodes approximately $2.4 \times 10^{8}$ valid configurations.

Processing Layer. The processing layer (highlighted in brown in Figure 2) transforms this specification into framework-specific implementations. During the validation phase, GEAR checks the specification structure, feature-model constraints, and workflow consistency, and normalizes valid configurations into a common intermediate representation. During the translation phase, a connector for each target framework applies explicit feature mappings and provides the manifest, templates, and assembly logic required by that framework. The Assembly engine then deterministically generates the executable artifacts, including source code, configuration files, and execution entry points. A conversion report records how selected features were mapped, adapted or unresolved, preserving traceability between the common specification and each generated implementation.

Image not extracted

Preliminary Mapping Assessment

We conducted a preliminary mapping assessment across the ten frameworks, listed in Figure 4. For each of the 32 evaluated GEAR features, we examined whether a framework-specific implementation was feasible, yielding 320 feature–framework pairs. We considered a mapping as identified when we could determine how the feature could be implemented in the target framework, using a native mechanism, an adaptation, or synthesized code. Otherwise, we marked the mapping as unresolved, particularly when the feature was not exposed by the framework or remained implicit in its internal mechanisms. The identified mappings were then used to define and extend the framework-specific connectors of GEAR.

Figure 4 presents the mapping results for 320 feature–framework pairs, obtained by evaluating each of the 32 GEAR features against the ten selected frameworks. Overall, mappings were identified for 271 pairs (84.69%), while 49 (15.31%) remained unresolved. CrewAI achieved the highest coverage, with mappings identified for 31 GEAR features (96.88%) and one unresolved, followed by Google ADK with 30 (93.75%) and two, respectively. At the other end, Microsoft Agent Framework had 24 identified mappings (75.00%) and eight unresolved, while PydanticAI had 23 (71.88%) and nine. A given GEAR feature may be mapped to some frameworks while remaining unresolved in others.

To further assess GEAR, we are conducting an ongoing user study in which participants use the tool to specify and generate mass. We evaluate usability, effort, and the difficulties they encounter.

Limitations & Future Work

While GEAR demonstrates its ability to facilitate the configuration, validation, translation, generation, and execution of mas across different frameworks, several limitations remain. First, the current implementation focuses on the core abstractions and functionalities shared by the considered frameworks. More advanced capabilities, such as multimodal inputs and streaming are currently out of scope. Many of these capabilities are highly framework-specific and were intentionally excluded to preserve a common abstraction level and enable a controlled comparison across frameworks.

Second, support for a new target framework currently requires manually defining the corresponding connectors and mappings between GEAR’s framework-independent specification and framework-specific concepts. Although these mappings are reusable once implemented, their initial development requires both engineering effort and knowledge of the target framework. Reducing this effort, for instance through partially automated connector generation or mapping inference, is therefore an important direction for future work.

GEAR validates specifications against encoded constraints and reports target-specific translation limitations. Unresolved properties are omitted, so generated projects may differ from the requested specification. Future work should therefore investigate these behavioral differences more systematically, extend the range of supported features, and evaluate GEAR on larger and more representative real-world multi-agent applications.

Conclusion

In this paper, we presented GEAR, an open-source tool for configuring and generating mass across heterogeneous agentic frameworks. By separating the specification of a mas from its framework-specific implementation, GEAR allows users to reuse the same mas specification across different frameworks through framework-specific connectors. It also makes configuration choices explicit through its feature-based model and makes the support of new frameworks easier through its connector-based design. Overall, GEAR contributes to bridging variability modeling with mas, and opens new directions for their study and evaluation. Data Availability GEAR is open-source and available at https://github.com/brellsanwouo/gear-framework. A demonstration video presenting an end-to-end case study is also available at https://youtu.be/iwNi-oC2tCw.