# AI Harness as Function Composition: Orchestrating Systems Around a Frozen M(x)

Same base model, same task brief—swap the rule files, validators, and tool allowlists, and the outcome can look like two different systems. The instinctive fix is often “use a stronger model.” A stabler diagnosis: failure lives in the chain around the model.

This piece offers a decomposable abstraction: designing and running an AI Harness is multilayer composition and constraint wrapping around a frozen foundation function $M(x)$. Single-turn inference is close to classical composition; multi-turn agents add state iteration on top. The optimization target therefore shifts from “change the weights” to “change the outer $\mathcal{H}$.” It is the first-principles companion to Harness Engineering: that article builds the control system; this one says what it is as a map.

1. Foundation function $M(x)$: a frozen black-box operator

A mainstream Transformer LM can be treated mathematically as a high-dimensional, nested multilayer composite. Vaswani et al. describe encoders/decoders as stacks of $N$ identical layers, each built from attention and feed-forward sub-transforms. With weights $\theta$ fixed at inference, the forward pass is:

$$M(x) = F_n\!\big(F_{n-1}(\cdots F_1(x;\theta)\cdots)\big)$$

Here $x$ is the input representation and each $F_i$ a layer transform. $M$ is the Harness system’s core foundation operator: parameters stay put; what changes is how it is called and what wraps it.

Two properties explain why a Harness is needed—not only better prompts:

Property	Meaning	System consequence
Opacity	Inner-layer transforms are not business-editable step by step	Controllability must be external: contracts, permissions, checks
Stochastic outputs	Sampling injects noise; format, bounds, and coherence are not hard guarantees	Deterministic post-processing and feedback loops must compensate

Tighten the claim: frozen weights at inference do not make the whole pipeline a deterministic map. Temperature, top-$p$, tool returns, and context drift all change effective outputs. A Harness’s job is to produce predictable system behavior around a stochastic core.

In one line: the model supplies possibility; the Harness supplies reliability—aligned with “Agent = Model + Harness” in Agentic Coding Agent core concepts.

2. Three first principles of composition

Classical $H(x)=f(g(x))$ compresses to three criteria—also the bottom constraints of Harness architecture:

1. Layer dependence — Inner outputs feed outer inputs; order is not free, or the whole map changes.
2. I/O closure — Each stage’s shape, format, and semantics must match the next contract.
3. Composable extension — Simple operators nest into higher-order systems; a stage can be added, removed, or swapped without retraining $M$.

In engineering terms:

Criterion	Engineering meaning	Typical failure when broken
Layer dependence	Assemble → infer → parse → tool → re-validate; order is policy	“Polish before validate” beautifies broken JSON into something harder to fix
I/O closure	Schemas, MIME, auth boundaries, error shapes must be explicit	Hallucinated tool args, truncated JSON, type drift
Composable extension	Guides, Sensors, MCP tools are pluggable	Only a rewrite of one “god prompt” seems possible

These do not claim a proven optimal Harness. They give a design language you can reason with: which layer to change, why, and how the map moves.

3. Single-turn: static multilayer composition $\mathcal{H}_{single}$

A Harness does not edit $M$’s parameters. It orchestrates an outer family $\mathcal{H}=\{h_0,h_1,\ldots,h_k\}$. In the minimal stateless, one-shot case, the pipeline is ordinary multilayer composition:

$$\mathcal{H}_{single}(x) = h_k\!\big(\cdots h_2\big(h_1\big(M(h_0(x))\big)\big)\cdots\big)$$

Roles, coarsely (implementations often split further):

Symbol	Role	Typical operations
$h_0$	Preprocess	Cleaning, context assembly, prompt/skill packing, format normalization
$M$	Foundation	Semantic understanding and generation (black box)
$h_1$	Post-parse	Decode, structure, JSON/Schema validate and repair
$h_2\sim h_k$	Function & constraint	Tool dispatch, filtering, logic checks, permission gates, polish

