Harness your Agent

From code generation to reliable systems

The evolution of AI-assisted development is often described as a sequence of better models. That is only part of the story. The most important progress has happened around the model: better instructions, better context, access to tools, observable feedback, permission boundaries, and explicit verification. Together, those pieces form an agent harness.

A useful progression is:

Chat → Prompt Engineering → Context Engineering → Tools → Feedback Loops → Harness Engineering

Each stage solves a limitation of the previous one and adds another layer of control.

The model provides intelligence. The harness provides operating conditions.

Code is text. Software is a system.

Early AI coding workflows were conversational: a developer described a task, the model generated code, and the developer manually decided whether it worked.

That was useful, but fragile. A response could be syntactically correct while ignoring the repository architecture, using the wrong dependency, duplicating an existing component, violating a security rule, or failing at runtime.

The limitation was system awareness and execution. A completed change requires integration and evidence.

Prompt engineering clarified the contract

Prompt engineering improved results by making tasks explicit: objective, scope, constraints, expected output, prohibited actions, and completion criteria.

Prompts still cannot provide information the model does not have. Instructions about architecture or existing components only work when the agent can inspect them.

Prompt engineering asks: How should the task be described?

Context engineering asks: What must the model know to perform it correctly?

Context engineering made the model system-aware

Context engineering is the design of the information pipeline around the model.

For a coding agent, context may include repository files, project rules, architecture documentation, issues, framework documentation, schemas, logs, tests, design files, and deployment state.

The goal is not to load everything. More context can reduce quality when it hides the relevant signal. The goal is to provide the smallest trustworthy working set for the current decision.

This is where progressive disclosure helps. A harness can keep short descriptions of tools and skills available, then load full instructions, schemas, scripts, or references only when required.

The Agent Skills specification formalizes this through reusable skill folders built around a SKILL.md file. Cursor added native support for Agent Skills in version 2.4, allowing procedural knowledge to be loaded dynamically instead of placing every instruction in one permanent rule file.

Tools moved agents from advice to action

Tools allow agents to read files, modify code, run commands, inspect Git history, open a browser, query a database, call an API, or create a deployment preview.

The Model Context Protocol standardizes how AI applications connect to external systems. MCP improves interoperability, but it is not the complete harness. A harness may also use APIs, CLIs, browser automation, SDKs, or native function calls.

A tool answers: Can the agent perform this action?

The harness must also answer: Should it perform the action, with which permissions, and how will the result be verified?

Giving an agent database access is not the same as allowing production writes. Giving it a deployment tool is not the same as allowing an unsupervised release. Capability is not governance.

Reliability emerges from the loop

Tool access makes an agent more capable, but not automatically more reliable.

The decisive improvement comes when the result of an action becomes input to the next decision. The agent reads the task, inspects the system, acts, observes the result, corrects the failure, and verifies again.

Anthropic describes this as loop engineering: repeated cycles that continue until a stop condition is met. A frontend loop might inspect the implementation, make a change, open the page, interact with it, check the console, run tests, fix failures, and repeat.

A failing test, compiler error, browser exception, or invalid query becomes evidence for the next step.

Completion must also be explicit. “Make it work” is subjective. “Pass typecheck, pass the relevant tests, produce no new console errors, satisfy the acceptance criteria, and create a reviewable preview” is verifiable.

The agent should not decide that it is finished based only on confidence. The harness should define what finishing means.

What a harness actually is

A harness is the model-external system that makes agent behavior operational. It may include instructions, context retrieval, tools, Agent Skills, sandboxes, state, permission policies, hooks, tests, logs, rollback mechanisms, and human approval.

As Vivek Trivedy summarizes in The Anatomy of an Agent Harness:

Agent = Model + Harness

A harness is not a specific framework, a long system prompt, or a collection of plugins. It is the architecture that determines how the model works inside a real environment.

Models are replaceable; workflows, permissions, tests, and operational knowledge can remain. Like LSP separated editors from language-specific intelligence, a harness separates the workflow from a specific model.

Tools, skills, and harnesses

A tool gives the agent a capability. Playwright can operate a browser. BigQuery can query data. Figma can expose design context.

A skill gives the agent a procedure. It can teach the agent how to diagnose a bug, review an animation, run exploratory data analysis, or verify a task before claiming completion.

The harness governs both. It decides when the skill is relevant, which tools it may use, which actions are blocked, which checks are required, and when a human must approve the result.

The tools provide action. The skills provide procedure. The harness provides control.

Profession-specific harnesses

The same model can support different professions because the surrounding system changes.

Designer

A designer harness might connect Figma MCP, Miro MCP, Canva MCP, Webflow MCP, and Higgsfield CLI.

Useful skills include emil-design-eng, prototype, find-animation-opportunities, canvas-design, and web-design-guidelines. The harness should preserve the design system, require responsive and accessibility review, and keep publishing behind human approval.

Marketing

A marketing harness might connect Semrush MCP, Meta Ads MCP, Google Ads MCP, Google Analytics MCP, and HubSpot MCP.

Useful skills include product-marketing, ads, ad-creative, analytics, and seo-audit. The harness should default to read-only access, prevent unsupervised budget changes, and protect personal data.

Frontend engineering

A frontend harness might connect Figma MCP, GitHub MCP, Playwright MCP, Chrome DevTools MCP, and Vercel MCP.

Useful skills include tdd, diagnosing-bugs, code-review, react-best-practices, and verification-before-completion. The harness should isolate work, block secret access and production deployment, and require tests plus browser verification.

Analytics engineering

An analytics harness might connect BigQuery MCP, dbt MCP, Jupyter, Tableau MCP, and GitHub MCP.

Useful skills include exploratory-data-analysis, statistical-analysis, scientific-visualization, polars, and xlsx. The harness should use read-only warehouse access by default, enforce query limits, protect PII, and require data-quality checks.

Designing a minimum viable harness

A useful harness does not need to begin as a complex multi-agent platform. Start with one repeated workflow. Define the desired result, identify authoritative sources, expose only necessary tools, add deterministic boundaries for high-risk actions, define completion before execution, and capture enough observability to understand failures.

Improve it through: Observed failure → harness change → re-run → measure.

If the agent ignores conventions, improve context retrieval. If it edits unrelated files, add scope checks. If it claims success with broken code, require current verification evidence. If it publishes without review, add an approval gate.

Addy Osmani describes this as converting recurring mistakes into durable improvements to the system rather than treating each failure as an isolated bad response.

Current research

Agentic Harness Engineering proposes a closed loop for improving a harness through component, experience, and decision observability. The authors report an improvement on Terminal-Bench 2 from 69.7% to 77.0% while keeping the base model fixed. The result is promising, though it remains research evidence rather than a production guarantee.

Code as Agent Harness treats code not only as output, but as an operational substrate for planning, state, tools, verification, and coordination.

Both reinforce that performance is not determined by the model alone.

Conclusion

The evolution of agentic development is not only the history of better models. It is the history of better systems around those models.

Prompting, context, tools, feedback, permissions, and verification became one operating system around the model.

A better model can improve one run. A better harness improves every run that uses it.

The durable advantage is not the cleverest prompt. It is the most reliable system around the model.

References

Agent Harness Engineering — Addy Osmani
The Anatomy of an Agent Harness — LangChain
Loop engineering — Anthropic
Agentic Harness Engineering
Code as Agent Harness
Agent Skills specification
Model Context Protocol
Cursor 2.4
emilkowalski/skills
mattpocock/skills
coreyhaines31/marketingskills
anthropics/skills
vercel-labs/agent-skills
obra/superpowers
K-Dense-AI/scientific-agent-skills

Verification note: “Verified” means that the linked public repository and SKILL.md path existed when this draft was prepared. It does not mean that the skill has been independently security-audited.