How to Get Out of Your Agent’s Way

By

Chris Tate

This is a set of patterns that have held up for me when trying to make agents run unattended.

Autonomous agents fail for predictable reasons. Most failures are not model failures. They are system design failures.

If an agent requires approval at every step or depends on a developer’s laptop being open, it is not autonomous.

Autonomy is an infrastructure decision.

Sandbox Everything

Unsupervised execution requires isolation.

Every agent run should execute inside its own environment:

  • Ephemeral
  • Isolated
  • Disposable

Each run gets:

  • A clean environment
  • A writable filesystem
  • Command execution
  • Explicitly scoped network access

When the run completes and the output is verified, the environment is destroyed.

No Access to External Databases

A sandboxed agent should not talk to shared or long-lived databases.

Instead:

  • Install system packages on demand
  • Spin up databases locally inside the sandbox
  • Run migrations as part of the task
  • Seed data explicitly
  • Tear everything down at the end

If the agent needs a database, it should create one.

This has several benefits:

  • No risk of corrupting production or staging data
  • Fully reproducible runs
  • Production-like behavior without shared state
  • No hidden dependencies on environment drift

You do not need an external DB to do serious work. You need a realistic environment, not a persistent one.

Environment Garbage Is Real

Most people understand context garbage.

If you keep appending to a prompt, performance degrades. Irrelevant history pollutes reasoning. Models become less reliable as context grows.

The same thing happens at the system level.

Long-lived environments accumulate:

  • Stray files
  • Half-installed packages
  • Cached state
  • Orphaned processes
  • Implicit assumptions from previous runs

This is environment garbage.

It affects performance and reliability in ways that are hard to detect:

  • Agents behave differently run to run
  • Failures become non-deterministic
  • Debugging becomes guesswork
  • Benchmarks lose meaning

Shared or persistent environments hide these problems by smoothing over missing steps.

Fresh environments expose them immediately.

Starting from a clean sandbox for every run forces the agent to:

  • Declare all dependencies
  • Handle setup explicitly
  • Operate without hidden state
  • Produce reproducible results

Clean environments surface correctness. Persistent environments obscure it.

Systems that are not reproducible cannot be trusted to run unattended.

Run Agents Independently of User Sessions

Autonomous agents should not depend on an active user session.

The agent loop must be decoupled from:

  • Browser tabs
  • Terminal sessions
  • Developer machines

Correct architecture:

  • The agent runs remotely
  • Clients only observe, cancel or fetch results
  • Disconnecting the client does not interrupt execution

You should be able to:

  • Start a task
  • Close your laptop
  • Return later to completed artifacts

Control is enforced through system constraints:

  • Wall-clock limits
  • Resource limits
  • Explicit lifetimes
  • Automatic cleanup

Define Outcomes, Not Procedures

Over-instruction degrades agent behavior.

Avoid:

  • Step-by-step plans
  • Tool-level micromanagement
  • Predefined execution graphs

Instead:

  • Define the desired outcome
  • Define acceptance criteria
  • Define constraints

Then stop.

Planning and execution belong to the agent.

Human intervention during execution usually degrades results and masks real system flaws.

Give Agents Direct, Low-Level Interfaces

Autonomy requires direct access to execution primitives.

Effective agents need direct access to:

  • Command execution
  • Persistent files
  • Network requests
  • Browsing

The simpler the interface, the better.

Operating systems already provide:

  • Process isolation
  • Composition
  • Error signaling
  • Durable storage

Leaning on these primitives removes abstraction and increases reliability.

If the model understands the interface, the system will scale.

Avoid MCPs and Overbuilt Agent Frameworks

What has consistently worked best is not more abstraction. It is less.

Protocols and coordination layers exist to help humans reason about systems and integrate with other systems. Agents do not need them.

Agents adapt well to small, explicit interfaces. They struggle with indirection.

Most real-world agent workflows reduce to:

  • Running commands
  • Reading and writing files
  • Making network calls

You do not need a framework to orchestrate this. The operating system already does.

CLI-first systems are:

  • Easier to reason about
  • Easier to debug
  • Cheaper to run
  • More capable than they look

When an abstraction layer is more complex than the task, it becomes the bottleneck.

Persist State Explicitly

Stateless systems are inefficient.

Without persistent state, agents:

  • Recompute work
  • Lose context
  • Inflate prompts
  • Increase cost

Each run should have a writable workspace directory.

Use it for:

  • Intermediate results
  • Logs
  • Partial outputs
  • Planning artifacts

Files are inspectable and deterministic. They also make post-run analysis possible.

Introduce Benchmarks Early

Benchmarks are usually treated as a finishing step. That is backwards.

Benchmarks should exist as early as possible.

They are how you answer:

  • Is this agent output actually good?
  • Is it better than alternatives?
  • Is it the best version of this thing?

Without benchmarks:

  • You optimize based on intuition
  • You mistake novelty for progress
  • You ship something that feels impressive but performs poorly

Benchmarks do not need to be perfect. They need to be representative and repeatable.

Even crude benchmarks are better than none.

If quality is not measured early, it becomes harder to evaluate and improve later.

Plan for Cost

Autonomous execution has a different cost profile than interactive use.

Unattended agents operate continuously. They explore, retry, reflect and iterate without human throttling.

This drives consumption across:

  • Tokens
  • Compute time
  • External API calls

These costs do not appear as spikes. They accumulate over time.

Autonomy only works when this usage is treated as an operational input, not an anomaly.

That means:

  • Token usage is provisioned, not rationed ad hoc
  • Compute is allocated explicitly
  • Limits are enforced by the system, not by humans

Autonomy shifts where costs appear, it does not remove them.

Organizations that want autonomous agents must plan for sustained token and compute spend as part of the system design.

The Correct Mental Model

Autonomous agents are not interactive interfaces. They are execution systems.

They run for extended periods, operate without supervision and are bounded by infrastructure, not prompts.

In practice, this means:

  • Permissions are constrained by the environment
  • Objectives are defined upfront
  • Tools are real and composable
  • Limits are enforced by the system
  • Output is verifiable

When systems are designed this way, human-in-the-loop is no longer a requirement. It becomes an exception.

By:

Posted in:


Design a site like this with WordPress.com
Get started