agentleFS
asmamestasmamest/Nexus-Skills/skills/agentic-engineering/agent-harness-engineering/SKILL.md

agent-harness-engineering

Skill1 starsChanged 17 days agoMITView on GitHub

Design the harness around an AI agent: tool interfaces, execution loop, context management, policy checks, budgets, state, verification, and recovery.

We split this skill into the rules it gives an agent

3 rules. About 0 are common, 3 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Write the task contract and acceptance criteria before building an autonomous loop.

    line 22
  2. Distinctive:

    Verify final artifacts independently of the model's claim that it succeeded.

    line 29
  3. Distinctive:

    Test timeout, malformed tool arguments, empty results, tool denial, repeated calls, prompt injection, cancellation, and resume behavior.

    line 30

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Agent Harness Engineering

Goal

Build the reliable control layer around a model-driven agent. The harness governs how the model receives context, requests actions, observes results, retries, verifies completion, and stops.

Core components

  • Input contract: task, constraints, user permissions, and expected deliverable.
  • Context manager: selects evidence, trims history, tracks artifacts, and preserves provenance.
  • Policy layer: validates tool access, arguments, sensitive actions, and human-approval requirements.
  • Tool adapter: typed inputs/outputs, timeouts, cancellation, error normalization, and idempotency.
  • Execution loop: model call → validated action request → policy check → tool execution → observation → progress assessment.
  • State store: explicit task status, checkpoints, artifacts, budgets, and resumable progress.
  • Verifier: checks results against acceptance criteria and evidence.
  • Telemetry: traces, cost, latency, tool errors, safety events, and final outcome.

Design workflow

  1. Write the task contract and acceptance criteria before building an autonomous loop.
  2. Separate deterministic business rules from model decisions.
  3. Expose the smallest set of tools needed, each with narrow permissions and typed schemas.
  4. Define maximum steps, wall-clock time, token/cost budget, retries, and tool-call limits.
  5. Normalize tool results and label them as untrusted observations.
  6. Require approval for consequential actions such as external messages, destructive writes, purchases, deployments, or permission changes.
  7. Make side effects idempotent or persist an action ledger so resumed runs do not repeat them accidentally.
  8. Verify final artifacts independently of the model's claim that it succeeded.
  9. Test timeout, malformed tool arguments, empty results, tool denial, repeated calls, prompt injection, cancellation, and resume behavior.

Loop design

A safe loop must have explicit continuation and stop conditions. Stop when the goal is verified, the task is impossible with available permissions/evidence, the budget is exhausted, or a human decision is required. Do not continue merely because the model keeps requesting another step.

Harness vs prompt

Prompts guide model behavior; the harness enforces operational boundaries. Authorization, filesystem boundaries, budgets, approval gates, schema validation, and idempotency must live in code or infrastructure, not only in natural-language instructions.

Evaluation

Measure goal success, unnecessary steps, tool-call precision, recovery from tool errors, budget adherence, policy violations, and verification accuracy. Compare against a simpler deterministic workflow before increasing autonomy.

Deliverable

Provide an architecture diagram, state model, tool contracts, policy matrix, stop conditions, verification plan, observability fields, and failure-injection tests.

References

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.