Towards a Harness That Can Do Anything

For the past few years, we have been thinking about how to move large language models beyond the chat window.

A chatbot waits for a prompt, generates a response, and stops. An agent needs to operate inside a changing environment. It must discover information, use tools, react to events, recover from failures, preserve context, and complete work across systems.

Giving an LLM more tools is not enough.

The system surrounding the model—the agent harness—determines whether the agent is reliable, understandable, and useful in the real world.

At Adaptive, we believe the best agent harnesses will not be the ones with the most abstractions. They will be the ones that reduce the amount of new machinery the model must understand.

The model’s existing knowledge is one of the cheapest and most powerful resources available to us. A good harness should take advantage of it.

What Makes a Good Agent Harness?

A capable harness should have four fundamental properties.

1. It should feel natural to the agent

The agent should not need to learn an entirely new operating model before it can perform useful work.

Large language models already understand filesystems, shells, source code, logs, configuration files, processes, users, and common command-line utilities. A harness should build on these existing priors instead of introducing unnecessary proprietary abstractions.

2. It should be transparent

The agent should be able to inspect the environment in which it operates.

It should be possible to answer questions such as:

• What happened?
• Which tool was executed?
• What data was read or modified?
• Why did the operation fail?
• What state did the previous run leave behind?

Transparency is necessary for human auditing, but it is equally important for agent self-recovery.

An agent cannot repair what it cannot observe.

3. It should remain lean and composable

Every instruction, tool definition, schema, and warning loaded into the model’s context consumes attention.

The goal of a harness should not be to tell the model everything it might ever need to know. It should provide a small core environment and allow the agent to load the relevant skills and context only when required.

4. It should survive failure and change

Agents will fail. APIs will change. Tools will return malformed output. Dependencies will break. Context will be lost.

A production harness must tolerate:

• Failed actions
• Partial executions
• Tool upgrades
• Schema changes
• Agent restarts
• Long-running state
• Corrupted or stale memory

Reliability does not come from assuming the model will behave perfectly. It comes from designing an environment in which mistakes are observable, contained, and recoverable.

The Real Constraint Is Cognitive Load

As models become more capable, the question is no longer only whether they can perform a task.

The more important question is:

How much cognitive load does the harness impose on the model before it can perform that task?

For an LLM, cognitive load is largely expressed through tokens.

A model that must repeatedly reason about tool schemas, navigation rules, object hierarchies, API response structures, and framework-specific conventions has fewer tokens available for solving the actual problem.

A good harness reduces that burden.

It performs routine work deterministically and leaves decisions requiring judgment to the model.

Some Preliminary Truths

Several principles have become increasingly clear as agent systems have evolved.

Use determinism wherever possible

The model may decide which objective to pursue, but the path toward that objective should use well-defined operations whenever possible.

Tasks such as these should not require open-ended reasoning:

• Locating a known configuration
• Parsing API responses
• Validating command arguments
• Tracking execution state
• Retrying transient failures
• Recording audit logs
• Enforcing access policies

The LLM should provide judgment where judgment is useful. The harness should provide determinism everywhere else.

Keep the core prompt small

A large system prompt is often a symptom of missing infrastructure.

Instead of loading every possible instruction into the initial context, the agent should discover and load skills as needed.

The core prompt should define the environment, its boundaries, and how to find additional capabilities. Workflows and domain-specific instructions should remain modular.

Treat context limits as an operational constraint

Long contexts do not simply become more expensive. They also become harder for models to reason over consistently.

Important instructions may be overlooked. Old assumptions may conflict with new information. Tool output can drown out the original objective.

The solution is not always a larger context window.

The solution is better context management.

Design Around the Model’s Strengths

Agent infrastructure should be designed around the capabilities and operational patterns that models already understand.

Rather than relying on a model to navigate unfamiliar abstractions, a harness should build on established concepts such as filesystems, shells, source code, logs, processes, and command-line workflows.

Programming, Linux administration, debugging, configuration management, and command-line workflows are heavily represented in model training data.

That makes a Unix-like environment especially powerful for agents.

Instead of forcing an agent to manipulate unfamiliar nested interfaces, give it:

• Files
• Directories
• Commands
• Logs
• Processes
• Users
• Permissions
• Documentation
• Standard input and output

The environment should feel simple to the agent while performing considerable work behind the scenes.

The harness can quietly handle:

• Input sanitization
• Policy enforcement
• Authentication
• Secret injection
• Logging
• Validation
• Rate limiting
• Retries
• Rollbacks
• State checkpoints
• Failure containment

The agent sees a predictable interface. The harness manages the complexity.

Auditability, Logging, and Self-Healing

Every sufficiently capable agent will eventually fail.