Mini example. User: “Turn last week’s failed payment alerts into a table.” $h_0$ injects field conventions and log sources; $M$ proposes a table and query intent; $h_1$ checks column names against a Schema; $h_2$ runs the query read-only; $h_3$ strips PII and returns. Break any contract (e.g. $h_1$ accepts illegal columns) and later stages amplify the error—order sensitivity made concrete.

Single-turn Harness thus embodies order sensitivity, nesting, and I/O closure: classical composition instantiated as an engineering system.

4. Multi-turn agents: stateful dynamic composition $\mathcal{H}_{multi}$

A full agent system leaves the “stateless, finite, one-shot map” boundary: it stacks state-machine iteration, branches, retries, and memory updates on multilayer composition. Schematically:

$$\mathcal{H}_{multi}(x, S_t) = \mathcal{Loop}\!\big(\mathcal{H}_{single}(x, S_t),\; S_t \to S_{t+1}\big)$$

$S_t$ is state at step $t$: session memory, iteration count, tool traces, task progress, budgets (tokens / time / steps), and so on. Each composite pass updates state and feeds the next round.

Versus static composition:

	Static $\mathcal{H}_{single}$	Dynamic $\mathcal{H}_{multi}$
Map	Approximately fixed (given seed and input)	State-driven; same $x$ can yield different outcomes via $S_t$
Stop	One forward pass ends	Needs explicit stop / budget / human escalation
Failure modes	One-shot contract breaks	Infinite loops, context bloat, repeated no-op actions

This lines up with ReAct (interleaved reasoning traces and actions, observations written back): Thought / Act / Observation unfolds $\mathcal{Loop}$, and observations are deterministic writes into $S_t$—not something the model should invent. Production turn caps, duplicate-action breakers, and verbatim tool-result injection are convergence and anti-divergence constraints on state iteration.

Multi-turn Harness is therefore not “longer composition” but composition × state machine: still discussable layer by layer, but stop and verify must be designed on their own.

5. Concept contrast: Guides, Sensors, ReAct, and Loop

Mid-weight contrast—not a survey. The point: familiar engineering terms land in one composition frame.

5.1 Where Guides / Sensors sit in $h_i$

In Harness Engineering, Guides are feed-forward; Sensors are feedback.

Control type	Place in the composition view	Note
Guides	Mostly $h_0$ and routing-related $h_i$	Raise prior odds of first-try correctness: rules, skills, knowledge pointers
Computational Sensors	Deterministic $h_j$ (tests, lint, types, policy engines)	Judgable without re-sampling $M$
Inferential Sensors	Sub-composites that call $M$ again (e.g. independent reviewer agents)	Semantic judgment; costlier; contracts still must close

Mature systems need both: Guides alone, and the model may “know the rules without knowing compliance”; Sensors alone, and it burns tokens on the same walls. Composition language treats both as swappable outer function units, not scattered ops scripts.

5.2 ReAct as stateful unrolling

ReAct expands the action space to “environment actions ∪ linguistic reasoning,” so thoughts update context and acts produce observations. In our notation:

• One step “assemble → $M$ → parse tool calls → execute → write observation” ≈ one stateful $\mathcal{H}_{single}$
• Until finish or budget exhaustion ≈ $\mathcal{Loop}$ stop conditions

The payoff: when improving an agent, ask whether you are changing a layer $h_i$, or the update / stop rules on $S_t$—not only “add another system-prompt sentence.”

5.3 Loop Engineering: the cross-turn control plane

Loop Engineering asks a different question: which work deserves a closed loop, and what Trigger, Verifier, Budget, and Handoff contracts look like. Briefly:

• Harness / $\mathcal{H}$ — within a turn or session, how $M$ is composed and constrained safely
• Loop — how cross-turn work units are hosted, verified, and escalated

