Paper deep dive

BONSAI: A Mixed-Initiative Workspace for Human-AI Co-Development of Visual Analytics Applications

Thilo Spinner, Matthias Miller, Fabian Sperrle-Roth, Mennatallah El-Assady

Year: 2026Venue: arXiv preprintArea: cs.HCType: PreprintEmbeddings: 87

Intelligence

Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 98%

Last extracted: 4/26/2026, 9:21:53 PM

Summary

BONSAI is a mixed-initiative workspace designed for the human-AI co-development of Visual Analytics (VA) applications. It addresses the challenges of monolithic architectures and unconstrained AI code generation by utilizing a modular four-layer architecture (Hardware, Service, Orchestration, and Application) and a structured four-phase development process (Plan, Design, Monitor, and Review). The system emphasizes modularity, strict interface contracts (guardrails), and fine-grained provenance tracking to ensure that both human and AI contributions are traceable, auditable, and structurally bounded.

Entities (11)

AI Agent · agent · 100%Application Layer · architecture-layer · 100%BONSAI · systemworkspace · 100%Design · development-phase · 100%Hardware Layer · architecture-layer · 100%Human Developer · user-role · 100%Monitor · development-phase · 100%Orchestration Layer · architecture-layer · 100%Plan · development-phase · 100%Review · development-phase · 100%Service Layer · architecture-layer · 100%

Relation Signals (4)

BONSAI → followsprocess → Plan

confidence 100% · The workspace incorporates this architecture into a structured four-phase development process (plan, design, monitor, and review)

BONSAI → usesarchitecture → Hardware Layer

confidence 100% · BONSAI utilizes a modular four-layer architecture (hardware, services, orchestration, application)

AI Agent → contributesto → Service Layer

confidence 90% · An AI agent is bound to a specific layer and constrained by its interface contract

Human Developer → contributesto → Application Layer

confidence 90% · allows human and AI developers to independently contribute reusable components.

Cypher Suggestions (0)

No Cypher suggestions yet.

Abstract

Abstract:Developing Visual Analytics (VA) applications requires integrating complex machine learning models with expressive interactive interfaces. Developers face a stark trade-off: building tightly-coupled monoliths plagued by fragile interdependencies, or relying on restrictive, simplistic frameworks. Meanwhile, unconstrained, single-shot AI code generation promises speed but yields unstructured, unauditable chaos. The core challenge is combining the control and expressiveness of custom development with the efficiency of AI generation under strict constraints. To address this, we introduce BONSAI, a mixed-initiative workspace for the multi-agent co-development of VA applications. BONSAI utilizes a modular four-layer architecture (hardware, services, orchestration, application) that allows human and AI developers to independently contribute reusable components. The workspace incorporates this architecture into a structured four-phase development process (plan, design, monitor, and review), ensuring distributed agency and full provenance, where all human and AI contributions are structurally bounded and tracked. We evaluate BONSAI through case studies demonstrating the efficient creation of novel tools and the rapid reconstruction of complex VA applications directly from research paper descriptions. Ultimately, this paper contributes a conceptual workflow, a scalable architecture, and an integrated system that successfully balances AI's generative speed with the structural rigor required for complex VA development.

PDF

Open source PDF →Open local PDF →

Trouble viewing inline? Open PDF directly →

Full Text

86,559 characters extracted from source content.

Expand or collapse full text

