New this week: the plumbing that keeps AI agents in their lane

Once an agent can write code, open web pages and query your database, the model matters less than two plainer questions: what is it allowed to touch, and can you see what it did? Eight tools we reviewed on 31 October and 1 November answer them from different sides: a sandbox, a browser built for machines, a branch per agent, a skill scanner, a careful database connection, and three ways to record, grade and type what the model sends back. None is glamorous. Each removes a specific way an agent run goes wrong.

Somewhere safe to run

An agent that writes code is only useful if it can run that code. E2B (4.4) rents you a throwaway Linux computer for each session. Each is a Firecracker microVM, a small virtual machine with its own kernel, and it can be paused with memory and disk intact. The default machine of 2 vCPUs and 4 GiB costs about $0.17 an hour, billed by the second, and the free Hobby plan comes with a one-time $100 credit.

The catch: the defaults favour convenience. Every sandbox has outbound internet access, and its public URLs answer anyone who has the link until you restrict them. There are no GPUs.

Most agents that browse never need to see a page, only to run its JavaScript and read the result. Lightpanda (4.2) is a headless browser written from scratch in Zig that leaves out the part that paints pixels and speaks the same DevTools Protocol as Chrome, so an existing Puppeteer or Playwright script mostly needs a new address. On the project's own benchmark, peak memory over 100 pages was 123 MB against 2 GB for headless Chrome. Those are self-reported page loads, not long click-through sessions, but even part of that gap means many more agents per machine.

The catch: it is a young engine. A site that leans on a web feature Lightpanda has not built yet will fail where Chrome would not, so keep a Chrome pool for the misfits. Telemetry is on until you set LIGHTPANDA_DISABLE_TELEMETRY=true.

Limits on what it can touch

Running five coding agents on one repository goes wrong the moment two of them edit the same files. Git worktrees fix that by giving each agent its own folder, but git's own commands make you type the branch name three times. Worktrunk (4.4) makes worktrees behave like branches: one wt command creates the branch and the folder and starts the agent inside it. On APFS, btrfs and XFS it shares node_modules and target/ between worktrees, so ten agents do not mean ten builds from scratch. It is free, with about 9,700 GitHub stars.

The catch: it manages folders, not agents. Merge conflicts between parallel branches are still yours, and at version 0.81 its flags and settings can still change.

Agent skills are folders of instructions and scripts you drop into Claude Code or Codex, and a bad one can hide instructions or send your keys somewhere else. NVIDIA's SkillSpector (4.1) reads one skill closely before you install it, against 71 patterns in 17 categories, without ever running it, and returns a risk score from 0 to 100 with a plain recommendation: SAFE, CAUTION or DO NOT INSTALL.

The catch: its optional AI review stage is switched on by default and sends the skill's files to build.nvidia.com unless you change the provider or pass --no-llm. NVIDIA publishes no detection or false-alarm rate, and the default exit code lets a CAUTION result through, so a strict gate needs --fail-on-findings.

A database connection is where a hijacked instruction does the most damage. Microsoft's preview Postgres MCP server (4.0) works with any PostgreSQL, not only Azure, keeps passwords in your operating system's keyring rather than in the agent's config file, and separates reading from writing: the query tool accepts one read-only statement at a time, and a profile set to read-only blocks the write tool. Its documentation is frank that it is "a gateway, not a policy engine", so whatever the database role can do, the agent can do. The package saw 27,344 npm downloads in the week to 29 October.

The catch: new profiles allow writes unless you set them to read-only, tool names changed in v0.2.0, and telemetry is on until you pass --no-telemetry.

A record of what happened, and output you can rely on

When an agent gives a bad answer, the first thing you want is the trail: which prompt, which search, which tool call. MLflow (4.4), long the default place to log machine-learning experiments, now records each model call, retrieval and tool call as a trace, with one line of setup for OpenAI, Anthropic, LangChain and others. The whole Apache-2.0 codebase is free, with nothing held back for a paid licence, it has about 28,600 GitHub stars, and it starts on a single SQLite file.

The catch: the server asks for no login unless you start it with basic authentication, and in October a critical flaw let attackers run code on servers left open that way. It is fixed in 3.17.0; still, never leave the server open on a shared network.

If your traces already live in Langfuse, its built-in MCP server (4.2) lets an agent read them. There is nothing to install, and it offers about 95 tools across prompts, traces, datasets, scores and dashboards.

The catch: rate limits. On the free Hobby plan, MCP calls share 30 requests a minute with every other API call in your organisation, so an agent paging through traces can stall on a single question. About half the tools change things, including ones that delete dataset runs or move the production label to another prompt version, so allow only the read tools if reading is all you need.

Agents break most often at the seam where the model's reply is meant to be clean JSON and is not. BAML (3.8) lets you declare a function's inputs, output type and prompt in a .baml file, generates a client for your app, and repairs trailing commas and half-finished objects instead of rejecting them. On Boundary's own benchmark of 1,000 Berkeley Function Calling Leaderboard cases, gpt-4o-mini scored 92.4% with BAML's parser against 19.8% with native function calling. The figures are self-reported and use 2024-era models.

The catch: the project is split between a legacy v0 and a new v1 language that is still before 1.0, and the v1 0.21.0 release notes alone list 13 breaking changes. A team with working v0 pipelines has little reason to move yet; a new project is betting on a language that changes every few weeks.

Where to start

Three habits run through these reviews. First, defaults are open: public sandbox URLs, write access, servers without a login, telemetry on. Spend ten minutes closing them before anything else; MLflow's worst advisory this year hit exactly the servers left without a login. Second, the cheapest safety is separation, one sandbox, worktree or read-only profile per agent, which costs almost nothing and limits what one bad run can break. Third, record before you need to. A trace switched on last week beats a careful investigation afterwards, and MLflow will hold it for the price of a small server.