Give the Agent a Workshop, Not a Cage

SF Scott Farrell July 10, 2026 scott@leverageai.com.au LinkedIn

LeverageAI Field Note

Give the Agent a Workshop, Not a Cage

Model capability is not system capability. Outcome quality multiplies across model, harness and substrate — so give the agent an elastic workshop, and put the membrane on irreversible substrate damage, not on the solution space.

Scott Farrell · LeverageAI

📚 Read the full field guide

Go deeper — the complete field guide expands the multiplicative formula, goal-world isolation, and the reversibility membrane with the full build order. Give the Agent a Workshop, Not a Cage →

Watch long enough and the contrast becomes rude. In one window a frontier model is eloquent and useless: it explains how one might recover an obsolete database and stops. In another window the same model class is mounting disk images, writing password harnesses, reverse-engineering binary offsets, and treating “the connector does not exist” as a sub-goal rather than a wall. People narrate that gap as “AI got better.” Often the machine under the agent changed — and nobody updated what they were measuring.

Model capability is not system capability.

A model is a hypothesis engine. A system is a model wearing a harness on a substrate. Confuse the two and you keep buying larger brains for a prisoner who still has no tools, or you keep “adding safety” by shrinking the workshop until the expedition cannot leave the courtyard.

Prisoner, workshop, expedition

There are at least three deployments of “the same AI,” and the industry keeps using one word for all of them.

  • Very smart prisoner — chat box, no durable tool surface, no right to mutate a machine. Hard problems end in advice.
  • Smart person in a workshop — coding harness, project files, shell, compile, test. The agent can do work, not only describe it.
  • Self-equipping expedition — long goal ownership, broad reality access, and the ability to install or forge tools mid-mission. Capability acquisition becomes a step inside the work.

At hour six of a serious goal the agent is not the same execution capability it was at minute one. It has grown mission-local machinery: parsers, indexes, recovered credentials, half-finished virtual machines. Interrupting it is less like distracting a junior and more like yanking a field team out of a dig site they just instrumented.

The multiplicative formula

Benchmark theatre trains the wrong instinct. A model card improves; someone ships the new weights into the same thin harness on the same barren machine; the business outcome barely twitches. Additive thinking says more model, more result. Multiplicative thinking says: find the zero.

OUTCOME CAPABILITY ≈
  MODEL
  × GOAL QUALITY
  × HARNESS PERSISTENCE
  × REALITY ACCESS
  × TOOL SURFACE
  × TOOL SYNTHESIS

Not a spreadsheet identity — a conceptual product. A frontier model with no reality access is still a prisoner. A persistent harness on a machine that cannot install anything is a determined person locked out of the storeroom. A rich tool surface without tool synthesis dies the first time the required connector is missing.

Hold the model fixed. Hold the goal fixed: recover data from an obsolete encrypted store where no supported connector remains.

Setup Live factors What happens
Chat box Model Plausible advice. Stops at the boundary.
Fixed-tool agent Model × thin tools × weak synthesis Missing importer = hard fail.
Elastic Linux + goal harness All factors non-zero Install, forge, mount, continue.

That is not a published vendor A/B. It is a shape-statement from contact with real goals — and it matches what you see when an agent treats ETL as something that can grow organs until the source becomes legible. Traditional automation assumes connectors exist. The expedition assumes connectors can be built.

Harness persistence multiplies the loop across hours: the long-running agents problem is architectural, not a missing IQ point.1 Substrate affordance multiplies the set of probes that can exist. Tool synthesis multiplies the set of probes that can be invented when the current set is wrong.

High-affordance and elastic

“Missing qemu” is either a hard stop or a five-minute install. That binary choice is the chapter.

A substrate has high agent affordance when state is inspectable, actions are scriptable, capabilities are composable, missing capabilities are installable, interfaces can be made textual at the right resolution, tools can call tools, new tools can be written, and execution can be automated. Linux is freakishly good at this — not primarily because it is “faster,” but because it is a richer vocabulary of composable machine verbs.

Fixed vs elastic
Fixed: here are your tools; use them. Elastic: here is a machine; change the machine. The tool surface at 9am is not the tool surface at noon. Passwordless sudo — inside an appropriate boundary — is the elasticity switch.

