Architectural Design Decisions in AI Agent Harnesses

An agent is a model plus a great deal of ordinary software: code that registers tools, decides when to spawn a helper, keeps or compresses the conversation, runs commands somewhere safe, and sequences the work. This paper calls that layer the harness and asks a plain question. When you look at many real projects side by side, which design decisions keep coming up, and which ones travel together?

The author, Hu Wei, assembled 70 publicly available agent projects, froze the list on 23 March 2026, and read each one under a written protocol covering 14 modules, from the runtime loop to sandboxing and memory. The corpus includes OpenHands, Codex CLI, Gemini CLI, Cline, Goose, Docker's docker-agent, many smaller "claw" projects, and one source snapshot of Claude Code that the paper describes as leaked. LLM agents helped navigate repositories, and a human checked every coding decision against the code; a second review of 15 projects agreed on 94% of fields at first pass.

The result is a vocabulary of five dimensions: subagent architecture, context management, tool system, safety mechanisms and orchestration. For each, the paper reports how the 70 projects split. Then it reports which options appear together, which expected links do not appear, and five recurring project patterns. The vocabulary is the durable part. The statistics need care, for reasons covered further down.

Customers rarely ask "which model?" for long. They ask whether the agent can touch their file share, what it remembers between sessions, who approves a refund, and what record exists when something goes wrong. Those are harness questions, and this paper gives you a checklist for them.

Use the five dimensions as a design review. For any agent you build or buy, write one line for each: does it spawn subagents, where does context live, how are tools registered, how is execution contained and audited, how is work sequenced. Gaps show up immediately.

Match the bundle to the job. The paper's patterns run from a single-loop personal tool to an enterprise platform with containers, policy engines and audit trails. A narrow internal tool does not need the enterprise bundle, and an agent that moves money cannot live with the lightweight one.

Do not assume capability brings controls. Projects with broad execution power did not reliably add approval and audit. Check for them explicitly; in this corpus, 40% of projects kept no audit trail at all, as reported.

Read framework comparisons skeptically. The paper itself shows how easily a comparison of frameworks produces confident numbers that cannot be checked. When a vendor or survey tells you most teams choose X, ask for the denominator and the data.