These failures generally occur at two levels.

Model-level failures

The model may misunderstand the task, choose an incorrect strategy, hallucinate a capability, or produce an invalid action.

The harness cannot directly patch the model’s intelligence. It can, however, reduce the likelihood and impact of these failures through:

• Constrained interfaces
• Approval policies
• Validation
• Sandboxing
• Dry runs
• Reversible actions
• Clear feedback
• Limited permissions

Harness-level failures

Tools, connectors, integrations, and runtime components may fail independently of the model.

Unlike model-level failures, harness failures are often repairable.

Because agent execution is turn-based, the agent can inspect the error, modify the failing component, and retry the operation—provided the environment exposes enough information.

To repair a defect, the agent needs two things:

1. A clear error message
2. Complete and accessible logs

“Something went wrong” is not an actionable error.

A useful error should explain:

• Which operation failed
• Which inputs were used
• Which component produced the failure
• What state may have changed
• Whether retrying is safe
• Where detailed logs can be found

Observability is not merely for operators. In an agentic system, observability becomes part of the agent’s reasoning interface.

A Unified Data Layer for Agents

Many of the challenges in agent infrastructure are not entirely new.

Before we talked about agents, we asked similar questions about users, processes, services, permissions, storage, and operating systems.

How should programs communicate?

How should capabilities be discovered?

How should failures be recorded?

How should resources be isolated?

How should access be controlled?

The terminology has changed, but much of the systems thinking already exists.

Our hypothesis is that a Unix-like environment provides a strong foundation for an agent harness—with some important modifications.

This is not an argument that agents should literally operate an unrestricted Linux machine. Rather, Unix offers a useful design language for building an environment that models already understand.

Revisiting the Unix Philosophy

The classic Unix philosophy is commonly summarized through three ideas:

• Build programs that do one thing well.
• Build programs that work together.
• Use text streams as a universal interface.

These principles map remarkably well to agent infrastructure.

Many current agent platforms do the opposite. They expose large, multifunction tools, inject extensive schemas into context, and prescribe rigid execution paths before the agent understands the task.

This reduces agency while increasing cognitive overhead.

For agent harnesses, we can reinterpret the Unix philosophy as follows.

Build small, transparent tools

Each tool should have a narrow purpose, predictable inputs, and clear outputs.

When a tool fails, it should fail loudly and explain why.

Separate skills, tools, and connectors

These concepts are related, but they should not be conflated.

• Skills describe how work should be performed.
• Tools execute specific operations.
• Connectors expose external systems and data.
• Policies determine which actions are allowed.

A skill may coordinate several tools. A tool may operate against several connectors. A policy may restrict both.

Keeping these layers separate makes the system easier to understand, compose, and repair.

Prefer text as the agent-facing interface

Language models naturally operate on text.

External APIs may return deeply nested JSON. SaaS platforms may expose large schemas. Databases may return binary or tabular formats. The harness should normalize these representations before placing them in model context.

This does not mean every underlying system must store plaintext.

It means the model-facing representation should be readable, searchable, and easy to manipulate.

Everything Is a File

One of the simplest ways to create a unified agent environment is to represent capabilities and external data through a virtual filesystem.

Rather than requiring the model to remember how every API works, the harness can mount normalized resources at predictable paths.

For example:

/home/agent/              Agent workspace
/etc/agent/               Configuration and policies
/bin/                     Agent-facing tools
/usr/share/skills/        Skills and workflow documentation
/var/log/agent/           Execution and audit logs
/sys/connectors/          External systems and data sources
/recovery/                Checkpoints and repair utilities

This structure provides several advantages.

The agent can navigate it using familiar commands:

ls
find
grep
rg
cat
tail
which
diff

Humans can inspect the same environment.

Tools can compose through files and streams.

State becomes explicit instead of hidden inside framework objects.

Most importantly, the agent does not need a lengthy explanation of how to navigate the system. It already knows.

Mapping Agent Concepts to Unix Concepts

A possible mapping looks like this:

Agent Harness Concept	Unix Analogy	Example Location
Agents	Users	/home/<agent>
Connectors and external data	Devices and system interfaces	/sys/connectors
Tools	Executable binaries	/bin
Logs and execution history	System logs	/var/log
Configuration and policy	System configuration	/etc/agent
Recovery and self-healing	Administrative utilities	/sbin or /recovery
Skills and workflows	Manuals and documentation	/usr/share/skills
Secrets and credentials	Protected runtime material	/run/secrets

The difficult work is not creating the directory structure.

The difficult work is transforming the messy external world into a safe, normalized, and coherent virtual environment.

That is where the harness provides value.

The Agent Kernel

