Exploring how coding agents operate within business software. While agents reason about workflows and use code to compose tasks, the host platform manages data permissions, durable project state, gated writes, and continuous human editing.
When integrating large language models into enterprise environments, early architectural designs often rely entirely on direct tool calling. You expose a set of APIs, the model selects the right tool, and the application executes it. This pattern can successfully complete complex tasks, but it encounters friction when handling the interconnected workflows of real business software.
Consider a standard e-commerce request: "Filter out products with low inventory, draft missing English descriptions for the remaining items, and prepare a promotional landing page for my review."
This single prompt requires querying transactional systems, processing intermediate datasets, generating user interface code, and pausing for human validation. The combinations of dynamic requirements cannot be pre-enumerated. While a model can orchestrate this via sequential tool calls, the cumulative coordination, context management, latency, and inference-budget costs of unpredictable cross-domain combinations quickly become prohibitive.
To manage this complexity, a more resilient architecture incorporates code execution. By provisioning an isolated sandbox equipped with a shell and filesystem, we allow the agent to read authorized schemas and structured business data views.
Code execution consolidates deterministic joins, filtering, and calculations. Instead of relying on the model to infer every intermediate step across dozens of API responses in its context window, the agent writes and executes scripts to process intermediate data and generate a comprehensive modification proposal. Tool calling is not abandoned—the model still reasons and uses tools directly in its agent loop, and not all tool calls are orchestrated by generated scripts—but heavy deterministic data manipulation is shifted to code.
To safely scale this environment, the platform reuses read-only source snapshots and authorized business-data snapshots, rather than attempting to freeze and cache the underlying sandbox or virtual machine environment state.
For a deeper dive into the execution lifecycle and context management, see Why We Model Business Agents Like Coding Agents.
When a coding agent generates a script that runs successfully in a sandbox, it has merely produced a valid proposal. Sandbox execution success is not equivalent to user confirmation, and user confirmation is not equivalent to a successful business write.
Integrating agents safely requires strictly decoupling these phases:
The host platform is entirely responsible for authorization, data preparation, and final commitment. Before any data is persisted, the system must verify current user permissions, check version constraints, and ensure no conflicting mutations have occurred since the proposal was generated. If the agent proposes a discount for an item that just went out of stock, the business service rejects the write.
When an agent builds a promotional page, the output blends two fundamentally different types of state, which must be versioned, validated, and rolled back independently.
Project State encompasses the source code, page references, and supported instance overrides. Business State consists of live operational data, such as catalog prices, inventory levels, and active promotions.
Consider a merchant interacting with a generated promotional page. If they change the style or format of a price tag, they are altering presentation. If they swap which product is featured in a hero block, they are modifying a product reference within the project state. However, if they change the actual selling price of the item itself, they are initiating a domain-service mutation.
An architecture must decouple these updates entirely. A project-level "undo" command that reverts the layout of the promotional page must never inadvertently roll back a subsequent, unrelated catalog repricing action executed in the business domain.
A generated user interface is rarely the end of the lifecycle. Once a coding agent outputs a page, the merchant often needs to make immediate adjustments via a visual canvas, while the agent might be tasked with further source-code refactoring in the background.
Historically, platform builders attempted to solve this by creating proprietary visual page builders, relying on custom XML nodes, database-driven directory structures, or limited Domain Specific Languages (DSLs). This creates a massive maintenance burden and locks agents into generating proprietary structures rather than standard code.
Because our internal tools already relied on standard compilation environments, SDKs, and source code, we exposed this same foundation to the external coding agents. The agents generate standard React code.
To bridge the gap between source code and the visual canvas, static compiler analysis and runtime observation derive an edit index, provenance candidates, and instance information. A click on the visual canvas does not by itself yield the unique writable Abstract Syntax Tree (AST) target. Instead, the resolver uses field provenance, the intended scope of the edit, and the current project revision to accurately plan the write. The compilation index and the visual preview are purely derived artifacts; the platform does not maintain a separate, independently editable parallel page tree.
While standard code executes reliably, deriving visual editing controls requires structural predictability; not every dynamic JavaScript expression can be cleanly reversed from the canvas. To understand how we handle compiler analysis and AST-to-UI mapping without relying on proprietary DSLs, see Making AI-Generated Frontend Code Visually Editable.
Connecting coding agents to real business software requires acknowledging that code generation is only a fraction of the solution. The true architectural challenge lies in boundary management.
By pushing dynamic orchestration into secure, code-executing sandboxes, strictly separating project code from live business state, and relying on compiler analysis rather than proprietary UI definitions, platforms can leverage the power of coding agents without compromising the integrity of their business systems. Externalizing these capabilities is primarily an exercise in product engineering—managing delivery, state reconciliation, and human review—built on top of standard, battle-tested compilation fundamentals.
For bounded actions, standard tool calling works well. But for multi-step e-commerce workflows, code execution provides a cleaner path for composition. We share our architecture evolution across sandboxing, authorized views, immutable snapshots, watermarks, and approval gates.
While AI can quickly generate functional React components, fine-tuning layout details and validating dynamic business data directly in raw code creates friction during product iteration. Pairing generated code with an interactive canvas allows teams to inspect and refine interfaces in context. In this post, we share our architectural lessons on bridging the two: using provenance tracking to trace rendered UI back to originating source expressions, instance scoping to apply visual adjustments without corrupting shared component definitions, and version reconciliation to preserve layout changes across iterative updates and concurrent edits.
An engineering look at how platform architecture, domain contracts, and context lifecycle management enable AI agents to build complete, cross-domain business workflows.