Skip to main content

Adding Harness Support

This guide is for developers building AI clients, IDEs, agent frameworks, or other tools who want to support the Agent Harnesses standard.

What clients must implement

A compliant client must support the four-phase loading model:
  1. Load — at session start, inject the full HARNESS.md body into the agent’s context
  2. Discovery — expose tools so the agent can read routing files and content descriptions to find what is relevant to a task
  3. Activation — expose tools so the agent can read the full content of a skill, document, or routing file when it matches the task
  4. Execution — expose tools so the agent can run scripts bundled within skills
Clients may implement additional features (caching, search, UI affordances) but these four behaviors are the baseline.

Loading model in detail

Load

At session start, read HARNESS.md frontmatter to get name and description, then inject the full body into the agent’s context:
HARNESS.md is the agent’s map of the harness — it establishes the agent’s role and tells it what top-level directories are available.

Discovery

When a task arrives, the agent reads routing files to decide which directories are relevant. Expose a tool so the agent can request content on demand rather than having the client inject everything upfront.

Activation

When the agent determines a directory or file is relevant, your client reads the requested content and returns it. A single path-based tool handles the full directory hierarchy:
Using a single path-based interface keeps the API uniform across flat and deeply nested harnesses and handles arbitrary directory structures without client changes.

Traversal and termination

A harness may contain any number of top-level subdirectories. Each uses a routing file named after the top-level directory in all-caps — TOOLS.md for tools/, DATA.md for data/, and so on. This convention propagates throughout each subtree. The agent navigates progressively: reads HARNESS.md to learn about top-level directories, loads a routing file to learn what is in a branch, then loads individual files only when a task requires them. Two mechanisms signal that a directory should not be traversed further:
  • .harnessleaf — a file that explicitly marks a directory as a leaf
  • .leaf-detectors — a file at the harness root declaring keyword patterns; any directory containing the named file is treated as a leaf of the declared type
Your load_content tool should respect these boundaries: return the leaf directory’s primary file or listing rather than recursing into subdirectories.

Reference file types

Files in a harness may be any type — markdown, images, code, data files, or anything else. Your load_content tool should return the raw file content and let the agent handle interpretation. When indexing files for presentation or search, only markdown files (.md) may carry a description frontmatter field. Non-markdown files have no structured metadata.

Script execution

When an agent invokes a script bundled inside a skill, your client is responsible for executing it. The expected interface:
  • Scripts receive input via command-line arguments or stdin
  • Scripts write results to stdout
  • Non-zero exit code indicates failure; stderr contains the error message
Clients should sandbox script execution appropriately for their environment and expose a run_script(path: str, script: str, args: list[str]) -> str tool to the agent.

Validation

Use the harnesses-ref CLI to validate a harness before loading it:
The validator checks structural correctness including HARNESS.md frontmatter, detected skill leaf validity, and the presence of routing files in grouping subdirectories. Clients may run this check at install time and surface errors to the user.

Minimal example

A minimal Python implementation of harness loading: