papers/hanzo-harness-hacking/sections/01-introduction.tex

\section{Introduction}

\label{sec:intro}

Modern autonomous AI agents~\cite{openai2023gpt4, anthropic2024claude,
yang2024sweagent} operate within a two-layer architecture: a foundation model
providing general reasoning and a \emph{harness}---the collection of tools,
extensions, APIs, and orchestration code that translate model outputs into world
actions. This harness is, in practice, always designed by humans and treated as
fixed infrastructure from the agent's perspective. The agent can use the tools
it is given; it cannot create new ones. The agent can invoke its extension API;
it cannot extend the API.

This assumption is not fundamental. It is a design choice---one made, we argue,
out of an abundance of caution rather than technical necessity. The same
capabilities that make an agent useful for software engineering tasks (reading
code, writing code, running tests, submitting pull requests) are precisely the
capabilities required to improve its own harness. The question is not whether
agents \emph{can} hack their harness, but whether they can do so \emph{safely}.

\paragraph{The Meta-Learning Opportunity.}
The most impactful improvements in any system are often improvements to the
improvement process itself. An agent that learns a better heuristic for a single
task improves on that task. An agent that adds a new tool for a class of tasks
improves on every future instance of that class. An agent that identifies a
missing abstraction in its extension API and implements it improves every
subsequent session for every agent sharing that infrastructure.

This hierarchy of improvement leverage is well-understood in meta-learning and
curriculum learning~\cite{schmidhuber1987evolutionary,
thrun1998learning}, but has not been applied to agent harness evolution. We
refer to the capacity for an agent to modify its own tools and infrastructure as
\emph{harness-hacking}: a deliberate, safety-bounded capability for
self-improvement at the infrastructure layer.

\paragraph{The Specific-Tools Principle.}
Empirical data from the Hanzo Dev agent benchmark confirms a foundational
motivation: on tasks where agents have access to a purpose-built, task-specific
tool, they succeed $93.1\%$ of the time. On the same tasks where only
general-purpose fallback tools are available, success drops to $83.8\%$---a
$9.3$ percentage point gap. This validates the \emph{specific-tools-beat-generic-flexibility}
principle: a well-designed, narrow tool outperforms a general tool applied to a
specific problem. Since it is impossible to anticipate every task a deployed
agent will encounter, an agent that can create its own task-specific tools
closes this gap at deployment time rather than pre-deployment design time.

\paragraph{Why Current Systems Treat the Harness as Immutable.}
Three concerns dominate: (1) \emph{safety}---a buggy or malicious self-modification
could destabilize the system; (2) \emph{auditability}---modifications without
human review undermine trust; (3) \emph{scope creep}---unconstrained modification
could consume unbounded resources. We address each directly. Safety is achieved
via worktree isolation with formal invariants. Auditability is achieved via
git-based review at each trust tier. Scope creep is bounded by a
per-session modification limit and a time-box on each hack cycle.

\paragraph{Contributions.}
This paper makes the following contributions:

\begin{enumerate}[leftmargin=1.5em]
    \item \textbf{Harness-Hacker Protocol (HHP):} A complete protocol for
          safe agent self-modification organized into four trust tiers, each with
          formal preconditions and postconditions.
    \item \textbf{Isolation Invariant:} A formal definition of the worktree
          isolation boundary and a proof that validate-then-merge preserves
          system integrity.
    \item \textbf{Runtime Tool Creation Pipeline:} A concrete implementation
          of hot-loadable, TTL-governed tools generated by agents to address
          observed friction points.
    \item \textbf{Virtuous Cycle Analysis:} A formal model of the feedback
          loop connecting telemetry, GRPO-based experience extraction,
          self-modification proposals, and improved agent capability.
    \item \textbf{Risk Analysis:} A systematic treatment of failure modes with
          formal bounds on the damage each can cause under HHP constraints.
\end{enumerate}

\paragraph{Paper Outline.}
Section~\ref{sec:related} reviews related work.
Section~\ref{sec:taxonomy} presents the self-modification taxonomy.
Section~\ref{sec:safety} formalizes the safety framework.
Section~\ref{sec:protocol} specifies the Harness-Hacker Protocol.
Section~\ref{sec:cycle} analyzes the virtuous improvement cycle.
Section~\ref{sec:architecture} describes the multi-component architecture.
Section~\ref{sec:risks} presents the risk analysis.
Section~\ref{sec:discussion} discusses implications and future work.

% ============================================================================
% 2. RELATED WORK
% ============================================================================