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
- Distinctive: line 22
Write the task contract and acceptance criteria before building an autonomous loop.
- Distinctive: line 29
Verify final artifacts independently of the model's claim that it succeeded.
- Distinctive: line 30
Test timeout, malformed tool arguments, empty results, tool denial, repeated calls, prompt injection, cancellation, and resume behavior.
≈ “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.
Files
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
- Write the task contract and acceptance criteria before building an autonomous loop.
- Separate deterministic business rules from model decisions.
- Expose the smallest set of tools needed, each with narrow permissions and typed schemas.
- Define maximum steps, wall-clock time, token/cost budget, retries, and tool-call limits.
- Normalize tool results and label them as untrusted observations.
- Require approval for consequential actions such as external messages, destructive writes, purchases, deployments, or permission changes.
- Make side effects idempotent or persist an action ledger so resumed runs do not repeat them accidentally.
- Verify final artifacts independently of the model's claim that it succeeded.
- 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
- LangGraph runtime concepts: https://docs.langchain.com/oss/langgraph/overview
- OpenAI Agents SDK: https://openai.github.io/openai-agents-python/
- Microsoft AI Agents for Beginners: https://github.com/microsoft/ai-agents-for-beginners
In this repository28 other files it gives its agents.
- agent-architecture-designSkill
- agent-evaluationSkill
- agentic-workflow-testingSkill
- agent-memory-designSkill
- browser-computer-useSkill
- durable-agent-workflowsSkill
- human-in-the-loopSkill
- mcp-developmentSkill
- mcp-server-developmentSkill
- multi-agent-orchestrationSkill
- tool-calling-designSkill
- advanced-retrieval-rerankingSkill
- context-engineeringSkill
- embedding-model-engineeringSkill
- llm-evaluationSkill
- llm-observabilitySkill
- model-serving-inferenceSkill
- multimodal-ai-pipelinesSkill
- prompt-engineeringSkill
- rag-engineeringSkill
- rag-pipeline-engineeringSkill
- structured-outputsSkill
- agentic-securitySkill
- security-reviewSkill
- code-reviewSkill
- debuggingSkill
- test-engineeringSkill
- example-skillSkill
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
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.

