How to Run an Agent Loop That Actually Converges
A four-checkpoint how-to for agent loops: name a measurable job, bound the tool surface, refresh sandbox fixtures from real traffic, and verify at agent speed.
Loading visual explainer…
How to give every agent its own versioned workspace
A five-step workflow for turning agent output into versioned artifacts: scope a repo per agent, branch instead of copying, run in an isolated sandbox, gate changes with push-triggered evals, then deploy or roll back.
Explanation
Agents now produce more changes than a human review process was designed to absorb, so the artifact itself becomes the unit of control. This explainer walks through five checkpoints: give each agent or task its own repository, fork or branch for an attempt instead of copying data, run the work in an isolated sandbox with a clear trust boundary, subscribe to push events so evals and review run before anything ships, and keep every deploy reversible. The goal is agent output that is reviewable, attributable, and cheap to undo rather than trusted on the strength of a model's own summary.
FAQ
Why branch an agent's workspace instead of copying the repo?
Branching as a metadata operation avoids duplicating data, so an attempt can be created near-instantly regardless of how large the underlying store is. The same pattern shows up in versioned filesystems that offer forking per agent or per task, and in database restores that are treated as branches rather than snapshot copies. That cheapness is what makes rollback and parallel attempts practical.
What should gate an agent's change before it ships?
Subscribe to push events on the repository so CI and review run automatically when an agent commits, rather than after a human notices the change. Evals can be wired into pull requests with path filters so they execute only when the relevant files are touched, catching regressions before merge at a small per-run cost. The gate is the point where an artifact stops being a draft.
The posts behind it
Related reading
Databricks · · ExplainerLakebase Postgres branch-based restores for fast recovery at scale
Traditional Postgres point-in-time recovery is slow because compute and storage are coupled, requiring provisioning a new instance, restoring a snapshot from object storage to disk, and replaying WAL, leading to hours of downtime for large databases. In a survey of developers running 1TB+ production Postgres, 59% had a critical production failure and 30% were down for over three hours. Lakebase Postgres decouples compute and storage using safekeepers, a pageserver, and object storage, storing database history as an immutable timeline. A restore becomes a branch at a point in history, a metadata operation that does not copy data, making it near-instant regardless of database size. This eliminates data copies and WAL replay, so restoring a 100 TB database is as fast as restoring 10 GB, and agents can use restores as ordinary tool calls for versioning and undo.
Red Hat · · ExplainerMaster your skills: Building skills you can trust
Skills in AI agent projects silently misfire when their trigger descriptions are passive or too general, causing the agent to skip using them. The authoring tool skill-creator, from Anthropic’s skills collection, provides an eval loop that generates positive and negative test prompts and iterates on description accuracy using a training and held-out test set to avoid overfitting. These tests are ephemeral, so the open-source framework promptfoo extends them into permanent configuration files that can be committed alongside skills. Promptfoo’s agent SDK providers test through the actual agent runtime and include a skill-used assertion to confirm proper routing, and its YAML-based configuration fits naturally into version control. The final step is wiring promptfoo evals into CI, using GitHub Actions with path filters to run on pull requests that modify skills, catching regressions before they ship and costing roughly $0.10-0.15 per eval.
Cloudflare · · AnnouncementWe want you to build the next Git platform on Cloudflare
Cloudflare announced Artifacts, a programmable versioned filesystem speaking Git, is now in open beta for Workers Paid customers. Aimed at an era where AI agents write more code, Artifacts offers primitives for per-agent or per-task repositories, forking, versioned storage, and Git operations. New capabilities include deploying Artifacts repos to Workers via Workers Builds, managing repos from Workers with bindings, subscribing to push events for CI or review, setting US/EU data jurisdiction, and viewing metrics. Cloudflare is hosting a competition to build the next Git platform on Artifacts, requiring a 5-10 minute video and permissively licensed source code that reimagines agent coordination, review, and concurrent changes. Submissions close October 14, 2026; the first-place team wins $25,000 in Cloudflare credits and a trip to Cloudflare Connect, with three teams invited to San Francisco.
Modal · · AnnouncementVM Sandboxes: Full computers for agents
Modal has launched VM Sandboxes in general availability, providing agents with full Linux VMs accessible via a single flag. The VMs support Docker stacks, local databases, dev servers, and other real-machine features that agents increasingly require, as demonstrated by Ramp’s internal agent driving the entire software development lifecycle. Modal built a custom runtime on the Rust-based Cloud Hypervisor, layering innovations in host filesystems, lazy image loading, memory bursting, and snapshotting to preserve the same APIs and sub-second cold starts as their existing gVisor Sandboxes. Early customers like Linear, Legora, and Snorkel have launched over 20 million VMs, using them for coding sessions, legal agent evaluations, and agent simulations that require multiple containers and real-world environments. Modal recommends using VM Sandboxes when workloads need Docker, FUSE filesystems, or niche kernel features, while gVisor remains the default for compatible workloads.
- Modal · · Announcement
Sidecars: A low-latency trust boundary for Sandboxes
Modal introduces Sidecars, isolated containers that run alongside a main Sandbox on the same host, establishing a trust boundary between trusted and untrusted code. Sidecars enable communication across trust boundaries at least 3x faster than using separate Sandboxes, reducing latency for operation-heavy agent workloads. The feature addresses the security risk of running an agent’s harness and tool calls together, which creates the “lethal trifecta” of private data, untrusted content, and external communication. Existing solutions either move the harness to a remote service (adding network latency) or rely on egress controls that lack flexibility. Sidecars allow trusted services such as credential injection, proxy traffic, and harness logic to run locally alongside the Sandbox, with independent network policies and dynamic creation via the Modal SDK.
More like this
More how to explainers
BYOC in Five Checkpoints: Name, Split, Land, Govern, Operate
A five-checkpoint walkthrough of BYOC: name the control you need, split control and data planes, build the landing zone, govern data in place, then operate inside your own tenant.
Five Checkpoints to Bitwise-Deterministic Training Runs
A five-checkpoint workflow for making large-scale training runs bitwise reproducible: pick the guarantee, fingerprint the run, and trace divergence down to the kernel.
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
The best engineering reads, once a week
One useful email. Unsubscribe anytime.