Screen print poster: An indigo mechanical cradle holds a vermilion circular core.

Agent Harnesses as the AI Era's OS Layer

The model is simply the inference engine, while the external Harness (Loop, Context, Memory, Tool, and Verify) is the operating system that actually holds state and determinism.

A model alone is not enough to make an Agent; it needs an operating system layer, a Harness, to work continuously. That is a judgment I strongly agree with after reading industry discussions on Agent infrastructure, especially breakdowns like *The Anatomy of an Agent Harness*.

If you compare a large language model to a CPU, the entire harness layer wrapped around the model is the operating system. It covers loop control, tool invocation, context scheduling, memory retrieval, state management, evaluation, and safety guardrails. A bare LLM can only generate text from an input; an Agent that works continuously in an environment has to repeatedly run through a closed loop of "perceive, decide, act, and receive feedback." That closed loop does not grow naturally out of model weights. It has to rely on the runtime structure provided by an external harness.

So when I think about Agent capabilities, I don't believe simply waiting for or swapping in a stronger foundation model will solve everything. The bigger bottlenecks usually sit in the system design outside the model:

Whether tool definitions are explicit and their granularity controllable
Whether context enters the prompt according to priority and hierarchy
Whether long-term memory can be recalled at the exact right moment
Whether the file system can reliably hold the true state of the workspace
Whether the evaluation system can faithfully report end-to-end task completion rates
Whether tool execution failures and permission exceptions can be caught and corrected by the runtime
Whether security boundaries can strictly isolate user instructions from external data at the semantic layer

From Chatbot to Production-Grade Harness

In discussions around Agent architecture, *The Anatomy of an Agent Harness* unpacks, names, and standardizes the infrastructure surrounding the model.

My understanding is that a production-grade harness capable of working reliably has to coordinate at least ten core components:

Orchestration loop: The execution loop driving perception, decision-making, action, and feedback.
Tools: Translating the model's semantic decisions into real operations on external systems (reading and writing files, executing commands, making network requests, etc.).
Memory: Persisting key facts across conversation turns and tasks, and retrieving them when needed.
Context management: Deciding what content enters the active context, at what moment, and with what priority.
Prompt construction: Assembling system roles, project constraints, task materials, and historical tool results into a task state the model can understand.
Output parsing: Converting the model's natural language or formatted output into deterministic structured calls or verifiable deliverables.
State management: Tracking the current environment, unfinished tasks, modified files, and runtime side effects.
Error handling: Providing recovery mechanisms when tools throw errors, permissions are restricted, context overflows, or the task drifts off course.
Eval / Observability: Ignoring how fluently an answer reads and looking only at whether the goal was actually achieved.
Guardrails: Restricting high-risk operations and establishing permission approval mechanisms.

Among these ten components, I think state management and error handling are easier to underestimate than tool calling. Once the model deviates at a given step, the harness needs to catch the exception and return the system to a safe state; whether it can do this often determines whether the task ultimately gets finished.

The Loop Is the Execution Cadence of the Harness

Within a harness system, the orchestration loop sets the system's execution cadence. As I laid out in The Core of an Agent Loop Is Trigger, Stop, and Verification, putting a model inside a loop is still not enough to make a harness.

For a loop to run reliably, I believe three things must be explicitly defined at the contract level:

Trigger condition: When does it start?
Stop condition: What state must be met for it to actively exit?
Verification criteria: What objective evidence confirms that the task has met the standard?

When you put a loop into a workflow, its value lies in turning high-frequency manual operations into reliably reproducible routines, such as syncing documentation, checking CI status, or pulling data dashboards. Every routine should constrain its verification criteria with a checklist or dedicated rule file, constrain its trigger timing with scheduled tasks, and intercept high-risk actions with human confirmation. Without stop conditions and verification criteria, simply letting the model run in a loop only brings unnecessary invocation overhead and state chaos.

Markdown Is a Context Routing Protocol

I tend to use Markdown as a system-level interface for context management. Treating it merely as an ordinary formatting syntax for human readers overlooks its role in the system. I unpack the full logic behind this in Markdown Is the Context API for an Agent OS.