Once the data layer is established, the next question is when the agent should run.

Many always-on agents combine pushed messages with periodic polling or heartbeats.

For example, an agent may wake up every 30 minutes, inspect its environment, and decide whether anything requires attention.

This creates a trade-off.

A short interval produces low latency but wastes model invocations when nothing has changed.

A long interval reduces cost but allows the agent to fall behind external events.

A more efficient architecture is event-driven.

At Adaptive, we think of the component coordinating this environment as an agent kernel.

The kernel watches relevant resources, records state changes, applies policy, coalesces related events, and invokes the appropriate agent only when necessary.

Events may include:

• A new email or message
• A modified file
• A failed deployment
• A changed database record
• A security alert
• A pull request update
• An approval decision
• A scheduled workflow
• A new log entry matching a condition

The kernel does not need the LLM to continuously ask, “Has anything changed?”

It already knows.

The Kernel Does the Heavy Lifting

An operating-system kernel mediates between software and hardware.

An agent kernel mediates between the model and the outside world.

Its responsibilities may include:

• Event routing
• Authentication
• Authorization
• Policy enforcement
• Workspace isolation
• Secret management
• Input normalization
• Output validation
• Execution logging
• State checkpointing
• Concurrency control
• Retry management
• Human approval
• Damage containment

This allows the agent-facing environment to remain small and understandable.

The model can operate through files and commands while the kernel ensures that those operations are safe, traceable, and correctly connected to real systems.

Agents as Users

The Unix user model also provides a useful abstraction for multi-agent systems.

Instead of treating every agent as a collection of prompts and tool permissions, we can treat agents as users with:

• A home directory
• An identity
• A role
• A set of permissions
• A history
• A collection of skills
• Access to selected tools and connectors

A practical environment might include several specialized users.

root

A privileged maintenance agent responsible for:

• Repairing tools
• Updating connectors
• Diagnosing runtime failures
• Installing or generating new capabilities
• Managing system-level configuration

This agent should be tightly controlled and invoked only when required.

operator

The primary human-facing agent responsible for:

• Receiving requests
• Coordinating workflows
• Interacting with external systems
• Reporting outcomes
• Requesting approvals

librarian

A reflective agent responsible for:

• Summarizing completed work
• Maintaining durable knowledge
• Identifying recurring failures
• Recording successful workflows
• Detecting outdated instructions
• Preventing memory degradation

These agents can communicate through messages, shared files, and events without requiring every agent to hold the entire system state in context.

Where Adaptive Fits

Adaptive is building the secure execution and access layer required for this kind of agentic environment.

An agent that can do anything must not automatically be allowed to do everything.

As agents gain access to infrastructure, databases, Kubernetes clusters, internal applications, and SaaS platforms, the harness must enforce the same security principles expected for human operators:

• Least-privilege access
• Just-in-time authorization
• Approval workflows
• Credential isolation
• Session recording
• Policy enforcement
• Complete audit trails
• Revocable access
• Workload isolation

Adaptive provides a controlled environment in which agents can access protected systems without receiving unrestricted, long-lived credentials.

An agent can request access to a database, server, cluster, or application. Adaptive can evaluate the request, apply policy, obtain approval where necessary, create a temporary session, and record the resulting activity.

To the agent, the capability can remain simple:

adaptive connect production-postgres

Behind that command, the harness can manage identity, authorization, networking, credentials, auditing, and session lifecycle.

This is the central design principle:

Keep the interface simple for the agent while making the execution path safe for the organization.

The Harness Should Be Powerful, but Feel Boring

The best infrastructure often feels unremarkable when it works.

Agents should not spend their context reasoning about authentication protocols, token refresh, API pagination, network tunnels, audit storage, or policy engines.

Those concerns still matter. They simply belong in the harness rather than in the model’s active reasoning loop.

A capable agent harness should feel like a clean workstation:

• Tools are where the agent expects them to be.
• Documentation is searchable.
• Errors are understandable.
• State is visible.
• Permissions are explicit.
• Actions are recoverable.
• External systems appear through consistent interfaces.

The sophistication should exist beneath the surface.

Towards a Harness That Can Do Anything

The future of agents will not be defined by a single model, framework, or tool protocol.

It will be defined by environments that let models act reliably over long periods of time.

Those environments should use the model’s prior knowledge instead of fighting it. They should expose clear, composable interfaces. They should treat logs and auditability as part of the agent’s sensory system. They should isolate capabilities through identity and policy. They should invoke models in response to meaningful events rather than wasting turns on constant polling.

Most importantly, they should minimize the amount of machinery the agent must keep in its head.

The model’s intelligence is valuable.

The harness should spend as little of it as possible on understanding the harness.