BONSAI: A Mixed-Initiative Workspace for Human-AI Co-Development of Visual Analytics Applications Thilo Spinner, Matthias Miller, Fabian Sperrle-Roth, Mennatallah El-Assady Hardware Layer Service Layer Orchestration Layer Node A Node B Node D Node C Node E AI Agent Chat AI Agents Nexus Task Worker 1 ... Pipeline EditorRevisionsParameters Column AColumn BColumn C Dashboard Ideation Workspace Setup Issue Board AI Agent Management Current Agent View History & Provenance Code Analysis Health & Cost Application Preview Automated Testing Performance Metrics Versioning MCP DesignMonitorPlanReview Application Layer Collaborative Development and Provenance Tracking Efficient Validation and Agentic Evaluation Architecture Guardrails using Interface Contracts Modularity and Reuse with Augmented Planning CI/CD Parameters Iterate Column AColumn BColumn C Dashboard Logs End- User- Facing Application Fig. 1: The structured four-phase workflow of theBONSAImixed-initiative workspace. The human-driven process begins with (1) Plan to ensure modularity and reuse through augmented task and agent management. In the (2) Design phase, human and AI agents collaborate within bounded contexts, enforcing architectural guardrails via strict interface contracts across the four system layers. The (3) Monitor phase enables safe collaborative development through comprehensive provenance tracking of all multi-agent interactions. The (4) Review phase facilitates efficient validation of the resulting Visual Analytics application through agentic evaluation, automated testing, and performance dashboards. Finally, the application is deployed to be accessed by the end-user. Abstract—Developing Visual Analytics (VA) applications requires integrating complex machine learning models with expressive interactive interfaces. Developers face a stark trade-off: building tightly-coupled monoliths plagued by fragile interdependencies, or relying on restrictive, simplistic frameworks. Meanwhile, unconstrained, single-shot AI code generation promises speed but yields unstructured, unauditable chaos. The core challenge is combining the control and expressiveness of custom development with the efficiency of AI generation under strict constraints. To address this, we introduceBONSAI, a mixed-initiative workspace for the multi-agent co-development of VA applications.BONSAIutilizes a modular four-layer architecture (hardware, services, orchestration, application) that allows human and AI developers to independently contribute reusable components. The workspace incorporates this architecture into a structured four-phase development process (plan, design, monitor, and review), ensuring distributed agency and full provenance, where all human and AI contributions are structurally bounded and tracked. We evaluateBONSAIthrough case studies demonstrating the efficient creation of novel tools and the rapid reconstruction of complex VA applications directly from research paper descriptions. Ultimately, this paper contributes a conceptual workflow, a scalable architecture, and an integrated system that successfully balances AI’s generative speed with the structural rigor required for complex VA development. 1 INTRODUCTION Developing data-driven Visual Analytics (VA) applications is inher- ently complex, requiring tight integration of machine learning models, intensive data-processing pipelines, expressive interaction design, and heterogeneous execution environments [29]. Developers face persistent challenges in decomposition and reuse across projects, such as extract- ing a novel visualization technique from a prototype, sharing a reusable view, or reconstructing a complex system described in a research paper. While these demands do not strictly forbid monolithic implementations, tightly coupled architectures silently tangle concerns across the result- ing systems, making it difficult to reason about, audit, and extend [38]. Recently, agent-assisted and fully agentic coding workflows have matured significantly [62]. Current best practices—leveraging stronger frontier models, structured plan files, agent skill constraints, and auto- mated review steps—can dramatically improve development throughput and catch shallow failures. However, this rapid pace introduces a new sociotechnical challenge often colloquially termed “vibe coding” [56]: a momentum-driven development style where the sheer speed and ease of generation motivate developers to rely on intuition rather than critical oversight. While frontier tools allow developers to read along and steer the process, they rarely enforce active comprehension. Consequently, developers are easily incentivized to disengage from the causal story of how outputs are produced, leading to misplaced confidence in system layers where the human reviewer no longer possesses a stable mental model [7, 39, 41]. The resulting gap is a severe lack of fine-grained provenance: there is no legible record of why an integration decision survived review, or how human and machine edits intertwined [5, 47]. To restore intelligibility and control, the underlying architecture must enforce a strict separation of concerns. Modularity and explicit in- terface contracts are standard software-engineering responses to exactly this kind of boundary pressure. We adopt a layered core architecture (hardware, services, orchestration, application), not to claim novelty for layering as such, but as a disciplined, machine-enforceable scaffold. Interface contracts and modularity operate both within and across these layers. Vertically, each layer enforces its own standardization: the hardware layer achieves consistency across heterogeneous platforms through Kubernetes, abstracting bare-metal and cloud nodes behind a uniform scheduling interface; the service layer exposes independently deployable microservices with typed, versioned interfaces; and the or- chestration layer provides centralized management components (au- thentication, service registry, workflow orchestrator) powering DAG- based workflows that enable design-time type checking and selective recomputation. Horizontally, each layer exposes only a minimal typed surface to the layer above: context distillation optimizes the informa- tion scope that any developer or agent needs to hold at once, and the abstraction barrier prevents upper layers from reaching through to by- pass or alter lower-layer implementations. By applying these standard good practices, we transform the uncon- strained “AI-does-everything” sandbox into targeted, manageable tasks. An AI agent is bound to a specific layer and constrained by its interface contract, which prevents context-window saturation [32] and keeps re- sponsibilities and review surfaces explicit—a prerequisite for legible human–AI co-development. Furthermore, it enables VA developers to focus exclusively on specific layers according to their expertise—for example, application developers can concentrate on UI/UX and work- flow logic, service developers on atomic data-processing algorithms, and DevOps engineers on the underlying execution environments. Un- der this level of bounded expert control, agentic systems unlock mas- sive potential, including the rapid reconstruction of complex VA appli- arXiv:2604.19247v1 [cs.HC] 21 Apr 2026 cations directly from research papers that lack published source code. To operationalize this scaffold, we introduceBONSAI, a mixed- initiative workspace for the human–AI co-development of data-driven VA applications. Its name signals our stance: like cultivating aBONSAI tree, generative code changes represent organic growth that still de- mands deliberate structure, pruning, and guided oversight if the product is to stay robust and inspectable. The workspace organizes collabora- tion through four phases—Plan, Design, Monitor, and Review. This structured workflow ensures that oversight, provenance tracking, and a balanced distribution of agency remain visible and actionable through- out development, rather than collapsing into a single opaque transcript. Specifically, this paper makes four principal contributions: (1) a con- ceptual analysis of human–AI co-development tailored to VA applica- tions, emphasizing the necessity of modularity, reuse, guardrails, in- terface contracts, provenance tracking, and agency distribution; (2) a layered core architecture encompassing four distinct levels (hardware, services, orchestration, and application) that provides the structural foundation for safe multi-agent interaction; (3) the introduction of the BONSAIworkspace, an integrated system for human–AI collaboration that operationalizes this architecture through a four-phase development process; and (4) validation of the approach via use cases demonstrat- ing the system’s effectiveness in rapidly reconstructing complex VA applications from research paper descriptions. 2 RELATED WORK BONSAIsits at the intersection of workflow orchestration, visualization architecture design, mixed-initiative human-AI collaboration, prove- nance tracking, and agentic software engineering. We structure this section along these dimensions, highlighting how existing approaches address parts of the problem but leave gaps that BONSAI fills. Workflow Management and Data Pipeline Tools — The orchestra- tion of multi-step computational workflows has a long history in data engineering. Apache Airflow [6] popularized workflows as directed acyclic graphs (DAGs) in Python, providing scheduling, dependency resolution, and monitoring. More recent platforms such as Prefect [43] and Kestra [30] decouple orchestration from business logic, with Kestra using declarative YAML definitions for language-agnostic execution. Dagster [19] introduces software-defined assets, treating data lineage as a first-class citizen. This principle resonates withBONSAI’s typed interface contracts. KNIME [9] offers a visual node-based interface for composing analytical pipelines. However, these tools target batch pro- cessing and do not address the interactive feedback loops of VA appli- cations nor bounded human-AI co-development.BONSAIextends their declarative philosophy with a layered architecture for VA pipeline con- struction, where services, orchestration logic, and front-ends co-evolve under human oversight. Visualization Architectures and Design Constraints — Satyanarayan et al. introduced Vega-Lite [45] as a high-level grammar of interactive graphics on Vega’s reactive dataflow [46]. Moritz et al. formalized vi- sualization design as a constraint satisfaction problem in Draco [35], enabling automated encoding recommendations. Heer and Moritz pro- posed Mosaic [24], decoupling visualization clients from a scalable query engine—a separation of concerns parallelingBONSAI’s layered design. Wongsuphasawat et al. showed with Voyager 2 [59] how par- tial specifications enable mixed-initiative exploration of design spaces, and Ding et al. [15] found that shared visual structures for human–AI hypothesis exploration act as “guardrails” focusing thinking without constraining creativity—validatingBONSAI’s pipeline editors as cogni- tive scaffolds. These systems advance visualization rendering, recom- mendation, and scalable querying, but target the use of visualizations, not the co-development of full VA applications including backend data processing pipelines. Mixed-Initiative Visual Analytics and Guidance — Mixed-initiative interaction—where humans and agents dynamically share control—was formalized by Horvitz [26] in his foundational principles for mixed- initiative user interfaces. Amershi et al. [1] later consolidated practical guidelines for human–AI interaction that have become a reference in the field. Ceneda et al. [12] characterized guidance as closing knowl- edge gaps and proposed a designer model [11] for the what, when, and how of guidance. Sperrle et al. introduced co-adaptive guidance for learning user preferences [49, 50] and contributed Lotse [48], a library for deploying guidance strategies in running VA systems. El-Assady et al. [18] proposed speculative execution for VA, enabling proactive computation of competing model states. Stähle et al. [53] presented a design space for agents in VA, while Monadjemi et al. [34] confirmed the breadth of mixed-initiative VA research while identifying the lack of frameworks moving beyond analysis assistance toward development support. Across this work, mixed-initiative interaction targets data analysis.BONSAItransfers these principles to the development process, guiding developers and agents through the co-construction of VA appli- cations and distributing agency across architectural layers and phases. Provenance Tracking in Visual Analytics — Provenance—the sys- tematic recording of history and lineage of analytical artifacts—has been extensively studied in visualization. Ragan et al. [44] proposed a taxonomy distinguishing data, visualization, interaction, insight, and rationale provenance. Xu et al. [61] provided a comprehensive survey establishing a unified framework for provenance in VA. On the systems side, VisTrails [10] represents workflow evolution as a version tree, and AVOCADO [54] manages dense provenance graphs through hierarchi- cal aggregation—a challenge mirrored inBONSAI’s multi-agent devel- opment histories. CLUE [22] enables capturing and explaining prove- nance with branching, Trrack [13] provides a reusable tracking library, and Loops [16] extends provenance into computational notebooks. In agent provenance, PROV-AGENT [47] extends W3C PROV with agent- centric entities, while Cursor’s Agent Trace [5] addresses AI code at- tribution at the file level. These contributions provide mature mod- els for tracking user interactions and agent actions, but none address provenance in VA development—tracking who contributed what, at which layer, and during which phase.BONSAItreats agency attribution as a first-class dimension: every modification across all four layers is recorded with its actor, enabling developers to audit, compare, and roll back human and AI contributions throughout the development lifecycle. Agentic Software Engineering — AI-assisted coding tools—GitHub Copilot, Cursor [4], Windsurf [58], JetBrains AI [27], Claude Code [3], and OpenAI’s Codex [37]—integrate large language models into de- velopment environments for code generation and increasingly au- tonomous task execution. In the multi-agent space, MetaGPT [25] en- codes Standardized Operating Procedures into multi-agent pipelines, AutoGen [60] orchestrates configurable multi-agent conversations, and Magentic-One [20] employs a dual-loop orchestrator. On the protocol level, Anthropic’s Model Context Protocol [2] standardizes agent-to-tool communication, Google’s Agent2Agent Protocol [21] ad- dresses inter-agent discovery, and the LLM Delegate Protocol [42] adds identity-aware routing and structured provenance—notably showing that self-reported quality scores degrade routing below random base- lines. Empirically, Peng et al. [40] found significant productivity gains, while Pearce et al. [39] and Perry et al. [41] showed that AI-generated code frequently contains vulnerabilities and that developers overesti- mate its security. These findings expose three gaps: (1) existing tools operate as monolithic agents without distribution of agency across ar- chitectural boundaries; (2) provenance is limited to git-level attribu- tion, missing fine-grained human–AI interplay; and (3) the absence of guardrails—typed contracts, bounded contexts—leads to context- window saturation and opaque generation as projects grow.BONSAI addresses all three through bounded, layer-specific AI Development Units, typed interface contracts, and comprehensive agency provenance across a four-phase development process. 3 PROBLEM CHARACTERIZATION To transition from the limitations of monolithic development to a robust, AI-assisted paradigm, we must formalize the system’s boundaries. Formative Methodology — To ground our design rationales and ar- chitectural decisions in practice, we used an iterative, human-centered process over three years: we first developed and validated the layered architecture without AI in multiple higher-education courses (200+ stu- dents per cohort) building complex VA pipelines, then used longitudi- nal observations of recurrent failures (e.g., dependency conflicts, brittle cross-layer contracts, and poor reproducibility) to design theBONSAI workspace and scope generative-AI support as guardrails, addressing real development bottlenecks rather than hypothetical edge cases. Target User Groups — Standard VA development often assumes a homogeneous “developer” role, but real systems involve distinct roles. To integrate AI agents safely,BONSAIaligns its abstractions with four groups: End-Users audit and steer application behavior via feedback, Application Developers build UI and interaction logic, Service Devel- opers build algorithms, models, and service contracts, and DevOps- Engineers take care of deployment, orchestration, and security. This separation lets both humans and AI assistants operate with the right layer-specific context, avoiding cognitive and computational overload. 3.1 Challenges First, developers face ch01 Tightly-Coupled Monoliths and Depen- dency Hell. Traditionally, VA tools are built as highly specialized, one- off monolithic architectures, leading to tremendous dependency trees virtually impossible to maintain. Updating individual packages often entails an avalanche of incompatibilities between upstream dependen- cies which are hard or even impossible to resolve. Related, accessibility of useful software components is limited by thech02(Re-)Usability Bottleneck. Extracting useful standalone func- tionalities from a monolith is non-trivial: components are typically entangled with application-specific logic and glue code, making isola- tion labor-intensive and error-prone. The problem is compounded for research-driven VA tools, where novel techniques are frequently pub- lished without well-maintained implementations, forcing developers to spend significant effort re-implementing algorithms from paper de- scriptions before any integration work can begin. Second, as generative AI is introduced to speed up development, systems suffer fromch03Architectural Drift and Context Degrada- tion. While modern agentic harnesses are increasingly capable, the quality of AI-generated code is ultimately bounded by the standards the project itself establishes: a codebase with clear boundaries, strict conventions, and well-defined interfaces naturally guides the AI toward coherent, maintainable outputs. Unstructured or entangled codebases instead cause the AI to replicate and amplify existing flaws. This accel- erates technical debt rather than alleviating it. Without bounded layers, the AI’s context is saturated with suboptimal patterns and details rather than the targeted interface contracts needed for reliable generation. The rapid pace of AI-driven development exacerbatesch04Loss of Semantic Provenance in Co-Creation. While AI harnesses are now proficient at utilizing feature branches and committing code regularly, standard version control diffs fail to capture intent:githistories do not always record why an AI made a specific integration decision, what prompted the generation, or how agency was distributed between the human and the machine. Without this semantic provenance, developers lose the ability to meaningfully audit or steer the system’s evolution. Finally, VA applications deployed on heterogeneous, multi-tenant platforms facech05Fragile Compliance Across Heterogeneous De- ployment Stacks. Applications routinely carry operational and regula- tory requirements: data must not leave a particular jurisdiction, certain computations require GPU-enabled hardware, sensitive payloads must not be routed through external services. While these requirements orig- inate at the application level, their enforcement must happen at the in- frastructure level. Without a structural bridge between the two, compli- ance depends on manual configuration and organizational convention at every layer independently: a developer who specifies that clinical data must remain on-premise has no guarantee that an external API will respect this. As the number of services, workflows, and execution en- vironments grows, this ad-hoc approach becomes increasingly fragile and difficult to audit. 3.2 System Requirements From these challenges, we derive three key requirements for safe, multi- agent co-development in the BONSAI workspace. R1 Modularity and Reuse — To resolvech01andch02, the system must enforce a strict separation of concerns, breaking the paradigm of isolated, single-use prototypes. Functionalities must be encapsulated into atomic, operationally independent microservices. By extracting these building blocks and preventing deep inter-dependencies, the ar- chitecture must guarantee that newly developed analytical techniques and interface components are natively reusable across multiple projects and easily deployable by different teams, rather than remaining locked away in custom glue code. R2Guardrails and Context Distillation — To addressch03and re- liably managech05, the architecture must provide strict boundaries that naturally distill the context for both human developers and agen- tic AI. Rather than exposing an unstructured full-stack codebase, the system must establish clear, formal interface definitions (e.g., semantic API documentation and API contracts) that enable design-time depen- dency resolution and validity checks. This deliberate context distilla- tion ensures that any given agent’s context is rich enough to complete a specific task, yet entirely pruned of redundant, irrelevant, or cross-layer implementation details. By constraining the action space to these well- documented, localized boundaries, generated outputs remain small and highly traceable. It is precisely this reduction in cognitive load and complexity that allows human developers to meaningfully review both their own and the AI’s contributions, guaranteeing they remain in full, confident control over the development process. R3Provenance Tracking and Agency Sharing — To overcome ch04 , the system must explicitly reject unconstrained generative work- flows in favor of formal agency sharing, where humans and AI collabo- rate across well-defined boundaries. In a mixed-initiative environment, robust accountability requires semantic provenance: tracking not just what code changed, but who (human or AI) authored it, and why. Cru- cially, this provenance tracking cannot rely solely on generic, one-size- fits-all version control logs. It must be tailored to each layer and treat agency handoff points as first-class citizens in the system’s state his- tory, enabling developers to audit, steer, or roll back the co-creation process at any time. 4 BONSAI’S LAYERED CORE To satisfy the aforementioned requirements (R1,R2,R3) and physi- cally isolate the operational domains of our target user groups, we in- troduce a four-layered architecture. Rather than relying on soft coding conventions, this infrastructure structurally enforces a strict separation of concerns. By untangling the complex dependencies of traditional VA pipelines into discrete, manageable environments, the architecture natively bounds the context for both human developers and their as- sistive AI agents. As detailed in the following subsections, each layer contributes distinct and complementary mechanisms that together oper- ationalize all three requirements: modularity and reuse (R1) through strict service encapsulation and a shared registry that makes components immediately composable across projects; guardrails and context distil- lation (R2) embedded structurally at every level rather than imposed by post-hoc convention; and the architectural foundations for prove- nance and agency attribution (R3), which theBONSAIworkspace (see Section 5) operationalizes fully through its four development phases. 4.1 Core Architecture As illustrated in Figure 2, the middleware is organized into four hierarchical layers, each abstracting complexity from the one be- low. At the base, the Hardware Layer (L1) exposes heterogeneous compute resources—on-premise clusters, hyperscalers, research, and supercomputing—through a unified Kubernetes abstraction, enabling policy-driven scheduling that transparently matches workload require- ments to compliant execution environments. The Service Layer (L2) hosts independently deployable microservices, each encapsulating a single AI or data-processing capability behind a typed OpenAPI con- tract. The Orchestration Layer (L3) maintains a shared service registry that handles discovery and monitoring of all admitted L2 services; it accepts workflow definitions as directed acyclic graphs and coordinates their execution: resolving inter-node dependencies, scheduling service calls, enforcing authentication, and routing results—or errors—back to the caller. The Application Layer (L4) exposes this machinery to end users as a low-code environment in which applications compose workflows from registry services, supply inputs and configuration pa- rameters, and consume structured results interactively. k8s Workflow 1 Application Layer Config Hyperscaler On- Premise Supercomputing Hardware Layer Service Layer Orchestration Layer Service A Service BService C Node ANode B... Inputs Results / Errors End- user- facing Application 2 Research End- user- facing Application 1 Dependency Resolution Scheduling Authentication Reporting Service Implementation Service Discovery Monitoring L1 L2 L3 L4 Fig. 2: The layered core architecture. The Application Layer provides a low-code environment for rapid pipeline configuration. The Orchestration Layer manages workflow execution and distributes tasks to the Service Layer, where independent microservices process data sequentially in accordance with strict API specifications. The underlying Hardware Layer abstracts diverse, heterogeneous resources via Kubernetes. L1: Hardware Layer & Policy-Driven Scheduling The Hardware Layer unifies disparate execution environments, such as on-premise clusters, HPC systems, or cloud providers, into a single logical resource pool managed via Kubernetes, providing the infrastruc- ture required for heterogeneous VA execution. Beyond resource pooling, it implements a three-part cross-layer con- straint satisfaction mechanism that directly addresses R2 : application- level requirements are reliably enforced throughout the entire execution stack, not merely declared at the top. To this end, first, all entities in the stack (hardware environments, services, workflows, and applications) are tagged with a set of descriptive labels encoding properties along multiple dimensions, including data jurisdiction, confidentiality level, runtime behavior (e.g., absence of external network dependencies), hardware capabilities, and regulatory compliance. Second, applications and workflows explicitly declare the constraints they require the layers below to satisfy; these declarations are versioned alongside the work- flow definition, making compliance requirements a reproducible part of the workflow artifact rather than an external, mutable configuration. Third, at scheduling time, the platform matches constraints through the stack. Critically, a constraint that cannot be satisfied blocks execu- tion and surfaces a diagnostic error, rather than silently falling back to a non-compliant environment. For example, if a medical application is tagged as HIPAA-COMPLIANT, the orchestration layer will ensure its workloads call only compliant services. The hardware scheduler will ensure execution occurs exclusively on secure, on-premise nodes without requiring manual intervention per workflow. L2: Service Layer & Service Development The Service Layer is the domain of Service Developers and special- ized backend AI agents. A (micro)service is a small, independently deployable software component that encapsulates a single AI or data- processing capability and exposes it through a typed, validated Open- API contract. The microservice-based architecture is strictly motivated at this layer to addressR1: by enforcing strong encapsulation, services remain independently maintainable, can scale through replication, and are reusable across disparate VA projects without introducing tangled cross-project dependencies. Admission Gate — In L2, developers build and deploy atomic data- processing algorithms and machine learning models. To be admitted to the Service Registry and, thus, become discoverable by the orches- tration layer and eligible for hardware scheduling, every service must satisfy a set of mandatory interface requirements: a RESTful API, a strongly typed and complete OpenAPI specification, a health endpoint for runtime monitoring, semantic versioning, and a commitment to backward compatibility within a given endpoint version. These admis- sion checks are enforced before a service becomes visible to any work- flow or AI agent, ensuring that only well-specified, compatible compo- nents enter the shared ecosystem. Developer and Agent Guidance — To guide both human developers and AI coding agents in meeting these requirements,BONSAIprovides skill files (curated, machine-readable documents encoding coding con- ventions, architectural patterns, and layer-specific guardrails) alongside standardized scaffolds that serve as fully conformant service templates. Together, these resources operationalize R2 at the service level: rather than exposing agents to an unstructured codebase, the OpenAPI con- tract provides a semantically complete, implementation-agnostic de- scription of each service’s capabilities—precisely scoping what any developer or agent needs to know to integrate or extend a component, without access to irrelevant internal detail. For more details on how AI agents implement services as part of their workflow, see Section 6. L3: Orchestration Layer & Control Plane The Orchestration Layer acts as the central control plane, bridging ser- vices (L2) with applications (L4). It manages real-time execution, ser- vice discovery, and automatic dependency resolution, while serving as the architectural locus for three complementary guardrail mechanisms. Centralized Identity and Access Management — L3 provides a state- less authentication gateway that intercepts every inbound service call, validates the caller’s token against the Service Registry, and enforces uniform access control across the entire ecosystem. Services are re- quired to defer all authentication and authorization to this gateway and must not implement their own identity and access management (IAM) logic. This constraint eliminates security vulnerabilities arising from divergent implementations, prevents inconsistent access patterns, and ensures that access control is a uniform, centrally auditable property of the platform, providing the actor-level attribution log that is a structural prerequisite forR3. Structured Workflow Composition — Application logic in L3 is ex- pressed as directed acyclic graphs (DAGs) through a workflow designer that enforces a strict visual and textual grammar: nodes represent reg- istered L2 services or platform-provided control-flow constructs (e.g., conditional branches, parallel execution blocks), and edges represent typed data flows. Compatibility between connected nodes is validated at design time by the CType structural type system—where a CType is a named, structured data type composed of typed fields, each of which is either a primitive type (integer, string, boolean, etc.) or an- other CType—which checks that the output types of upstream nodes precisely match the expected input types of downstream nodes, catch- ing structural mismatches already during design-time. Once validated, the DAG is automatically transpiled into an executable flow and dis- patched to the orchestration engine, which schedules service calls in dependency order. When an end-user or agent adjusts a parameter mid-workflow, the dependency graph is resolved, and only the affected downstream nodes are re-executed—minimizing redundant computa- tion and ensuring responsive UI interactions. Because service discov- ery is continuous, newly registered L2 services immediately become composable nodes without requiring platform downtime or reconfigu- ration, leveraging the requirements and admission control mechanisms implemented by the service layer. This composability from a shared, versioned registry directly operationalizes R1 : a service developed once for any project becomes immediately available for reuse across all workflows without modification or duplication. L4: Application Layer & User Interaction The Application Layer is the top-most abstraction, where Appli- cation Developers implement the End-User-facing VA application. Implementation Openness — Unlike the lower layers, L4 intentionally provides the greatest degree of freedom: because VA applications are highly individual in their visual languages, interaction paradigms, and domain-specific requirements, no single framework or rigid template could accommodate the full range of expressiveness needed. Front-end developers may therefore use any framework of their choice to build custom, stateful user interfaces tailored to their analytical context. To guide both human developers and UI-focused AI coding agents through this open-ended layer,BONSAIprovides skill files, component templates, and curated library recommendations that encode best prac- tices for connecting applications to the underlying platform [23]. These resources reduce decision overhead without prescribing a fixed imple- mentation, operationalizingR2at the application level within the in- herent constraints of a free-form layer. Platform Integration — The application communicates with L3 via well-defined REST endpoints to discover workflow runs, fetch state histories, retrieve analytical results, and trigger selective re-executions. When an end-user adjusts a parameter, the UI must push the change to the orchestration layer; L3 resolves the DAG, re-executes only the affected downstream nodes, and returns the updated state. This clean separation allows Application Developers (and UI-focused AI agents) to focus entirely on visual components, UX workflow logic, and stateful interaction without managing service internals or infrastructure scaling. Importantly, the only formal guarantees the architecture can provide at L4 are the typed input and output contracts of the L3 pipelines and L2 services the application consumes. Beyond these contracts, correct- ness, visual quality, and interaction design remain the responsibility of the Application Developer—a deliberate boundary that preserves the expressiveness required for domain-specific VA tools while ensuring that the integration surface remains well-defined and auditable. 4.2 Implementation Details The following paragraphs describe the key mechanisms that realize the architectural principles outlined above. Service Discovery — Services deployed to designated Kubernetes namespaces are automatically discovered by the Service Registry. Ad- mission controllers verify that each deployment satisfies the platform’s requirements before registration proceeds. Services hosted outside the cluster can alternatively be registered manually. In both cases, the OpenAPI documentation of the service is checked against a validation endpoint, ensuring the API’s structure, its endpoints, and its typings match the specified quality criteria. If the validation succeeds, a newly added service enters a Pending Review state visible to platform admin- istrators. Once reviewed, one user (usually the developer) is appointed as the service’s manager and is responsible for governing access. Authorization and Authentication — The Service Registry enforces fine-grained access control over service resources through OAuth 2.0 Bearer tokens [28]. The ingress controller validates the Authorization header [36] of every incoming service call against a stateless authoriza- tion gateway, which in turn validates the token against the access con- trol endpoints of the Service Registry. Access to sensitive information held by a service is granted by possessing the resource identifier itself, eliminating the need for additional per-resource permission checks (but requiring that the resource identifier be treated as a secret). Workflow Composition, Dispatch, and I/O — Workflows are au- thored either through a visual canvas editor or by directly editing YAML, with both representations kept in sync. The editor exposes reg- istered services as typed, drag-and-drop nodes whose connectable han- dles and static parameter panels are derived automatically from the ser- vice’s OpenAPI schema: fields annotated withx-parameter: true appear as configuration knobs. In contrast, all other request-body fields become wired inputs that can receive data from upstream nodes. The canonical workflow artifact is a YAML revision stored in the portal’s database; the underlying orchestration engine Kestra [30] is never given a persistent copy. Instead, each execution follows an ephemeral dis- patch pattern: the portal injects an execution-scoped identifier into the YAML, registers the flow with Kestra’s REST API, starts an execution, and streams the resulting Server-Sent Event (SSE) progress feed. Once a terminal state is reached, logs and any file-typed outputs are copied to the platform’s object store, and the Kestra flow is deleted. Scalar inputs are passed as typed key-value pairs (string, int, float, boolean, json). File inputs are resolved from the platform’s object store before submission. For very large binary objects, it is recommended to instead use a Kestra plugin node that directly retrieves the file from a storage backend (e.g., S3). Applications trigger workflows through a webhook or through the platform’s MCP interface, supplying input values and optional file ref- erences. Callers poll the execution state endpoint and retrieve output artifacts via presigned object-store URLs once execution succeeds. Human Operator AI Development Units Nexus Orchestrator Human- Only Set Goals, Policy, and Constraints AI- Lead Decompose work into tasks, plan AI- Lead Prioritize and assign tasks ADU- Only Human- Only Implement and test automatable tasks Implement and test manual tasks Validate acceptance criteria Human- Only Final approval to merge System Write provenance and audit trail Comment, revise, pause, kill Human, AI Human- Lead Rollback and replan Human, AI Fig. 3: An exemplary human-AI collaborative Bonsai workflow, illustrating a natural distribution of agency across phases.Human-Only, AI-Lead, and mixed Human-AI phases alternate to balance automation with oversight, with feedback loops enabling iterative revision and rollback throughout. 5 THE BONSAI WORKSPACE The layered core provides structural foundation and interface contracts, but infrastructure alone is insufficient for successful human-ai collab- oration: the process must keep the human in the loop and prevent the AI from acting as an opaque black box. We therefore introduce the BONSAIWorkspace, a mixed-initiative environment that operational- izes the architecture through a continuous, four-phase workflow: Plan, Design, Monitor, and Review (see Figure 1). These phases make no assumption about agency distribution—either party could, in principle, run all four alone. In practice, a natural division emerges (Figure 3): humans set goals, policies, and constraints, while the top-level AI or- chestrator (Nexus) decomposes tasks and delegates them via mid-level coordinators (Squad Leads, SLs) to specialized implementation agents (AI Development Units, ADUs) that implement in parallel under the workspace’s guardrails. 5.1 Phase A PLAN – Workspace Configuration The Plan phase establishes guardrails and allows for steering the devel- opment context before code is generated. Idea Brainstorming and Issue Board — The human developer initi- ates a project by defining high-level goals and architectural constraints, thereby establishing the foundational context that feeds all AI agents. Through a brainstorming chat, theBONSAIusers explore ideas and tasks collaboratively with an AI assistant; each idea is structurally eval- uated for feasibility and complexity, receiving a go, refine, or pass rec- ommendation before promotion to the Issue Board. Promoted ideas are decomposed into a parent issue with numbered child issues, each as- signed an agent type and linked by explicit dependencies forming a di- rected acyclic graph, avoiding merge conflicts through proper planning. The Nexus respects this dependency order during execution, deferring any child whose prerequisites have not yet been completed. Agent Skill Management — Rather than relying on a single, omnipo- tent AI, the workspace allows configuring specialized ADUs. Here, developers define specific capabilities, assign allowed tools, and set rigid constraints for each agent. By reducing the action space and tai- loring the AI’s profile to a specific task (e.g., frontend UI vs. backend data processing), the system strategically decreases the risk of context- window ballooning and hallucinations. 5.2 Phase B DESIGN – VA Application Composition The Design phase is the active, collaborative coding environment where the BONSAI’s four-layer architecture is leveraged. Service Registry — The Service Registry introduced in Section 4.1 is exposed through a dedicated management interface that supports registering external services (in addition to automated discovery), role- based access management, and centralized documentation, including endpoint usage examples and code snippets. Composing Workflows — The workspace includes a visual pipeline editor backed by the structural type system (CType) shown in Figure 4. Developers select from a toolbox of pre-configured and auto-discovered service nodes and compose them via drag-and-drop in a graph editor. Valid connections are highlighted in green; type mismatches are flagged in red with a detailed error message on hover, providing immediate design-time feedback before any code executes. Besides inputs and Fig. 4: The orchestration graph shows the constructed Kestra workflow and highlights which services exist or must be built. outputs, nodes can have a special input type called parameters; unlike inputs, parameters are not provided by upstream nodes but can be configured as node properties. Parameters can be set at design time or provided to the flow at runtime. For example, a node implementing the k-Means algorithm [33] might have the parameterkspecified at runtime via user input or, if not provided, a plausible value determined by Nexus. Application View — Developers write custom code to create the End- User-facing application using their preferred language and frameworks. An integrated IDE provides direct access to the repository files; for more advanced setups, full-blown desktop IDEs can be used on a local copy of the repository. This follows the usual Git versioning process, which is also done by the AI agents working on implementation tasks. From the custom application code, workflows, and service resources can be accessed via simple HTTP requests. The documentation and examples provided by the Service Registry and the Workflow Compositor provide guidelines and constraints for developers. Besides the possibility to build a custom VA application, the HTTP-based architecture of the Bon- sai Core facilitates an integration into external tools for data processing and visualization (e.g., Jupyter Notebooks [31] or BI applications [52]). 5.3 Phase C MONITOR – Supervision & Provenance The Monitor phase replaces traditional, static logging with dynamic transparency, splitting oversight into two complementary dimensions: the agent map for spatial monitoring of ongoing actions and the history and provenance component for reviewing past decisions. Agent Map View — Figure 5 demon- strates how this view provides a real-time overview of all active ADUs, rendered as an interactive 3D scene where each agent is placed within feature rooms correspond- ing to parent issues on the Issue Board. Agent type is encoded through distinct color and shape, while agent sta- tus (in development, blocked, queued, in review) is conveyed through visual accents, enabling the developer to assess fleet health at a glance. There are interactive modals for agents and rooms showing more de- tails about their states, child issues, and merge progress. Crucially, the Monitor phase is not read-only. Through the map’s integrated Conductor control panel, the human can intervene directly: commenting on a running agent to provide additional context, injecting constraints mid-execution, pausing, terminating, or redirecting tasks, and responding to clarifying questions surfaced by blocked ADUs. This preserves mixed-initiative agency throughout the implementation cycle rather than limiting human input to pre-flight configuration. Fig. 5: The Agent Map provides a real-time, spatial overview of current agent activities, statuses, and feature room assignments. Fig. 6: The provenance visualization shows the development process at different levels of semantic zoom. History & Provenance Component — The provenance component shown in Figure 6 captures a fully traceable state history, document- ing every architectural decision and treating agency handoffs as first- class provenance events to ensure complete auditability across the co- development process. We visualize provenance as a directed acyclic graph (DAG) where the x-axis encodes time and the y-axis organizes actors into horizontal swimlanes: a dedicated lane for user interac- tions at the top, followed by one lane per Squad Lead (SL), and finally groups of ADUs (e.g., backend, frontend, database, web design), each subdivided into rows for individual agent instances. Lane headers stay pinned during panning to keep actor attribution always visible, and all actors are consistently color-coded across every view in the workspace. To keep the potentially large provenance space navigable, we employ a four-level semantic zoom [8]. At zoom level ZL0, only high-level parent issues are shown for a compact project overview. At ZL1, every provenance event is rendered as a small, color-coded circle; correction events use an inverted-triangle glyph so that disruptions remain immediately recognizable. At ZL2, nodes expand into badge- header cards that show the actor’s name, a one-line summary, and a timestamp. ZL3 augments these cards with pill-shaped links to the corresponding conversation log, git diff, or agent detail view. Two visually distinct edge types connect provenance nodes: solid edges encode causal relationships (e.g., “delegated to,” “completed”), while dashed edges denote informational influence (e.g., “informed,” “reviewed”). Because orchestrator actions frequently cluster within seconds of each other, a compressed time scale shrinks idle gaps while preserving true proportions within event clusters, with axis-break marks signaling compressed regions. A corner minimap provides an overview of the full time range, enabling click-to-navigate interaction. 5.4 Phase D REVIEW – Evaluation & Iteration The final phase ensures that the co-developed VA workflow is robust, scalable, and production-ready before deployment. Merge-Gated Completion and Agency Handling — Once humans or agents complete development of an issue, it is moved to the Review column of the issue board. From there, it can advance to Completed only after its feature branch has been merged. We enforce this constraint at the system level rather than leaving it to the developer or agent discipline. This strict quality gate closes the human-AI collaboration loop: by default, only human users can trigger a merge from the review queue, and only after a successful merge does the corresponding Issue Board card advance. To calibrate development speed against control, agency sharing can be calibrated by defining rules on when Nexus may auto-review issues instead of humans. For parent issues, all child tasks must individually pass this gate before the parent’s integration branch is merged into the main branch, ensuring that no partial or unreviewed work is silently introduced into the production codebase. Iterative Live Application Review and Feedback Loop — Rather than limiting review to code diffs or static screenshots, the workspace embeds the running application in a live preview panel. Nexus starts the application by scanning for free ports on the host system. After each merge to the main branch, the development server automatically reloads, allowing users to evaluate the artifact in its intended runtime context. We distinguish two levels of feedback. At the AI level, the Squad Lead’s acceptance-criteria validation can reject worker output and au- tomatically re-queue failing ADUs with diagnostic context, without human intervention. This also means that branches leading to conflicts Fig. 7: The Live App view shows a running instance of the PODIUM app under development to enable quick testing. Identified bugs and issues can be reported via the sidebar and are added to the issue board. that cannot be resolved by the ADUs must either be reimplemented or resolved by human experts. At the human level, the Review phase em- beds a lightweight issue-reporting mechanism directly into the live ap- plication view (see Figure 7): while inspecting the running prototype, the developer can directly file new issues from a sidebar, optionally attaching an automatically captured screenshot. The reported issue is added to the task backlog with status planning, feeding back into the Plan phase as a first-class development task, subject to re-planning and re-assignment, similar to the outputs of the brainstorming session. Both loops converge on the provenance graph, where each re-queue, rejec- tion, or newly filed issue is recorded as a distinct node capturing what was rejected, why, and by whom, ensuring that the graph documents the full trajectory of refinement rather than merely the final state. 6 INTEGRATION OF AGENTIC AI Collaborative VA application development produces high-volume, am- biguous team dialogue. To translate this naturalistic input into action- able, traceable work while preserving human agency,BONSAIinte- grates agentic AI as a structured, governed participant. 6.1 Cognitive Model: Agent Hierarchy We structure agentic participation through three hierarchical roles that mirror a software development team. The top-level agent, the Nexus, monitors the collaborative transcript and parses natural-language dia- logue into typed, confidence-scored intents. It maintains a prioritized backlog, allocates responsibilities across specialized roles, and enforces policy gates that regulate automation throughput. For multi-concern tasks requiring two or more distinct agent types, the Nexus delegates work packages to Squad Lead agents. The Squad Lead decomposes a parent issue into independent child tasks, extracting explicit acceptance criteria, and enforces a four-phase pipeline (planning, clarification, file declaration, implementation); failing outputs are being re-queued with structured feedback for rework. Actual coding is performed by AI De- velopment Units, specialized sub-agents provisioned on demand from 16 registered types (e.g., frontend, backend, database), each constrained to a single architectural layer. This hierarchy implements a two-layer cognitive model that explicitly separates reasoning from execution. The Nexus operates in the cognitive layer: structuring messy, exploratory input into concrete decisions, analogous to sensemaking support in vi- sualization research. Once intents are structured, they are handed to the operational layer, where the Squad Lead and ADUs map decisions onto the formal REST APIs and validated workflow graphs of the lay- ered core architecture. The underlying runtime is never LLM-driven as agentic behavior acts strictly as a bridge from informal human intent to formal, auditable pipeline assets. 6.2 Development Workflow When a human developer introduces a new directive,BONSAIdoes not generate code immediately. Instead, the Nexus classifies the intent (e.g., directive versus exploratory hypothesis) and performs active service mining: it queries the L2 service registry and L3 workflow catalog to determine whether existingBONSAICore services already satisfy the requirements. Services that match are wired directly into the pipeline. When no admissible service exists, Nexus spawns SLs and ADUs to implement, containerize, and register a new L2 service. This new service is subject to the same interface contracts and admission checks that govern manually built components. This reuse-first strategy ensures that the service catalog grows organically with each development cycle while minimizing redundant reimplementation. As illustrated in Figure 8,BONSAIoffers agentic integration at three levels. At the service level, curated Skill Files encode layer-specific coding conventions, architectural patterns, and domain guardrails; they equip each ADU with precisely the capabilities and context knowledge needed to build or extend a component within its assigned task. At the orchestration level, a dedicated MCP Server exposes design-time oper- ations (service discovery, workflow validation, DAG composition, and deployment) as structured, bounded function calls. Because these MCP tools mirror the same operations available through the graphical work- flow designer, the identical guardrails governing human composition also govern AI-generated workflows, with no privileged code path for automated agents. In theory, human developers could even create and register new services outside ofBONSAI, if needed. ADUs are aware of the Kestra workflow specification [30] through their skill files and can compose and register orchestration pipelines programmatically via the MCP Portal. At the application level, the Visual Analytics Context Protocol (VACP) [55] embeds an MCP server directly into the appli- cation under development, granting agents structured access to inter- nal application state and data; this targeted integration enables domain- specific VA tasks (e.g., coordinated view updates, parameter steering) that pure browser-based agent control cannot reliably achieve. ADUs are scheduled as external cloud agents that receive a strictly scoped task package including an encapsulated sandbox, skill files, file- lock boundaries, and a dedicated Git feature branch. They submit code artifacts, without access to orchestration or to each other’s working con- text, preserving the bounded execution model that operationalizesR2. 6.3 Execution Constraints and Governance To ensure that the development workflow described above remains a governed process rather than unconstrained parallelism, we enforce several complementary mechanisms. Policy Gates — Before any ADU is spawned, the Nexus evaluates a se- ries of preconditions: a configurable confidence and predefined timeout thresholds determine whether intents are auto-approved or (temporar- ily) held for human confirmation; concurrency caps limit simultaneous agent execution; dependency resolution defers tasks whose prerequi- sites remain incomplete; and file-lock checks prevent agents from writ- ing to the same files. A configurable briefing pause between spawn and execution gives human developers a window to inspect or abort planned agentic tasks before code generation begins. Coordinated Staging — For multi-concern initiatives, the SL delegates orthogonal child tasks, minimizing overlapping files across concurrent ADUs. This also means that a single ADU can perform multiple tasks in a single run when similar files must be modified. When all ADU workers are finished, the Squad Lead validates results against the required acceptance criteria using a structured evaluation; failing MW Portal Workflow Orchestrator Service A RESTFul Service BService C Queue- Based Streaming Sync Star Pattern ... ... protected namespace Application 1 Application 2... Webhook Event Endpoint Server- Sent Events (SSE) External Application Service Registry Direct IAM VACP Application Building Skill Portal MCP Service Implementation Skill Agentic AI V C P V AUTH GW Bearer- Token- Based IAM Bearer- Token- Based IAM Fig. 8: Agentic integration points within theBONSAIarchitecture. AI agents connect through three levels: Skill Files for service and application development, the MCP server for orchestration-layer operations, and VACP for structured interaction with the application’s internal state. outputs are rejected with specific feedback and re-queued, up to a configurable number of cycles before escalation to human review. Branch Isolation and Merge Governance — Every ADU operates on a dedicated, separate Git feature branch. Parent issues receive an inte- gration branch; child ADUs merge back into it upon successful com- pletion. Only after the combined results of all ADUs pass the Squad Lead’s review, Nexus permits merging the integration branch back into the main branch. When outstanding branches exceed a configurable threshold or merge conflicts arise, a specialized Merge ADU handles conflict resolution, ensuring that the merge process itself remains gov- erned. If merge conflicts cannot be resolved, the results of correspond- ing branches are summarized and retriggered for implementation. Architectural Drift Prevention — Two mechanisms jointly ad- dressR2by counteracting context degradation. First, the Nexus’s ser- vice mining actively surfaces reuse opportunities before any new code is written, keeping human developers informed of what the AI reuses ver- sus what it generates from scratch. Second, skill files do not merely pro- vide coding guidance; they encode the structural conventions each ser- vice must satisfy (e.g., OpenAPI contract requirements, admission crite- ria, layer-specific interface patterns). Together, service mining and skill- encoded guardrails ensure that AI-generated components conform to the platform’s architectural standards rather than silently introducing drift. 7 SYSTEM VALIDATION & USE CASES Evaluating a comprehensive architectural framework for human-AI co- development presents a methodological challenge that time-boxed con- trolled studies cannot adequately address: the longitudinal friction of dependency management, iterative design, and multi-agent coordina- tion in real VA projects unfolds over weeks or months, not a single ses- sion. We therefore adopt a systems-validation methodology common in HCI and visualization infrastructure research and evaluate theBONSAI workspace through two representative replication use cases [14]. Rather than cataloging outcomes in abstract capability buckets, we present each case as a walkthrough tracing workspace views, human decisions, and agent handoffs. The Semantic Color Mapping [17] case tests how effectively the workspace leverages an existing L2-service- catalog to simplify the build scope through reuse. The PODIUM [57] case tests the converse: zero catalog matches, forcing the architecture to decompose a paper into independent services built from scratch. Together, the two cases span the reuse spectrum and reveal how the same orchestration framework supports both extremes. 7.1UC1: Component Extraction: Semantic Color Mapping The Semantic Color Mapping (SCM) pipeline [17] is a recurring build- ing block across several VA systems, comprising a staged process from aggregated text data through vector representations to perceptual color assignment. In practice, it has historically been embedded deep within monolithic codebases such as the generAItor system [51]. We evaluate whetherBONSAIcan extract this logic from the existing monolith and reconstitute it as a composable workflow built entirely from existing middleware services, avoiding redundant reimplementation. Development Walkthrough — Cooperating with Nexus, we began in Phase A by decomposing the SCM process into its constituent stages: keyword extraction, embedding computation, dimensionality reduction, and 2D color-map assignment. We also clearly defined how each of these steps must be sequentially connected for seamless transitions. Moving on to Phase B , we asked Nexus to assemble a workflow that constitutes the SCM pipeline. Leveraging the MCP tool for service catalog search,BONSAIidentified that four of the required processing stages were available as microservices, ready for direct use. Conse- quently, the agent determined that mostly orchestration-level plumbing was required to connect the existing services into a valid DAG. Dur- ing the first composition attempt, the CType system flagged a schema mismatch between the embedding service’s output format and the pro- jection service’s expected input structure. Because the error message localized the incompatibility to a specific field-level type conflict, the ADU resolved the discrepancy by inserting a lightweight adapter node, addressing the input and output mismatches. Throughout both attempts, we tracked the ADU’s status transitions on the agent map inPhase C. Vector Representations Projection Method Color Map WordNetUMAPBremm et al. Word2Vec BERT T- SNE PCA Schuhmann, Urban Steiger et al. x2 x1 x0 Unit of Analysis Topics Keywords Sentiments x2 x1 Embedding LLM ... Semantic Color Mapping Flow Service Service Service Service Flow Inputs Text (Input) Selected Colormap (Parameter) Final Application Flow Outputs Fig. 9: The SCM pipeline [17] comprises multiple steps with clear in- terfaces before visual encoding is possible. The separate nodes in this pipeline represent separate building blocks covered by independent ser- vices provided by the BONSAI Core. In the second iteration, the workflow passed all structural validation checks for theBONSAICore and executed end-to-end, producing se- mantically meaningful color mappings consistent with the original de- scription. This yielded a working mini-application that we inspected in Phase D , exposing input forms and a visualization of the workflow’s output. Figure 9 shows the interface, with arrows indicating the data flow between the application and BONSAI’s Core. Lessons Learned — This case study surfaces three observations rele- vant to the design of mixed-initiative co-development workspaces. First, without explicit instruction, Nexus distills the requirements for the given situation to identify whether there are existing service modules that can already be employed instead of reinventing the wheel. Early versions of BONSAIlacked this behavior; dedicated skill files that prioritize catalog search over regeneration fixed it. Second, the structural type system is essential for third-party service reuse. When an ADU implements a ser- vice itself, it implicitly controls both sides of every interface. Reusing a pre-existing service removes this control; the ADU must conform to an interface it did not author. The CType system closes this gap by disclos- ing precise, field-level incompatibilities at design time, enabling the ADU to correct mismatches before runtime execution. Third, reusabil- ity dramatically reduces implementation effort. Because the middle- ware already contained all required processing stages, validated, and production-grade, the entire extraction task was reduced to the orches- tration layer. Compared to a from-scratch reimplementation, this ap- proach required only two ADU iterations. It demonstrated that a well- populated service catalog combined with strong interface contracts can transform complex feature migration into a lightweight wiring exercise. 7.2 UC2: System Reconstruction: PODIUM Wall et al.’s PODIUM [57] couples a tabular ranking interface with a Ranking SVM trained from drag-and-drop preferences. We selected it to contrast the previous Semantic Color Mapping (SCM) use case: service mining found no admissible L2 matches in the registry, meaning the architecture had to decompose the paper into independent services built entirely from scratch and composed through REST interfaces. A further objective was to demonstrate thatBONSAI, with human steering, can replicate a complex paper from a single source, yielding a high- fidelity, interactive prototype for pedagogical or demo use. Rather than relying on unconstrained “vibe-coding,” which typically yields a brittle, opaque monolith, we usedBONSAIto produce a rigorously architected, modular system that students can dismantle, inspect, and build upon. Development Walkthrough — The whole development process is summarized in Figure 10: DuringPhase A, we initiated the workflow by providing Nexus with a direct link to the PODIUM manuscript PDF in the brainstorming chat. Nexus retrieved the document and successfully extracted the core system components. It then proactively asked clarifying questions regarding the underlying machine learning architecture. We explicitly directed the Nexus to strictly adhere to the paper’s original Ranking SVM rather than introducing modern LLM- based explanation features. A notable success during this phase was the underlying model’s multimodal reasoning: the Nexus was able to process figures from the paper and automatically attach relevant UI mockups and architectural diagrams directly to the child issues. Subsequently, Nexus delegated the remaining implementation tasks to squad leads via issues on the issue board. InPhase B, the squad leads then instructed ADUs to implement the required backend services Fig. 10: Given a publication (as PDF), users can employ the brainstorm- ing chat to extract relevant parts of existing techniques, identify service, workflow, and implementation requirements, reuse existingBONSAICore services, and reimplement missing modules based on the four stages. as well as the visualization frontend. DuringPhase C, we monitored squad-lead delegation and ADU progress on the provenance graph, intervening via the Conductor panel when agents became blocked. After an initial implementation had been produced, we performed several feedback loops via the Live App view’s annotation feature (see Figure 7) to adjust the visual styling and interaction affordances in Phase D. Ultimately, we received a set of microservices and a modern frontend that could serve as a showcase for students to demonstrate the service- and worflow-based development process. Lessons Learned — This case study surfaces four critical observa- tions regarding the reconstruction of complex academic systems. First, agentic paper-to-code reconstruction is a highly viable pathway for re- viving legacy research. The workspace successfully translated a static PDF description into a live, interactive VA application without requir- ing access to the original source code. This demonstrates significant promise for democratizing access to older, unpublished, or deprecated visualization techniques that would otherwise be lost to software rot. Second, managing high-complexity deployments requires strict layer separation. Unlike simpler extractions, the PODIUM reconstruction involved a frontend, a backend, and seven distinct, interconnected mi- croservices (including a dataset provider and an SVM-based weight solver). By enforcing the 4-layer architecture,BONSAIensured that the Application ADUs and Service ADUs could generate code concur- rently without tangling the complex state logic. Third, strict service registry admission introduces friction during rapid prototyping cycles. BecauseBONSAIrequires human review before a newly generated ser- vice can be officially admitted and scheduled by the orchestrator, fast development loops can become bottlenecked. During the PODIUM build, pending components had to be evaluated in a local development environment. To mitigate this scheduling delay and keep the orchestra- tion workflow intact, we found that developers can temporarily mock service functionality using inline code snippets that Kestra can process until the formal review is complete. 8 DISCUSSION, LIMITATIONS, & FUTURE WORK WhileBONSAIdemonstrates how bounded orchestration resolves the sociotechnical friction of agentic VA development, its design involves deliberate trade-offs worth examining. This section reflects on key de- sign decisions, discusses agency distribution and ecosystem dynamics, and outlines pathways for future contributions. Learning Curve of the Layered Architecture — AdoptingBONSAI requires developers to internalize the four-layer mental model and inter- face requirements before contributing a service, which may deter those accustomed to flatter architectures, where immediate code execution takes priority. To mitigate this, we propose two complementary mecha- nisms. First, layer-specific skill files enable developers to engage in a natural dialog with agentic AI about architectural conventions, effec- tively turning static documentation into an interactive learning resource. Second, we are developing Onboarding ADUs that auto-generate boiler- plate OpenAPI contracts and scaffold compliant project structures. To- gether, these mechanisms aim to reduce the time-to-first-service while preserving the rigor that underpins cross-project reusability. Automated Architectural Auditing and Governance — A practi- cal bottleneck in scalingBONSAI’s ecosystem is the manual review re- quired to admit new services, which constrains throughput as the cata- log grows. We see complementary directions for addressing this. First, Auditor ADUs can automate static analysis and compliance checks, flagging non-compliant components before human review. Second, a staging mechanism with time-limited deployment would allow newly developed services to be tested in a sandbox before formal admission. The Trade-off: Guardrails vs. Creative Flexibility — The core philosophy ofBONSAIrelies on the premise that unconstrained “vibe coding” must be deliberately pruned using explicit interface con- tracts. However, this introduces a mandatory, contract-first develop- ment paradigm. In traditional, monolithic environments, developers can fluidly and chaotically experiment with UI and backend logic simul- taneously.BONSAI’s strict separation of concerns requires the Nexus and human developers to define data schemas and OpenAPI specifi- cations before the Application ADUs can effectively generate the in- terface. While this upfront sociotechnical friction drastically reduces downstream debugging and architectural drift, it inherently limits the unstructured, “blank canvas” momentum that some developers prefer during early-stage exploratory ideation. Agency Distribution Across the Human-AI Spectrum —BONSAI’s four-phase workflow makes no assumption about agency distribution between human and AI contributors. At one extreme, a developer com- pletes all phases manually, treating the workspace as an architectural scaffold. At the other end, the Nexus decomposes, delegates, and vali- dates entire feature sets while the human acts solely as a conductor. In practice, a natural middle ground emerges: developers retain control over design-critical decisions (goal setting, interface contracts, accep- tance criteria) while delegating repetitive tasks to ADUs. This flexibility mirrors the ongoing shift in software engineering, where developer roles evolve from writing code toward orchestrating and steering AI-generated artifacts.BONSAIaccommodates this transi- tion by design: the same guardrails, provenance tracking, and review mechanisms apply regardless of whether a human or AI authored a com- ponent. As frontier models improve, we expect the automation bound- ary to shift further toward high-level design tasks, makingBONSAI’s bounded orchestration model increasingly relevant. Ecosystem Dynamics & Reuse-First Development — The two case studies reveal a self-reinforcing dynamic at the core ofBONSAI’s ser- vice ecosystem. UC2 required building all services from scratch, yet the resulting component became available for future projects upon ad- mission. UC1 demonstrates the benefit: most processing stages already existed as microservices from other projects, mostly reducing pipeline construction to orchestration-level wiring in only two ADU iterations. This flywheel effect is a direct consequence ofBONSAI’s architec- tural enforcement of modularity and reuse. Because every service must satisfy typed interface contracts and pass admission checks inde- pendently of any particular application, components produced by one project are natively composable in contexts their original developers never anticipated. Additionally, MCP-exposed service discovery en- sures agents receive only relevant service definitions for their current task, preventing context-window saturation as the catalog grows. 9 CONCLUSION The rapid evolution of generative AI offers unprecedented prototyping speed but also introduces severe sociotechnical risks, often yielding opaque, tightly coupled monoliths in which developers lose the causal thread of system evolution. To bridge the gap between unconstrained coding and rigorous software engineering, we introducedBONSAI, a framework that replaces unconstrained full-stack code generation with bounded orchestration across a four-layer architecture. Through explicit interface contracts,BONSAIdistills the context window for specialized ADUs, ensuring analytical logic is cleanly extracted into reusable mi- croservices. Crucially, its structured four-phase workspace treats se- mantic provenance as a first-class citizen, guaranteeing a legible his- tory of agency handoffs. Ultimately, much like cultivating its name- sake,BONSAIdemonstrates that sustainable multi-agent development requires deliberate structure and guided oversight, ensuring that next- generation Visual Analytics applications remain scalable, maintainable, and firmly under human expert control. The system and its source code will be available at bonsai.ivia.ch. REFERENCES [1]S. Amershi, D. Weld, M. Vorvoreanu, A. Fourney, B. Nushi, P. Collisson et al. Guidelines for human-AI interaction. In Proceedings of the 2019 CHI Conference on Human Factors in Computing Systems, 2019. doi: 10. 1145/3290605.3300233 2 [2] Anthropic. Model context protocol (MCP): Open standard for AI applica- tion integration, 2024. Donated to Agentic AI Foundation (Linux Founda- tion), Dec 2025. 2 [3] Anthropic. Claude code: Agentic coding tool, 2025. 2 [4] Anysphere. Cursor: The AI-first code editor, 2025. 2 [5] Anysphere (Cursor). Agent trace: An open specification for AI code attribution, 2026. 1, 2 [6]Apache Software Foundation. Apache Airflow documentation, 2024. Originally developed at Airbnb in 2014. 2 [7] S. Barke, M. B. James, and N. Polikarpova. Grounded copilot: How pro- grammers interact with code-generating models. Proceedings of the ACM on Programming Languages, 7(OOPSLA1), art. no. 78, 2023. Distin- guished Paper Award, OOPSLA 2023. doi: 10.1145/3586030 1 [8] B. B. Bederson and J. D. Hollan. Pad++: a zoomable graphical interface system. In Conference Companion on Human Factors in Computing Systems, CHI ’95, p. 23–24. Association for Computing Machinery, New York, NY, USA, 1995. doi: 10.1145/223355.223394 6 [9]M. R. Berthold, N. Cebron, F. Dill, T. R. Gabriel, T. Kötter, T. Meinl et al. KNIME – the Konstanz information miner: Version 2.0 and beyond. ACM SIGKDD Explorations Newsletter, 11(1):26–31, 2009. doi: 10.1145/ 1656274.1656280 2 [10]S. P. Callahan, J. Freire, E. Santos, C. E. Scheidegger, C. T. Silva, and H. T. Vo. VisTrails: Visualization meets data management, 2006. doi: 10. 1145/1142473.1142574 2 [11] D. Ceneda, N. Andrienko, G. Andrienko, T. Gschwandtner, S. Miksch, N. Piccolotto et al. Guide me in analysis: A framework for guidance designers. Computer Graphics Forum, 39(6):269–288, 2020. doi: 10. 1111/cgf.14017 2 [12] D. Ceneda, T. Gschwandtner, T. May, S. Miksch, H.-J. Schulz, M. Streit et al. Characterizing guidance in visual analytics. IEEE Transactions on Visualization and Computer Graphics, 23(1):111–120, 2017. doi: 10. 1109/TVCG.2016.2598468 2 [13] Z. Cutler, K. Gadhave, and A. Lex. Trrack: A library for provenance- tracking in web-based visualizations. In IEEE VIS 2020 Short Papers, p. 116–120, 2020. doi: 10.1109/VIS47514.2020.00030 2 [14]Z. Cutler, J. Wilburn, H. Shrestha, Y. Ding, B. Bollen, K. A. Nadib et al. ReVISit 2: A full experiment life cycle user study framework. IEEE Transactions on Visualization and Computer Graphics, 32, 2026. IEEE VIS 2025 Best Paper Award. 8 [15]Z. Ding, E. Jun, J. Chan, and D. Moritz. “The Diagram is like Guardrails”: Structuring GenAI-assisted hypotheses exploration with an interactive shared representation. In Proceedings of the 2025 Conference on Creativity and Cognition (C&C), 2025. doi: 10.1145/3698061.3726935 2 [16]K. Eckelt, K. Gadhave, A. Lex, and M. Streit. Loops: Leveraging prove- nance and visualization to support exploratory data analysis in notebooks. IEEE Transactions on Visualization and Computer Graphics, 2024. Proc. IEEE VIS 2024. doi: 10.1109/TVCG.2024.3456320 2 [17]M. El-Assady, R. Kehlbeck, Y. Metz, U. Schlegel, R. Sevastjanova, F. Sper- rle et al. Semantic color mapping: A pipeline for assigning meaningful colors to text. In IEEE Workshop on Visualization Guidelines in Research, Design, and Education (VisGuides), 2022. doi: 10.1109/VisGuides57787. 2022.00008 8 [18] M. El-Assady, F. Sperrle, O. Deussen, D. Keim, and C. Collins. Visual analytics for topic model optimization based on user-steerable speculative execution. IEEE Transactions on Visualization and Computer Graphics, 25(1):374–384, 2019. doi: 10.1109/TVCG.2018.2864769 2 [19] Elementl. Dagster: Cloud-native data pipeline orchestrator, 2024. 2 [20] A. Fourney, G. Bansal, H. Mozannar, C. Tan, et al. Magentic-One: A generalist multi-agent system for solving complex tasks. arXiv preprint arXiv:2411.04468, 2024. 2 [21] Google. Agent2agent protocol (A2A), 2025. v0.3, July 2025. Now under Linux Foundation. 2 [22]S. Gratzl, A. Lex, N. Gehlenborg, N. Cosgrove, and M. Streit. From visual exploration to storytelling and back again. Computer Graphics Forum, 35(3):491–500, 2016. doi: 10.1111/cgf.12925 2 [23]P. F. Gyarmati, D. Moritz, T. Möller, and L. Koesten. Structured visual- ization design knowledge for grounding generative reasoning and situated feedback, 2025. doi: 10.48550/ARXIV.2512.20306 5 [24] J. Heer and D. Moritz. Mosaic: An architecture for scalable & interopera- ble data views. IEEE Transactions on Visualization and Computer Graph- ics, 30(1):436–446, 2024. doi: 10.1109/TVCG.2023.3327189 2 [25]S. Hong, M. Zhuge, J. Chen, X. Zheng, Y. Cheng, J. Wang et al. MetaGPT: Meta programming for a multi-agent collaborative framework. In The Twelfth International Conference on Learning Representations (ICLR), 2024. Oral Presentation. 2 [26] E. Horvitz. Principles of mixed-initiative user interfaces. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (CHI ’99), p. 159–166, 1999. doi: 10.1145/302979.303030 2 [27] JetBrains. JetBrains Junie AI Agent, 2025. 2 [28] M. B. Jones and D. Hardt. The OAuth 2.0 Authorization Framework: Bearer Token Usage. RFC 6750, Oct. 2012. doi: 10.17487/RFC6750 5 [29]D. A. Keim, G. Andrienko, J.-D. Fekete, C. Görg, J. Kohlhammer, and G. Melançon. Visual analytics: Definition, process, and challenges. In Information Visualization: Human-Centered Issues and Perspectives, p. 154–175. Springer, 2008. doi: 10.1007/978-3-540-70956-5_7 1 [30]Kestra Technologies. Kestra: Open-source orchestration platform.https: //kestra.io, 2026. Accessed: 2026-03-30. 2, 5, 7 [31] T. Kluyver, B. Ragan-Kelley, F. Pérez, B. Granger, M. Bussonnier, J. Fred- eric et al. Jupyter notebooks – a publishing format for reproducible com- putational workflows. In F. Loizides and B. Schmidt, eds., Positioning and Power in Academic Publishing: Players, Agents and Agendas, p. 87 – 90. IOS Press, 2016. 6 [32]N. F. Liu, K. Lin, J. Hewitt, A. Paranjape, M. Bevilacqua, F. Petroni et al. Lost in the middle: How language models use long contexts. Transactions of the Association for Computational Linguistics, 12:157–173, 2024. doi: 10.1162/tacl_a_00638 1 [33]S. Lloyd. Least squares quantization in pcm. IEEE Transactions on Information Theory, 28(2):129–137, Mar. 1982. doi: 10.1109/tit.1982. 1056489 6 [34]S. Monadjemi, Y. Guo, K. Xu, A. Endert, and A. Crisan. A scoping review of mixed initiative visual analytics in the automation renaissance. arXiv preprint arXiv:2509.19152, 2025. 2 [35]D. Moritz, C. Wang, G. L. Nelson, H. Lin, A. M. Smith, B. Howe et al. Formalizing visualization design knowledge as constraints: Actionable and extensible models in Draco. IEEE Transactions on Visualization and Computer Graphics, 25(1):438–448, 2019. InfoVis 2018 Best Paper Award. doi: 10.1109/TVCG.2018.2865240 2 [36]H. Nielsen, R. T. Fielding, and T. Berners-Lee. Hypertext Transfer Protocol – HTTP/1.0. RFC 1945, May 1996. doi: 10.17487/RFC1945 5 [37] OpenAI. Codex: Cloud-based software engineering agent, 2025. 2 [38] D. L. Parnas. On the criteria to be used in decomposing systems into modules. Communications of the ACM, 15(12):1053–1058, Dec. 1972. doi: 10.1145/361598.361623 1 [39]H. Pearce, B. Ahmad, B. Tan, B. Dolan-Gavitt, and R. Karri. Asleep at the keyboard? assessing the security of GitHub Copilot’s code contributions. In 2022 IEEE Symposium on Security and Privacy (S&P), p. 754–768, 2022. doi: 10.1109/SP46214.2022.9833571 1, 2 [40]S. Peng, E. Kalliamvakou, P. Cihon, and M. Demirer. The impact of AI on developer productivity: Evidence from GitHub Copilot. arXiv preprint arXiv:2302.06590, 2023. 2 [41]N. Perry, M. Srivastava, D. Kumar, and D. Boneh. Do users write more insecure code with AI assistants?In Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security (CCS), 2023. doi: 10.1145/3576915.3623157 1, 2 [42]S. Prakash. LDP: An identity-aware protocol for multi-agent LLM systems. arXiv preprint arXiv:2603.08852, 2026. 2 [43] Prefect Technologies. Prefect: Modern workflow orchestration, 2024. 2 [44]E. D. Ragan, A. Endert, J. Sanyal, and J. Chen. Characterizing provenance in visualization and data analysis: An organizational framework of prove- nance types and purposes. IEEE Transactions on Visualization and Com- puter Graphics, 22(1):31–40, 2016. doi: 10.1109/TVCG.2015.2467551 2 [45]A. Satyanarayan, D. Moritz, K. Wongsuphasawat, and J. Heer. Vega-Lite: A grammar of interactive graphics. IEEE Transactions on Visualization and Computer Graphics, 23(1):341–350, 2017. InfoVis 2016 Best Paper Award. doi: 10.1109/TVCG.2016.2599030 2 [46] A. Satyanarayan, R. Russell, J. Hoffswell, and J. Heer. Reactive Vega: A streaming dataflow architecture for declarative interactive visualization. IEEE Transactions on Visualization and Computer Graphics, 22(1):659– 668, 2016. doi: 10.1109/TVCG.2015.2467091 2 [47]R. Souza, A. Gueroudji, S. DeWitt, D. Rosendo, T. Ghosal, R. Ross et al. PROV-AGENT: Unified provenance for tracking AI agent interactions in agentic workflows. In Proceedings of the 21st IEEE International Conference on e-Science, p. 467–473, 2025. 1, 2 [48] F. Sperrle, D. Ceneda, and M. El-Assady. Lotse: A practical framework for guidance in visual analytics. IEEE Transactions on Visualization and Computer Graphics, 29(1):1124–1134, 2023. doi: 10.1109/TVCG.2022. 3209456 2 [49]F. Sperrle, A. Jeitler, J. Bernard, D. A. Keim, and M. El-Assady. Co- adaptive visual data analysis and guidance processes. Computers & Graph- ics, 100:93–105, 2021. doi: 10.1016/j.cag.2021.06.016 2 [50] F. Sperrle, H. Schäfer, D. A. Keim, and M. El-Assady. Learning contextu- alized user preferences for co-adaptive guidance in mixed-initiative topic model refinement. Computer Graphics Forum, 40(3):215–226, 2021. doi: 10.1111/cgf.14301 2 [51]T. Spinner, R. Kehlbeck, R. Sevastjanova, T. Stähle, D. A. Keim, O. Deussen et al. generaitor: Tree-in-the-loop text generation for language model explainability and adaptation. ACM Transactions on Interactive Intelligent Systems, 14(2):1–32, June 2024. doi: 10.1145/3652028 8 [52] G. Srivastava, M. S, R. Venkataraman, K. V, and P. N. A review of the state of the art in business intelligence software. Enterprise Information Systems, 16(1):1–28, Jan. 2021. doi: 10.1080/17517575.2021.1872107 6 [53]T. Stähle, M. Jansen op de Haar, S. Boyer, R. Sevastjanova, A. Narechania, and M. El-Assady. A design space for intelligent agents in mixed-initiative visual analytics. arXiv preprint arXiv:2512.23372, 2025. 2 [54]H. Stitz, S. Luger, S. Gratzl, and M. Streit. AVOCADO: Visualization of workflow–derived data provenance for reproducible biomedical research. Computer Graphics Forum, 35(3):481–490, 2016. doi: 10.1111/cgf.12924 2 [55]T. Stähle, P. F. Gyarmati, T. Spinner, R. Sevastjanova, D. Moritz, and M. El-Assady. Vacp: Visual analytics context protocol, 2026. doi: 10. 48550/ARXIV.2603.29322 7 [56]Various. Vibe coding: Programming through conversation with artificial intelligence. arXiv preprint arXiv:2506.23253, 2025. 1 [57]E. Wall, S. Das, R. Chawla, B. Kalidindi, E. T. Brown, and A. Endert. Podium: Ranking data using mixed-initiative visual analytics. IEEE Trans. Vis. Comput. Graph., 24(1):288–297, 2018. doi: 10.1109/TVCG.2017. 2745078 8 [58] Windsurf Inc. Windsurf Editor, 2026. 2 [59]K. Wongsuphasawat, Z. Qu, D. Moritz, R. Chang, F. Ouk, A. Anand et al. Voyager 2: Augmenting visual analysis with partial view specifications. In Proceedings of the 2017 CHI Conference on Human Factors in Computing Systems, p. 2648–2659, 2017. doi: 10.1145/3025453.3025768 2 [60] Q. Wu, G. Bansal, J. Zhang, Y. Wu, S. Zhang, E. Zhu et al. AutoGen: Enabling next-gen LLM applications via multi-agent conversation. arXiv preprint arXiv:2308.08155, 2023. 2 [61]K. Xu, A. Ottley, C. Walchshofer, M. Streit, R. Chang, and J. Wenskovitch. Survey on the analysis of user interactions and visualization provenance. Computer Graphics Forum, 39(3):757–783, 2020. doi: 10.1111/cgf.14035 2 [62]J. Yang, C. E. Jimenez, A. Wettig, K. Lieret, S. Yao, K. Narasimhan et al. SWE-agent: Agent-computer interfaces enable automated software engineering. In Thirty-Eighth Annual Conference on Neural Information Processing Systems (NeurIPS), 2024. 1

Instant research discovery