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.
When engineering teams first integrate Large Language Models into existing business applications, the natural instinct is to expose application capabilities as discrete tools. If the platform has a REST API or a set of admin panel actions, developers wrap them in a standard ReAct or function-calling loop.
This approach works for simple tasks ("update the price of SKU 1234"), but it degrades rapidly when applied to real-world operational workflows. To understand why—and how we adapted our architecture at Foundax—we have to look at the mechanics of tool granularity and the hidden costs of cross-tool orchestration.
Foundax is more than a page builder; it handles products, SKUs, inventory, multi-language content, and promotional systems. Consider a typical merchant request:
"Get ready for the weekend sale. Find items with more than 20 sellable units in stock, exclude anything already participating in a promotion, write missing English descriptions for the remaining items, and generate a 15% discount proposal. Let me review it before going live."
If we attempt to solve this via traditional tool calling, we face a granularity dilemma:
The fundamental issue is that complex business tasks require deterministic joins, filtering, and batch calculations. Forcing an LLM to coordinate these across dozens of tool calls consumes massive amounts of reasoning capacity, context tokens, time, and execution budget.
As highlighted in Anthropic's research on code execution via MCP and Cloudflare's Code Mode, models are exceptionally good at writing programs to manipulate data. Instead of forcing the model to issue sequential tool calls to filter arrays, we shifted our architecture: we expose business schemas and let the agent write Python or Shell scripts to handle the heavy lifting. The program executes the deterministic logic (filtering inventory, joining tables), freeing the model to focus on non-deterministic tasks like generating the missing English marketing copy.
For more background on integrating these architectures, see our earlier piece on Connecting Coding Agents to Business Software: Architectural Lessons.
Instead of replicating our internal administrative UI endpoints as functions, we expose our business rules through a structured filesystem inside an execution sandbox.
To work effectively, the model must understand the domain constraints: price and inventory belong to the SKU, while multi-language descriptions are mapped to Product × Language. Furthermore, terms must be precisely defined. In our specific implementation, "sellable stock" is explicitly defined as existing stock minus reserved stock—this is not a universal commerce formula, but the model learns it by reading our local schema definitions.
The execution environment is sandboxed. It limits network and system resources and holds no direct credentials or full application permissions to the production database. State is exposed via specific volume mounts:
This structured environment allows the model to act like a coding agent, navigating a codebase (the schema) and writing scripts (the workflow) to manipulate files (the business data). Importantly, this composition pattern does not replace tool calling or promise that a task is completed in a single inference round. The traditional Agent Loop and Tool Calling still handle the core mechanics of file access, command execution, environment inspection, code revision, and artifact submission. Instead of using tools to fetch and filter individual records, the agent uses its toolset to write and execute scripts that consolidate the deterministic data composition entirely within the sandbox process.
E-commerce is highly concurrent. While the agent is computing the weekend sale proposal, a customer might purchase five units of a targeted SKU, or an operations manager might manually update a price.
Because the sandbox cannot safely hold live, write-access database connections, we rely on a snapshot architecture. Immutable source snapshots are reused based on build and access scope, while data snapshots are strictly bound to the tenant, requested resources, and authorization limits.
Crucially, this exported data is tied to a Version Watermark. In our architecture, these watermarks act as cache freshness metadata tracking domain dependencies, not per-record optimistic-concurrency revisions. Watermarks track freshness; correctness requires exporting both the data and the corresponding watermark from a consistent snapshot or equivalent validated consistency boundary. This requirement exists because of a potential export race: if old data is exported while a concurrent write advances the watermark, tagging that old data with the new watermark would falsely mark it as fresh. The data and its watermark must always describe the exact same consistent snapshot.
During execution, a complete data version is held stable for a given command. If the agent shifts to a new command sequence that affects updated domain dependencies, the host system mounts a completely new snapshot version, refreshing the affected data while retaining the useful scripts in the /work directory. Final domain writes, however, still rely on validating current permissions, business constraints, and individual record revisions at the time of the commit.
Because the sandbox is isolated, agents cannot unilaterally alter production state. Instead, we divide execution into three distinct phases:
The write phase is heavily guarded. Rather than relying on cache dependency watermarks, a generated proposal carries expected per-record revisions (such as an expectedRevision field) for the data it intends to mutate. The underlying domain services independently validate the authorization scope, permitted fields, business constraints, and current record revisions before accepting the write. If an input assumption has changed—for example, if the available inventory for a targeted SKU dropped below the requested 20-unit threshold during the compute phase—the transaction is rejected. The agent cannot simply bump the revision number on its payload to force the write through; an invalid assumption requires pulling a fresh snapshot and recomputing the proposal.
Additionally, placing multiple operations into a single /outputs file does not magically create an atomic database transaction. Cross-domain transactions, partial successes, and retries are managed entirely by the underlying business services.
Integrating these execution loops requires careful attention to system latency, as fast agent response times are critical for user trust. By optimizing our internal environment preparation and scheduling, we reduced session startup elapsed time from roughly 2.1s down to 1.0–1.4s, and brought the first toolchain command elapsed time down from 0.87s to 0.10–0.15s. These measurements reflect the executor preparation and command overhead, rather than pure dispatch time, token savings, or the end-to-end completion time of a complex business task.
For teams looking to explore similar patterns, the general mechanics of agent execution, tools, and environments are well-documented in open-source SDKs like OpenHands. Our focus has been strictly on the integration layer: defining data contracts, managing snapshot lifecycles, and enforcing controlled writes back into live business systems.
You can explore a runnable, MIT-licensed demonstration of this reading, computing, and proposal-generation pattern in our agent-business-workspace repository. While it does not include our full proprietary caching or automatic snapshot refresh implementations, it demonstrates the core validation logic for scopes, fields, inventory constraints, and version checking.
By shifting from conversational tool-looping to sandboxed code execution, we align the AI's strongest capabilities—reading schemas and writing deterministic logic—with the rigorous demands of enterprise software architectures.
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.
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.