arXiv CSopen access

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

BONSAI : A Mixed-Initiative Workspace for Human-AI

Co-Development of Visual Analytics Applications Thilo Spinner

, Matthias Miller

, Fabian Sperrle-Roth

, Mennatallah El-Assady

Iterate

Ideation AI Agents Nexus

Design Workspace Setup

Issue Board

AI Agent Management

Service Layer

Orchestration Application Layer Layer

Pipeline Editor

Worker 1 ...

Task

Modularity and Reuse with Augmented Planning

arXiv:2604.19247v1 [cs.HC] 21 Apr 2026

Hardware Layer

Node A

Logs

Monitor

Node B Node D

Node C

MCP

Plan

AI Agent Chat

Current Agent History & View Provenance

Review Code Analysis

Health & Cost

Revisions

Parameters

Node E

Architecture Guardrails using Interface Contracts

Application Preview

Automated Testing

Column A

Collaborative Development and Provenance Tracking

Performance Metrics

Versioning

Dashboard

Parameters

Column B

Efficient Validation and Agentic Evaluation

Column C

Dashboard

CI/CD Column A

Column B

Column C

End-​User-​Facing Application

Fig. 1: The structured four-phase workflow of the BONSAI mixed-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 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.

1

I NTRODUCTION

Developing data-driven Visual Analytics (VA) applications is inherently 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 extracting 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 resulting 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 automated 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 interface 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 orchestration layer provides centralized management components (authentication, service registry, workflow orchestrator) powering DAGbased 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 information scope that any developer or agent needs to hold at once, and the abstraction barrier prevents upper layers from reaching through to bypass or alter lower-layer implementations. By applying these standard good practices, we transform the unconstrained “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 responsibilities 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 workflow logic, service developers on atomic data-processing algorithms, and DevOps engineers on the underlying execution environments. Under this level of bounded expert control, agentic systems unlock massive potential, including the rapid reconstruction of complex VA appli-

cations directly from research papers that lack published source code. To operationalize this scaffold, we introduce BONSAI, a mixedinitiative workspace for the human–AI co-development of data-driven VA applications. Its name signals our stance: like cultivating a BONSAI tree, generative code changes represent organic growth that still demands deliberate structure, pruning, and guided oversight if the product is to stay robust and inspectable. The workspace organizes collaboration 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 throughout development, rather than collapsing into a single opaque transcript. Specifically, this paper makes four principal contributions: (1) a conceptual analysis of human–AI co-development tailored to VA applications, emphasizing the necessity of modularity, reuse, guardrails, interface 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 BONSAI workspace, 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 demonstrating the system’s effectiveness in rapidly reconstructing complex VA applications from research paper descriptions. 2

R ELATED W ORK

BONSAI sits at the intersection of workflow orchestration, visualization architecture design, mixed-initiative human-AI collaboration, provenance 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 orchestration 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 with BONSAI’s typed interface contracts. KNIME [9] offers a visual node-based interface for composing analytical pipelines. However, these tools target batch processing and do not address the interactive feedback loops of VA applications nor bounded human-AI co-development. BONSAI extends their declarative philosophy with a layered architecture for VA pipeline construction, 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 visualization design as a constraint satisfaction problem in Draco [35], enabling automated encoding recommendations. Heer and Moritz proposed Mosaic [24], decoupling visualization clients from a scalable query engine—a separation of concerns paralleling BONSAI’s layered design. Wongsuphasawat et al. showed with Voyager 2 [59] how partial 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—validating BONSAI’s pipeline editors as cognitive scaffolds. These systems advance visualization rendering, recommendation, 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 mixedinitiative 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 knowledge 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. BONSAI transfers these principles to the development process, guiding developers and agents through the co-construction of VA applications and distributing agency across architectural layers and phases. Provenance Tracking in Visual Analytics — Provenance—the systematic 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 hierarchical aggregation—a challenge mirrored in BONSAI’s multi-agent development histories. CLUE [22] enables capturing and explaining provenance 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 agentcentric entities, while Cursor’s Agent Trace [5] addresses AI code attribution at the file level. These contributions provide mature models 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. BONSAI treats 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 development environments for code generation and increasingly autonomous task execution. In the multi-agent space, MetaGPT [25] encodes 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] addresses 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 baselines. 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 overestimate its security. These findings expose three gaps: (1) existing tools operate as monolithic agents without distribution of agency across architectural boundaries; (2) provenance is limited to git-level attribution, missing fine-grained human–AI interplay; and (3) the absence of guardrails—typed contracts, bounded contexts—leads to contextwindow 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

