September 2026 Summaries

Daytona has introduced the `@daytona/convex` component, which integrates isolated, disposable cloud sandboxes directly into Convex backends for AI agents that need to execute code, access filesystems, or run development servers. The integration represents sandbox creation and command execution as durable, reactive Convex database records, allowing interfaces, multiple browser tabs, teammates, and dashboards to receive live status and log updates without polling or custom synchronization. Daytona supplies Docker- or snapshot-based sandboxes, code and shell execution, filesystem tools, preview URLs, and automated cleanup, while Convex provides live queries, durable records, client consistency, and scheduled supervision for long-running background jobs. The post demonstrates a minimal code-interpreter setup and describes an AI app builder that streams generated code and serves completed applications through Daytona preview URLs.

Experiments with full sandbox snapshots for coding agents found that preserving an agent’s entire machine state can reliably retain files, Git metadata, dependencies, services, databases, and other environment details, but does not generally outperform independent fresh retries on repository-focused Terminal-Bench tasks. Under equal token budgets, fresh retries solved 17 of 25 task-seed pairs compared with 6 of 25 for snapshot branching, partly because useful progress was often already captured in source files and because restored branches can inherit flawed assumptions, require context reconstruction, and divide inference across attempts. However, snapshots proved highly valuable when key progress existed outside Git: in a staged service-repair task requiring both code changes and a SQLite database update, full snapshots solved 4 of 5 continuations while clean restarts and Git-diff restoration solved none. The results suggest that full-environment checkpointing is most useful for longer, stateful agent work involving databases, running services, package installations, browsers, infrastructure, and other persistent systems, while effective methods for choosing valuable checkpoints and transferring context remain open challenges.

AI agent frameworks extend the basic model-tool loop with production capabilities such as durable state, memory, human approvals, code-execution isolation, observability, and evaluation, but differ substantially in how much infrastructure and control flow they impose. The comparison evaluates Mastra, LangGraph, CrewAI, OpenAI Agents SDK, Vercel AI SDK, Google ADK, and Claude Agent SDK across workflow primitives, persistence, sandboxing, telemetry, language support, and deployment. Mastra and LangGraph emphasize explicit, durable workflows, with LangGraph positioned as the most mature low-level orchestration option and Mastra as a TypeScript-focused integrated platform; CrewAI favors role-based multi-agent collaboration and strong memory for Python users; OpenAI Agents SDK offers a lightweight provider-agnostic loop with sandbox, voice, and realtime support; Vercel AI SDK is strongest for streaming AI interfaces; Google ADK provides the broadest language support and most complete built-in evaluation tooling; and Claude Agent SDK exposes Claude Code’s established coding-agent harness programmatically. The guide stresses that security claims require close scrutiny because permissions and in-process sandboxes do not fully isolate host-level tools, recommending containers, microVMs, or other external machine boundaries for untrusted user workloads. It concludes that teams should select frameworks based on their architectural needs, task duration, language ecosystem, tolerance for nondeterministic behavior, and operational requirements, while establishing execution boundaries and portable internal interfaces early to reduce future migration and security risks.

Cursor Cloud Agents can now execute commands in self-hosted Daytona sandboxes, allowing organizations to keep code within their own infrastructure or provide specialized tools, dependencies, and network access while Cursor retains the agent loop and model access. A controller running on a customer-managed host claims requests from Cursor Self-Hosted Pools, creates an isolated sandbox from a predefined snapshot, checks out the requested repository with a short-lived GitHub token, and launches the Cursor worker. Each request receives a separate Linux container, Linux VM, or Windows VM environment, while follow-up messages can reuse the same worker during its idle period before monitoring processes clean up the sandbox. The integration supports reusable snapshots with custom dependencies and includes safeguards such as keeping Daytona API keys on the controller host, excluding keys from snapshots, requiring no inbound sandbox ports, and avoiding long-lived GitHub credentials. Access requires a Cursor Enterprise team, a service-account API key, and the lab-channel Cursor CLI controller.