hip-agent: a harness that fits in the prompt

hip-agent (harness in prompt) is a small agent harness designed for agents: the model reads its own harness, configuration is environment variables, and the rest is existing protocols.
Agents
LLM
Author

Jonathan Chang

Published

September 6, 2026

Note: this post was written with Claude Fable 5.1 and GPT 5.6 sol. Code: github.com/changjonathanc/hip-agent.

Motivation

There are many coding harnesses (Claude Code, Codex, and many more), but they are all designed to be used by a human.

They are not designed to be used by an agent. If you ask an agent to use codex exec as a subagent, it might spend a few turns just to figure out the right CLI flags and parse the output. And if you want a more custom loop, an agent might need even more turns to dig into the source code of Codex CLI to learn all the implementation details.

Harness In Prompt

hip-agent (harness in prompt) is a harness designed for agents. The core loop is about 200 lines of Python, plus one module for the Codex API. Three ideas:

  • The harness fits in the prompt. The loop is minimal, the model is given only two tools, sh and view_image, and the prompt tells it to read the source to learn exactly what the harness does.
  • The OS is the runtime. Configuration is environment variables, actions are shell commands, and a subagent is a child process.
  • The rest is handled by existing protocols and formats. Plugins follow Agent Plugins, hooks use Claude Code’s hook contract, and the conversation is a Codex CLI session file, so codex resume opens it.

The whole configuration looks like this:

# ~/.zshrc
P=~/hip-agent/plugins
export AGENT_MODEL=gpt-5.6-sol
export AGENT_PLUGINS=$P/environment:$P/cwd:$P/agentsmd

And a run:

codex login
./agent "inspect this repository and explain it"

Everything else comes naturally from this design:

  • A subagent is agent run from sh. It inherits the environment and gets its own conversation. The parent configures it with environment variables, AGENT_MODEL=... agent "...". By default the parent sees only the subagent’s final output, but its state can be read from its session file, and more advanced interactions can be implemented as plugins.
  • The harness is repairable. A sufficiently smart model that has read its harness can work around its limits, or change them.
  • You can put hip-agent in a skill and let your existing agent spawn subagents through it. The code itself is the documentation.

Why not native subagents?

Why a new harness when current models are already trained with subagents?

  1. Models don’t always perform best in a fixed harness, and as models get better a fixed harness can become the limitation. hip-agent is not a fixed harness. It is a reference implementation, deliberately small so that an agent can read, modify, and adapt it.
  2. You can train the model to use it. Future models can follow the hip-agent approach, building and editing their own subagent harness depending on the task.

Results

I did a few iterations of the code on Terminal-Bench 2 with gpt-5.6-luna at effort max: improved the shell design and the prompt a bit, added the view_image tool and command timeouts. Otherwise the code and prompt changes were minimal and not bench-maxxed.

The final code was then evaluated on DeepSWE, 113 tasks, against a Codex CLI 0.147.0 baseline. The results show hip-agent performs comparably with Codex CLI.

hip-agent Codex CLI
Resolved 73/113 (64.6%) 72/113 (63.7%)
Model calls per task 187 208
Agent time per task 58 min 52 min

One run each, no error bars. The two runs ran concurrently on two local machines with the same CPU but otherwise different hardware. Token usage is not compared because hip-agent does not log it.