P ROBLEM C HARACTERIZATION

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 architectural 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+ students per cohort) building complex VA pipelines, then used longitudinal observations of recurrent failures (e.g., dependency conflicts, brittle cross-layer contracts, and poor reproducibility) to design the BONSAI

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, BONSAI aligns its abstractions with four groups: End-Users audit and steer application behavior via feedback, Application Developers build UI and interaction logic, Service Developers build algorithms, models, and service contracts, and DevOpsEngineers 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 Dependency Hell. Traditionally, VA tools are built as highly specialized, oneoff monolithic architectures, leading to tremendous dependency trees virtually impossible to maintain. Updating individual packages often entails an avalanche of incompatibilities between upstream dependencies which are hard or even impossible to resolve. Related, accessibility of useful software components is limited by the ch02 (Re-)Usability Bottleneck. Extracting useful standalone functionalities from a monolith is non-trivial: components are typically entangled with application-specific logic and glue code, making isolation labor-intensive and error-prone. The problem is compounded for research-driven VA tools, where novel techniques are frequently published without well-maintained implementations, forcing developers to spend significant effort re-implementing algorithms from paper descriptions before any integration work can begin. Second, as generative AI is introduced to speed up development, systems suffer from ch03 Architectural Drift and Context Degradation. 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 accelerates 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 exacerbates ch04 Loss 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: git histories 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 face ch05 Fragile Compliance Across Heterogeneous Deployment Stacks. Applications routinely carry operational and regulatory 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 originate at the application level, their enforcement must happen at the infrastructure level. Without a structural bridge between the two, compliance 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 environments 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, multiagent co-development in the BONSAI workspace. R1 Modularity and Reuse — To resolve ch01 and ch02 , 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 architecture 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. R2 Guardrails and Context Distillation — To address ch03 and reliably manage ch05 , the architecture must provide strict boundaries that naturally distill the context for both human developers and agentic 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 dependency resolution and validity checks. This deliberate context distillation 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 welldocumented, 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. R3 Provenance Tracking and Agency Sharing — To overcome ch04 , the system must explicitly reject unconstrained generative workflows in favor of formal agency sharing, where humans and AI collaborate 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. Crucially, this provenance tracking cannot rely solely on generic, one-sizefits-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 history, enabling developers to audit, steer, or roll back the co-creation process at any time. 4

B ONSAI ’ S L AYERED C ORE

