Natural-Language Agent Harnesses: Making Agent Control Logic Portable and Inspectable

Paper: 2603.25723 Authors: Linyue Pan, Lexiao Zou, Shuo Guo, Jingchen Ni, Hai-Tao Zheng Categories: cs.CL, cs.AI

The Gap

Agent systems are getting powerful, but their performance increasingly depends on “harness engineering” — the scaffolding that orchestrates tool calls, manages state, handles errors, and controls execution flow. The problem: this critical logic is scattered across controller code, runtime-specific conventions, and undocumented tribal knowledge. You can’t easily compare harnesses across systems, migrate them between runtimes, or study them as scientific objects. Each team reinvents the wheel in their own codebase.

Prior work focused on improving agent models or tool interfaces, but treated the harness as implementation detail. The gap: no portable, inspectable representation of harness logic that separates “what to do” from “how to execute it.”

Problem: Harness logic buried in code
    |
    v
Assumption: High-level control can be externalized
    |
    v
Method: Natural-language harnesses + shared runtime
    |
    v
Evidence: Controlled evals on coding/computer-use tasks
    |
    v
Conclusion: Text harnesses match code harnesses, enable transfer

The Increment

One sentence: Before this paper, agent harnesses were runtime-specific code artifacts; after, they can be portable natural-language documents executed by a shared runtime.

Core Mechanism

The system has two parts: Natural-Language Agent Harnesses (NLAHs) and Intelligent Harness Runtime (IHR). An NLAH is a text document describing control flow — when to call tools, how to handle errors, what to do with outputs. It reads like a recipe or protocol. The IHR is the execution engine that interprets these text instructions.

The IHR works through three components: explicit contracts (formal interfaces between harness and tools), durable artifacts (persistent state like files and logs), and lightweight adapters (thin translation layers for different tool APIs). When you feed an NLAH to the IHR, it parses the natural language, maps instructions to tool calls via contracts, maintains state in artifacts, and uses adapters to talk to actual tools.

NLAH (text document)
    |
    v
IHR Parser --> Instruction sequence
    |
    +---> Contract layer (tool interfaces)
    |
    +---> Artifact manager (state persistence)
    |
    +---> Adapter layer (tool-specific translation)
    |
    v
Tool execution --> Results --> Next instruction

Think of it like a restaurant kitchen. Traditional agent systems are like having each chef memorize their own version of every recipe, with instructions mixed into their muscle memory. This paper separates the recipe (NLAH) from the kitchen equipment (IHR). The recipe is written in plain language: “sauté onions until translucent, then add garlic.” The kitchen (IHR) has standardized equipment (contracts), prep stations that remember what’s been done (artifacts), and adapters so the same recipe works whether you have a gas or electric stove. A new chef can walk in, read the recipe, and the kitchen handles the execution details. You can compare recipes side-by-side, improve them, or port them to a different kitchen without rewriting everything.

Key Concepts

• Harness: The control logic that orchestrates an agent’s behavior — not the model itself, but the scaffolding around it. It decides when to call which tools, how to chain operations, what to do when things fail, and when to stop. In traditional systems, this is hardcoded in Python or JavaScript. Here, it’s externalized as editable text. Think of it as the difference between a program’s source code and its compiled binary — the harness is the “source” of agent behavior, and making it readable/editable is the key move.

• Contract: A formal interface specification between the harness and tools. Instead of the harness directly calling subprocess.run() or requests.post(), it invokes abstract operations like “execute_command” or “read_file” defined in contracts. The IHR maps these to actual implementations. This is what makes harnesses portable — the same harness text works across different tool backends as long as they satisfy the contract. It’s like USB-C: the device doesn’t care if it’s plugged into a laptop or a wall charger, as long as the contract (voltage, protocol) is met.

• Durable Artifact: Persistent state that survives across agent steps. Traditional agents often lose context between tool calls or rely on fragile in-memory state. Durable artifacts are files, logs, or structured data that the harness explicitly manages. If the agent crashes and restarts, it can resume by reading artifacts. This makes agent behavior more inspectable (you can see what happened) and debuggable (you can replay from artifacts). It’s like version control for agent execution — every meaningful state change leaves a trace.

Framework Shift

Before (mainstream approach):        After (this paper):

Agent Model                          Agent Model
    |                                    |
    v                                    v
Controller Code                      NLAH (text document)
  [Python/JS]                          [natural language]
  - tool calls                           |
  - error handling                       v
  - state management                 IHR (shared runtime)
  - flow control                       [interpreter]
    |                                  - contracts
    v                                  - artifacts
Runtime-specific                       - adapters
tool bindings                            |
    |                                    v
    v                                Tool backends
Tools                                (any runtime)

From embedded control logic to externalized declarative harnesses, the core shift is making agent orchestration a first-class, portable artifact instead of implementation detail.

Expert Assessment

Problem choice: Real gap. As agent systems scale, harness engineering is becoming a bottleneck — teams waste time reimplementing the same patterns, and there’s no systematic way to study what makes a good harness. This sits at the intersection of software engineering and AI systems, which is timely given the proliferation of agent frameworks.

Method maturity: Clever insight with pragmatic execution. The natural-language representation is not just a gimmick — it genuinely enables portability and inspection. The contract/artifact/adapter architecture is sound software engineering. However, the paper doesn’t deeply explore the limits of natural language for expressing complex control flow (what about loops, conditionals, parallelism?). The IHR’s parsing and execution logic likely has edge cases not discussed.

Experimental integrity: Baselines are fair — they compare code harnesses vs text harnesses on the same tasks. The controlled ablations (removing contracts, artifacts, adapters) are well-designed. Numbers look reasonable, though the paper would benefit from more failure case analysis. One concern: the migration experiments (code → text) don’t show whether the text harnesses are actually more maintainable long-term, just that they work initially.

Writing quality: The abstract and intro are strong, but the method section gets dense with architectural details. The paper would benefit from more concrete examples of NLAH syntax early on — readers need to see what these text harnesses actually look like before diving into the runtime. The related work section is thorough but could be tighter.

Verdict: weak accept — Solid contribution to an emerging problem, with a practical solution that enables new research directions. The idea of externalizing harness logic is valuable, and the execution is competent. Not groundbreaking, but a useful step forward that others will build on.

Takeaways

Separation of concerns pays off: If you’re building agent systems, consider separating orchestration logic from execution. Even if you don’t use natural language, having a declarative layer (config files, DSLs) makes systems easier to debug and evolve.

Contracts enable portability: Define explicit interfaces between your agent’s control logic and tools. This lets you swap tool implementations without rewriting the agent. Useful for testing (mock tools) and deployment (different backends for dev vs prod).

Durable artifacts for debuggability: Instead of relying on logs or print statements, have your agent write structured state to files at key points. When things break, you can inspect exactly what the agent was thinking. This is especially valuable for long-running agents where in-memory state is fragile.

Natural language as executable spec: For domains where non-programmers need to understand or modify agent behavior (e.g., compliance, domain experts), text-based harnesses lower the barrier. The trick is keeping the language constrained enough to be unambiguous while readable enough to be useful.