Open source always offered latent composability. Coding agents collapse the activation energy. Capability synthesised after the problem arrives beats a pre-declared tool ontology — the same philosophy as code execution over stuffing every tool definition into context up front. Anthropic’s engineering write-up on code execution with MCP shows progressive disclosure cutting an illustrated load from on the order of 150,000 tokens to about 2,000 — a reported 98.7% saving in that example — and is explicit that code execution still needs secure sandboxing and monitoring.2

We agree about the need for a boundary. We disagree that the primary boundary should shrink the solution space before reality arrives.

Isolate the goal, not the subagent

If the substrate is powerful, what is the right disposable world? The industry’s first reflex — “sandbox every agent” — hides a unit error.

Long goals accumulate a mission-local capability stack. Subagents on the same goal need to share that dig site. Per-subagent pristine VMs optimise for isolation theatre and burn expedition continuity. The right unit is the top-level goal: one disposable Linux world; sudo inside; keep results and Git; throw the world away. Next goal gets another world. Safety upgrades: host backups make damage recoverable; goal-world isolation makes most damage irrelevant.

Docker-style application containers excel when you know what the app needs. Exploratory agent goals invert that premise. You specifically do not know what the goal will need at minute zero. Predeclared constraint is almost opposed to elastic substrate. What you want feels closer to a system container: full Linux userspace, package manager, the right to install QEMU at 11:40 because reality demanded it.

The workshop inversion

Domestic proof: gift someone a Mac, put Claude Code on it, tell them Brew will do. It sort of works. It is half-arsed next to a full Linux userspace the agent can mutate like a workshop. If you only give someone one machine for agent work, make it Linux.

Give an agent a Linux substrate and it does not see nails. It sees a workshop. If the workshop is missing a tool, it fabricates the tool.

Incus-style system containers on snapshottable storage (ZFS in the worked design) match the doctrine: launch a world, fat golden image so substrate richness affects imagined solutions, snapshot before crazy, restore or discard.3 Host = precious. Goal world = adventurous. Never expose the Incus Unix socket to the guest — socket access is effectively host root, an escape hatch you designed yourself.

The industry is arriving at the same silhouette from the corporate side. Claude Code on the web runs sessions in isolated managed VMs with cleanup when the session ends.4 Firecracker-class microVMs package dense isolation with KVM and a jailer process for multi-tenant strength.5 For a single powerful workstation already on ZFS, system containers get you goal worlds without a three-month infrastructure hobby.

DATA STATE ≠ SUBSTRATE STATE

Goal worlds can be over-applied. If every interesting database lives only inside a throwaway guest, you traded one cage for another. The freakish results come from contact with real files and real Postgres.

So: do not sandbox the work. Put a membrane around host-survival mutation — kernel, bootloader, storage topology, host networking, reboot. Use the whole world of work. Recognise when you are modifying the floor you are standing on.

Do not constrain the solution space. Constrain irreversible substrate damage.

Whole-machine rollback is the seductive undo button that fails under concurrency. Snapshot the host at 09:00; Agent A imports mail all day; Agent B writes wiki; Agent C does host-survival stupidity; roll back at 15:00 — you fixed C and murdered six hours of A and B. Split three domains: precious durable data, host substrate, scratch. Data state is often the goal. Substrate state is the prophylactic.

For a trusted operator box, the sharper doctrine is: Claude lives on the real host for real work, and knows how to manufacture a disposable Linux world when substrate experimentation is dangerous. The VM is an epistemic instrument, not a permanent prison. When uncertainty concerns the problem, explore reality. When uncertainty concerns the survival of the substrate, fork reality.

Ten tripwires and an AI judge

You do not want forty thousand allow rules. You want about ten places where an unattended agent must switch cognitive mode.

Encode a Host Substrate Doctrine as a skill (procedures, checkpoint scripts, lab creators). Global instructions get a pointer, not a novel. Normal work doctrine is expansive: install, compile, create databases, use scratch. Before host-survival changes — stop and classify.

Deterministic tripwire classes: reboot/shutdown; bootloader mutation; initramfs rewrite; kernel remove/replace; zpool destroy; critical pool export/remove; wipefs; mkfs on real devices; destructive partition changes; recursive destruction of crown-jewel paths. The barrier should not say a naked no. It should say: blocked on host — invoke substrate-safety and use checkpoint/lab workflow. PreToolUse hooks can return that reason to the working model so it can adapt.6