Harness is the runtime mapping layer; Loop is the control plane above it. For Inner / Middle / Outer stratification see the three loops. The composition view helps ground Loop contracts’ Verifier, State, and Budget in concrete $h_i$ and $S_t$ fields—so “loop” is not only a slogan.

5.4 Boundary with “improve $M$” research

Paradigm	Optimization target	Typical means	Cost shape
Model-centric	Parameters and alignment of $M$	Pretrain, fine-tune, RLHF, etc.	Heavy data/compute; slow iteration
Harness-centric	$\mathcal{H}$ and rules on $S$	Add/replace outer units, tighten contracts, strengthen Sensors	Fast engineering iteration; local rollback

Complementary, not exclusive. When base capability is “enough” and delivery bottlenecks are controllability and maintainability, changing $\mathcal{H}$ is often the higher-leverage path. Böckeler’s Agent = Model + Harness, with a user-built outer harness as the main trust and toil surface, points the same way as “freeze $M$, orchestrate the outside.”

6. Boundaries, anti-patterns, and discipline of claims

Formalism is a design language, not a finished optimality proof. Common anti-patterns:

Anti-pattern	Problem in composition terms	Stabler move
Over-composition	Too many overlapping $h_i$; order cost exceeds gain	Fold what can be deterministic into computational Sensors; cut decorative layers
Broken contracts	Output shape fails the next input	Explicit Schema; failures as observations into retry, not silent swallow
Non-convergent loops	$\mathcal{Loop}$ without budget, duplicate detection, or escalation	Turn caps, same-action breakers, HOTL escalation
Using $M$ for the already-decidable	Lint/type judgments left to sampling	Deterministic first; LLM for semantic trade-offs
Pretending determinism	Ignoring sampling and tool noise	Spec the randomness envelope and retry policy

Three claim disciplines to avoid empty academic tone:

1. Notation ≠ theorem — $\mathcal{H}_{multi}$ summarizes structure; semantics depend on the implementation.
2. Frozen weights ≠ frozen behavior — fixed $\theta$ does not fix system outcomes.
3. Every $h_i$ must be testable — a layer you cannot unit-test is often not a function unit but a liability.

7. Conclusions, open problems, and minimal actions

Conclusions

1. Essence — Harness work is outer-composition orchestration, unit design, chain optimization, and iteration constraints around $M$: higher-order packaging and controlled amplification of capability.
2. Forms — Single-turn ≈ strict multilayer composition; multi-turn ≈ composition fused with a state machine—layered where useful, flexible where engineering requires.
3. Optimization logic — Prefer improving reliability by adding, replacing, and tuning $h_i$ and $S$ rules—not defaulting to weight updates.

Open problems (research agenda)

• How to search or evolve optimal combinations of outer units under constraints?
• What convergence mechanisms for state iteration (when to stop; when to escalate to humans)?
• How to systematize functional constraints on uncertain outputs (Schema, types, policy, independent review) under cost–risk trade-offs?

Minimal action list

1. Sketch your current $\mathcal{H}_{single}$: label $h_0$, $M$, parse, tools, permissions.
2. For multi-turn paths, write $S_t$ fields and stop conditions; missing them is an anti-pattern by default.
3. Route recurring failures back into some $h_i$ or Sensor—not only a one-off chat correction.
4. Align with site practice: Guides / Sensors in Harness Engineering; cross-turn contracts in Loop Engineering.

Much research still optimizes $M(x)$. Harness opens another path: leave the foundation operator alone; reshape system outputs via higher-order composition rules. When capability is relatively saturated and delivery bars rise, Harness iteration grounded in composition is the main arena for cheaper robustness and interpretability—from empirical assembly toward decomposable, verifiable system optimization.

References

• Vaswani et al., Attention Is All You Need, NeurIPS 2017
• Birgitta Böckeler, Harness engineering for coding agent users, Martin Fowler, 2026
• Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models, ICLR 2023
• On this site: Harness Engineering, Loop Engineering, Agentic Coding Agent core concepts, Inner / Middle / Outer Loop