To satisfy the aforementioned requirements ( R1 , R2 , R3 ) and physically isolate the operational domains of our target user groups, we introduce 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 assistive AI agents. As detailed in the following subsections, each layer contributes distinct and complementary mechanisms that together operationalize 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 distillation ( R2 ) embedded structurally at every level rather than imposed by post-hoc convention; and the architectural foundations for provenance and agency attribution ( R3 ), which the BONSAI workspace (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 below. 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 requirements 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 contract. 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 parameters, and consume structured results interactively.

End-​user-​facing Inputs Config Application 1

Application Layer L4 Orchestration Layer Dependency Resolution Scheduling Authentication Reporting L3 Service Service Implementation Layer Service Discovery Monitoring L2 Hardware Layer Supercomputing L1 End-​user-​facing Application 2

Results / Errors

Node A

Workflow 1 Node B

..

Service A

Service B

Service C

On-​Premise

Hyperscaler

k8s Research

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 infrastructure required for heterogeneous VA execution. Beyond resource pooling, it implements a three-part cross-layer constraint satisfaction mechanism that directly addresses R2 : applicationlevel 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 workflow 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 execution 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 specialized backend AI agents. A (micro)service is a small, independently deployable software component that encapsulates a single AI or dataprocessing capability and exposes it through a typed, validated OpenAPI contract. The microservice-based architecture is strictly motivated at this layer to address R1 : 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 dataprocessing algorithms and machine learning models. To be admitted to the Service Registry and, thus, become discoverable by the orchestration 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 admission checks are enforced before a service becomes visible to any work-

flow or AI agent, ensuring that only well-specified, compatible components enter the shared ecosystem. Developer and Agent Guidance — To guide both human developers and AI coding agents in meeting these requirements, BONSAI provides skill files (curated, machine-readable documents encoding coding conventions, 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 contract provides a semantically complete, implementation-agnostic description 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 services (L2) with applications (L4). It manages real-time execution, service discovery, and automatic dependency resolution, while serving as the architectural locus for three complementary guardrail mechanisms. Centralized Identity and Access Management — L3 provides a stateless 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 required 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 for R3 . Structured Workflow Composition — Application logic in L3 is expressed as directed acyclic graphs (DAGs) through a workflow designer that enforces a strict visual and textual grammar: nodes represent registered 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 another CType—which checks that the output types of upstream nodes precisely match the expected input types of downstream nodes, catching structural mismatches already during design-time. Once validated, the DAG is automatically transpiled into an executable flow and dispatched 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 computation and ensuring responsive UI interactions. Because service discovery is continuous, newly registered L2 services immediately become composable nodes without requiring platform downtime or reconfiguration, 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 Application 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, BONSAI provides skill files, component

templates, and curated library recommendations that encode best practices for connecting applications to the underlying platform [23]. These resources reduce decision overhead without prescribing a fixed implementation, operationalizing R2 at the application level within the inherent 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, correctness, 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. Admission 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 administrators. 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 authorization gateway, which in turn validates the token against the access control 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 authored either through a visual canvas editor or by directly editing YAML, with both representations kept in sync. The editor exposes registered services as typed, drag-and-drop nodes whose connectable handles and static parameter panels are derived automatically from the service’s OpenAPI schema: fields annotated with x-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 dispatch 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 references. Callers poll the execution state endpoint and retrieve output artifacts via presigned object-store URLs once execution succeeds.

Comment, revise, pause, kill

Human Operator

Human, AI

Nexus Orchestrator

Set Goals, Policy, and Constraints

Human-​Only

AI Development Units

Decompose work into tasks, plan AI-​Lead

Prioritize and assign tasks AI-​Lead

Rollback and replan Human-​Lead

Implement and test automatable tasks ADU-​Only

Validate acceptance criteria Human, AI

Final approval to merge

Human-​Only

Write provenance and audit trail System

Implement and test manual tasks

Human-​Only

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

T HE BONSAI W ORKSPACE

The layered core provides structural foundation and interface contracts, but infrastructure alone is insufficient for successful human-ai collaboration: the process must keep the human in the loop and prevent the AI from acting as an opaque black box. We therefore introduce the BONSAI Workspace, a mixed-initiative environment that operationalizes 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 orchestrator (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 development context before code is generated. Idea Brainstorming and Issue Board — The human developer initiates a project by defining high-level goals and architectural constraints, thereby establishing the foundational context that feeds all AI agents. Through a brainstorming chat, the BONSAI users explore ideas and tasks collaboratively with an AI assistant; each idea is structurally evaluated for feasibility and complexity, receiving a go, refine, or pass recommendation before promotion to the Issue Board. Promoted ideas are decomposed into a parent issue with numbered child issues, each assigned an agent type and linked by explicit dependencies forming a directed 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, omnipotent 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 tailoring the AI’s profile to a specific task (e.g., frontend UI vs. backend data processing), the system strategically decreases the risk of contextwindow 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), rolebased 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. 6: The provenance visualization shows the development process at different levels of semantic zoom.

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 parameter k specified at runtime via user input or, if not provided, a plausible value determined by Nexus. Application View — Developers write custom code to create the EndUser-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 Bonsai 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 demonstrates 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 corresponding to parent issues on the Issue Board. Agent type is encoded through distinct color and shape, while agent status (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 details 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.

History & Provenance Component — The provenance component shown in Figure 6 captures a fully traceable state history, documenting every architectural decision and treating agency handoffs as firstclass provenance events to ensure complete auditability across the codevelopment 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 interactions 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 badgeheader 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 automatically re-queue failing ADUs with diagnostic context, without human intervention. This also means that branches leading to conflicts

6 I NTEGRATION OF AGENTIC AI Collaborative VA application development produces high-volume, ambiguous team dialogue. To translate this naturalistic input into actionable, traceable work while preserving human agency, BONSAI integrates 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 dialogue 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 Development 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 visualization 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 layered 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.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 series of preconditions: a configurable confidence and predefined timeout thresholds determine whether intents are auto-approved or (temporarily) held for human confirmation; concurrency caps limit simultaneous agent execution; dependency resolution defers tasks whose prerequisites remain incomplete; and file-lock checks prevent agents from writing 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 V CP

VACP

Application 1

Event Endpoint

Webhook

MW Portal

...

Direct IAM

protected namespace

Workflow Orchestrator

Service A

Streaming

Service B

Application Building Skill

Agentic AI

Service Registry

Portal MCP

Bearer-​TokenBased IAM

Sync

RESTFul

6.2 Development Workflow When a human developer introduces a new directive, BONSAI does 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 existing BONSAI Core services already satisfy the

Application 2

Server-​Sent Events (SSE)

Queue-​Based

Star Pattern

...

Service C

...

AUTH GW

that cannot be resolved by the ADUs must either be reimplemented or resolved by human experts. At the human level, the Review phase embeds a lightweight issue-reporting mechanism directly into the live application 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, rejection, 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.

V

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.

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, BONSAI offers 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 operations (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 workflow 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 of BONSAI, 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 application under development, granting agents structured access to internal application state and data; this targeted integration enables domainspecific 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, filelock boundaries, and a dedicated Git feature branch. They submit code artifacts, without access to orchestration or to each other’s working context, preserving the bounded execution model that operationalizes R2 .

Service Implementation Skill

Bearer-​TokenBased IAM

External Application

Fig. 8: Agentic integration points within the BONSAI architecture. 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 integration branch; child ADUs merge back into it upon successful completion. 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 governed. If merge conflicts cannot be resolved, the results of corresponding branches are summarized and retriggered for implementation. Architectural Drift Prevention — Two mechanisms jointly address R2 by counteracting context degradation. First, the Nexus’s service mining actively surfaces reuse opportunities before any new code is written, keeping human developers informed of what the AI reuses versus what it generates from scratch. Second, skill files do not merely provide coding guidance; they encode the structural conventions each service must satisfy (e.g., OpenAPI contract requirements, admission criteria, layer-specific interface patterns). Together, service mining and skillencoded guardrails ensure that AI-generated components conform to the platform’s architectural standards rather than silently introducing drift. 7

S YSTEM VALIDATION & U SE C ASES

Evaluating a comprehensive architectural framework for human-AI codevelopment presents a methodological challenge that time-boxed controlled studies cannot adequately address: the longitudinal friction of dependency management, iterative design, and multi-agent coordination in real VA projects unfolds over weeks or months, not a single session. We therefore adopt a systems-validation methodology common in HCI and visualization infrastructure research and evaluate the BONSAI 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-servicecatalog 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.1 UC1: Component Extraction: Semantic Color Mapping The Semantic Color Mapping (SCM) pipeline [17] is a recurring building 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 whether BONSAI can 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, BONSAI identified that four of the required processing stages were available as microservices, ready for direct use. Consequently, the agent determined that mostly orchestration-level plumbing was required to connect the existing services into a valid DAG. During the first composition attempt, the CType system flagged a schema mismatch between the embedding service’s output format and the projection 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 in Phase C .

Semantic Color Mapping Flow x1

Text (Input)

x1

Selected Colormap (Parameter)

x0

x2

x2

Vector Representations

Unit of Analysis

Projection Method

Color Map

WordNet

Topics

UMAP

Bremm et al.

Word2Vec

Keywords

T-​SNE

Schuhmann, Urban

BERT

Sentiments

PCA

Steiger et al.

Service

Service

Flow Inputs

Flow Outputs

Service

...

Embedding LLM

Final Application

Service

Fig. 9: The SCM pipeline [17] comprises multiple steps with clear interfaces before visual encoding is possible. The separate nodes in this pipeline represent separate building blocks covered by independent services provided by the BONSAI Core.

In the second iteration, the workflow passed all structural validation checks for the BONSAI Core and executed end-to-end, producing semantically meaningful color mappings consistent with the original description. 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 relevant 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 BONSAI lacked 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 service 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 disclosing precise, field-level incompatibilities at design time, enabling the ADU to correct mismatches before runtime execution. Third, reusability dramatically reduces implementation effort. Because the middleware already contained all required processing stages, validated, and production-grade, the entire extraction task was reduced to the orchestration layer. Compared to a from-scratch reimplementation, this approach required only two ADU iterations. It demonstrated that a wellpopulated 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 that BONSAI, with human steering, can replicate a complex paper from a single source, yielding a highfidelity, interactive prototype for pedagogical or demo use. Rather than relying on unconstrained “vibe-coding,” which typically yields a brittle, opaque monolith, we used BONSAI to 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: During Phase 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 LLMbased 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. In Phase B , the squad leads then instructed ADUs to implement the required backend services

Fig. 10: Given a publication (as PDF), users can employ the brainstorming chat to extract relevant parts of existing techniques, identify service, workflow, and implementation requirements, reuse existing BONSAI Core services, and reimplement missing modules based on the four stages.

as well as the visualization frontend. During Phase 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 observations regarding the reconstruction of complex academic systems. First, agentic paper-to-code reconstruction is a highly viable pathway for reviving legacy research. The workspace successfully translated a static PDF description into a live, interactive VA application without requiring 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 microservices (including a dataset provider and an SVM-based weight solver). By enforcing the 4-layer architecture, BONSAI ensured that the Application ADUs and Service ADUs could generate code concurrently without tangling the complex state logic. Third, strict service registry admission introduces friction during rapid prototyping cycles. Because BONSAI requires human review before a newly generated service 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 orchestration 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 D ISCUSSION , L IMITATIONS , & F UTURE W ORK While BONSAI demonstrates how bounded orchestration resolves the sociotechnical friction of agentic VA development, its design involves deliberate trade-offs worth examining. This section reflects on key design decisions, discusses agency distribution and ecosystem dynamics, and outlines pathways for future contributions. Learning Curve of the Layered Architecture — Adopting BONSAI requires developers to internalize the four-layer mental model and interface 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 mechanisms. First, layer-specific skill files enable developers to engage in a natural dialog with agentic AI about architectural conventions, effectively turning static documentation into an interactive learning resource. Second, we are developing Onboarding ADUs that auto-generate boilerplate OpenAPI contracts and scaffold compliant project structures. Together, 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 practical bottleneck in scaling BONSAI’s ecosystem is the manual review required 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 of BONSAI relies on the premise that unconstrained “vibe coding” must be deliberately pruned using explicit interface contracts. However, this introduces a mandatory, contract-first development paradigm. In traditional, monolithic environments, developers can fluidly and chaotically experiment with UI and backend logic simultaneously. BONSAI’s strict separation of concerns requires the Nexus and human developers to define data schemas and OpenAPI specifications before the Application ADUs can effectively generate the interface. 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 completes all phases manually, treating the workspace as an architectural scaffold. At the other end, the Nexus decomposes, delegates, and validates 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, acceptance 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. BONSAI accommodates this transition by design: the same guardrails, provenance tracking, and review mechanisms apply regardless of whether a human or AI authored a component. As frontier models improve, we expect the automation boundary to shift further toward high-level design tasks, making BONSAI’s bounded orchestration model increasingly relevant. Ecosystem Dynamics & Reuse-First Development — The two case studies reveal a self-reinforcing dynamic at the core of BONSAI’s service ecosystem. UC2 required building all services from scratch, yet the resulting component became available for future projects upon admission. 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 of BONSAI’s architectural enforcement of modularity and reuse. Because every service must satisfy typed interface contracts and pass admission checks independently of any particular application, components produced by one project are natively composable in contexts their original developers never anticipated. Additionally, MCP-exposed service discovery ensures agents receive only relevant service definitions for their current task, preventing context-window saturation as the catalog grows. 9 C ONCLUSION 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 introduced BONSAI, a framework that replaces unconstrained full-stack code generation with bounded orchestration across a four-layer architecture. Through explicit interface contracts, BONSAI distills the context window for specialized ADUs, ensuring analytical logic is cleanly extracted into reusable microservices. Crucially, its structured four-phase workspace treats semantic provenance as a first-class citizen, guaranteeing a legible history of agency handoffs. Ultimately, much like cultivating its namesake, BONSAI demonstrates that sustainable multi-agent development requires deliberate structure and guided oversight, ensuring that nextgeneration 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.

R EFERENCES

[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 application integration, 2024. Donated to Agentic AI Foundation (Linux Foundation), 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 programmers interact with code-generating models. Proceedings of the ACM on Programming Languages, 7(OOPSLA1), art. no. 78, 2023. Distinguished 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, pp. 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 provenancetracking in web-based visualizations. In IEEE VIS 2020 Short Papers, pp. 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 provenance 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. Sperrle 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 visualization 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 & interoperable data views. IEEE Transactions on Visualization and Computer Graphics, 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), pp. 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, pp. 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. Frederic et al. Jupyter notebooks – a publishing format for reproducible computational workflows. In F. Loizides and B. Schmidt, eds., Positioning and Power in Academic Publishing: Players, Agents and Agendas, pp. 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), pp. 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 provenance types and purposes. IEEE Transactions on Visualization and Computer 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, pp. 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. Coadaptive visual data analysis and guidance processes. Computers & Graphics, 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 contextualized 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, pp. 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

Related documents

• Two's a Crowd: Human and AI-Based Copresence for Developers with ADHD#1006931
• License Compliance in Open Source Cybersecurity Projects#1006932
• Embedding Drift in Code Vulnerability Models Under Intended Behaviour-Preserving Transformations#1006933
• SWE-Proof: Can Language Models Resolve Real-World Issues with Machine-Checked Proofs?#1006934
• Helpful but Fallible: Developer Experiences of AI Tools Under a Coordinated Industrial Roll-out#1006935