In a controlled harness, I believe different types of Markdown files should take on clear layers of context:

AGENTS.md: Regulates the Agent's behavioral boundaries and engineering principles within the current workspace;
SKILL.md: Defines standard execution steps and tool usage specifications for specific types of tasks;
Task plan documents (Plan): Track step-by-step progress and execution context for a single task;
Knowledge base indexes (Index): Provide directory pointers that the system can quickly look up;
Raw material archives (Source): Provide underlying facts and provenance without secondary processing.

Dumping all Markdown materials indiscriminately into the model context easily causes context pollution: outdated notes interfere with current rules, lengthy background materials squeeze the quota for tool outputs, and undigested drafts might even be misread by the model as execution instructions. The core responsibility of the Harness, then, is to deliver the right layer of text into the active context at the right time.

Context Compaction Is a State Checkpoint

When facing complex, long-horizon tasks, the context window will fill up sooner or later, forcing the model to undergo compaction.

Context management has to govern "what goes in," and it must also guarantee "how to recover state after dropping verbatim history." I agree with the point raised in discussions on context compaction: the compaction mechanism must turn conversation history into a trustworthy state checkpoint:

Active context: Retain only the core goals, constraints, and newly executed tool feedback for the current step;
State summary: Extract reached decisions and intermediate conclusions into semantic checkpoints to avoid accumulating semantic drift across multiple summarizations;
Prompt Cache: Keep static rules and prefix instructions stable to reduce repeated computation latency;
Persistent state: Commit specific file modifications, test logs, and Git commits to the workspace disk rather than relying on model memory.

Once context is compacted, I believe the Harness should guide the Agent to re-read the true state and verification results from disk. The model's residual, fuzzy memory cannot replace this step.

Security Defenses Must Be Built on Context Provenance

Once an Agent can call tools, read and write local files, and make network requests, the nature of security threats changes. The line of defense can no longer stop at whether the model refuses to answer sensitive words.

The thorniest risk in practice comes from Indirect Prompt Injection:

Retrieved web content has deceptive instructions embedded in it;
External calendar invites, emails, or image steganography carry specific hidden instructions;
External code or data files being analyzed contain text designed to make the Agent bypass permission checks.

Facing this kind of risk, I believe the Harness must strictly distinguish the trust levels of context as data flows in:

User instructions: Hold the highest execution priority;
Workspace configuration: Serves as an unshakeable code of conduct;
External inputs and tool return values: Must always be presented as Data to be processed, and must never be parsed as Instruction that overrides system rules.

From Individual Engineering to Organizational Accumulation

*A frontier without an ecosystem is not stable* brings the logic of the Harness to the team and enterprise level. Enterprises need to gradually turn human judgment, business experience, and rules into systematic "Harness assets": private knowledge bases, validated toolchains, automated test and evaluation suites, and complete protocols constraining Agent execution. Merely buying a model provider's API is not enough to build these core digital assets.

When gauging an individual's level of AI application, I look at whether they can build a stable engineering scaffold for themselves, turning everyday pitfalls and reflections into reusable context, executable tools, and objective eval verification criteria. Mastering complex prompt techniques alone is not enough to demonstrate these capabilities.

Key Boundaries

Based on these architectural discussions, I draw five boundaries for Harness design:

Insist on treating Markdown as a machine interface: For all indexes, specifications, and process descriptions, prioritize whether an Agent can read and execute them in a structured way.
Do not stuff everything in at once: Keep the active context clean, relying on directory indexes and layering mechanisms to fetch content on demand.
Turn high-frequency tasks into fixed workflows: Any work that needs to be repeated multiple times should be turned into a clear checklist or execution specification.
Always downgrade external inputs to pure data: Any content from third-party pages, scraped results, or external files must not be executed directly as control instructions.
Put verification mechanisms ahead of generation capability: Evaluating whether an Agent qualifies requires checking if it can verify results using real commands, tests, and disk state. Fluent text generation cannot replace these verifications.