Optional: a small AI judge on grey-area commands — does this risk bootability, storage integrity, reachability, or unrelated workloads? Prompt-style hooks exist for that judgement path.6 Seatbelt, not hostile-tenant boundary. A real VM remains the crash cage for untrusted code. Hope is not a membrane. Tripwires plus doctrine are. The guardrail becomes perturbation: deny feeds information back into the expedition.

Counterpoint and convergence

Elsewhere we argued that AI has no consequence coupling, so the goal is architecture that makes trustworthiness less relevant — not manners in a prompt.7 SiloOS is the containment story: constrain reach so unreliability is harmless.8 This essay is the counterpoint: expand workshop affordance; membrane only irreversible substrate damage. Both can be true at different altitudes. Mixing altitudes produces mush.

Code execution, per-session VMs, and microVM sandboxes mean you are not crazy for wanting Linux worlds. Choose the unit (goal/session owner, not every subagent) and the membrane on purpose.

Checklist

  1. Audit the multiplicative product — find zero factors.
  2. Choose elastic high-affordance substrate for coding agents.
  3. Isolate by top-level goal; share the world among subagents.
  4. Snapshot before chaos; keep results and Git; throw the world.
  5. Split data / substrate / scratch rollback domains.
  6. Install substrate-safety skill + ~10 tripwires + optional AI judge.
  7. Never expose hypervisor sockets to guests.
  8. Problem-uncertain → explore reality. Substrate-uncertain → fork reality.
Give the agent a workshop, not a cage.
Model capability is not system capability. Put the membrane on the floorboards, not on the hands.

References

  1. [1]Scott Farrell, LeverageAI. “Breaking the 1-Hour Barrier.” https://leverageai.com.au/breaking-the-1-hour-barrier-ai-agents-that-build-understanding-over-10-hours/ — Long-running agents as harness persistence and mission-local state.
  2. [2]Anthropic (Adam Jones & Conor Kelly). “Code execution with MCP: Building more efficient agents.” https://www.anthropic.com/engineering/code-execution-with-mcp — Progressive disclosure example (~150k→2k tokens / 98.7%); sandboxing required for code execution.
  3. [3]Linux Containers Project. “Incus.” https://linuxcontainers.org/incus/ — System containers, VMs, snapshottable storage backends.
  4. [4]Anthropic. “Claude Code on the web.” https://code.claude.com/docs/en/claude-code-on-the-web — Per-session isolated managed VMs with cleanup.
  5. [5]AWS Open Source. “Firecracker.” https://firecracker-microvm.github.io/ — KVM microVMs, ~125ms-class startup, <5 MiB overhead class targets, jailer.
  6. [6]Anthropic. “Claude Code hooks.” https://docs.anthropic.com/en/docs/claude-code/hooks — PreToolUse can block tools and return reasons; prompt/agent hook types for judgement.
  7. [7]Scott Farrell, LeverageAI. “AI Doesn’t Fear Death.” https://leverageai.com.au/ai-doesnt-fear-death-you-need-architecture-not-vibes-for-trust/ — Architecture not vibes; trust-irrelevance lineage.
  8. [8]Scott Farrell, LeverageAI. “SiloOS.” https://leverageai.com.au/siloos-the-agent-operating-system-for-ai-you-cant-trust/ — Trust-irrelevant containment; constrain reach (counterpoint sibling).
  9. [9]Scott Farrell, LeverageAI. “Why Code Execution Beats MCP.” https://leverageai.com.au/why-code-first-agents-beat-mcp-by-98-7/ — Code surface vs pre-declared tool ontology.

Discover more from Leverage AI for your business

Subscribe to get the latest posts sent to your email.

Leave a Reply

Your email address will not be published. Required fields are marked *

© 2026 Leverage AI, Scott Farrell. All rights reserved. This content is made available on a limited, revocable, read-only basis only. No licence or right is granted to copy, reproduce, republish, scrape, store, adapt, summarise, index, embed, or use this content to create derivative works, work product, deliverables, methodologies, training materials, prompts, templates, software, services, research, or commercial outputs, whether by humans or machines, without prior written permission. This restriction includes internal business use, client work, consulting, advisory, implementation, and any use in or for artificial intelligence, machine learning, data extraction, retrieval, evaluation, fine-tuning, or knowledge-base construction.