A harness is the system that turns intelligence into product behavior. Formally, LLM harnesses are “the code that determines what to store, retrieve and show to the model”1paperMeta-Harness: End-to-End Optimization of Model Harnesses, arXiv:2603.28052. The term is a more precise alternative to “GPT wrapper,” but harnesses around models have existed for more than a decade2essayLangChain — The anatomy of an agent harness.

Formal lensDefinitions of M and H
Core object H(M) LLM harnesses can be defined as H(M): persistent product software composing around callable mathematical functions.
M_imodel
Computes a mathematical function X_i -> Y_i. This can be y = ax + b, a calibrated score, an embedding function, a bandit, a deep ranker, or an LLM.
H_jharness component
Persistent software that encodes the product system. It owns lookup, business logic, validation, routing, orchestration, rendering, logging, policy, process control, and the rules for using model outputs.
H(M)product system
The composition of harnesses plus models that becomes product behavior. The model produces values; the harness turns those values into actions, interface state, decisions, traces, and user-visible output.
M_i : X_i -> Y_i
H_j : (state_t, data_t, rules, model_outputs) -> (state_{t+1}, action_j, trace_j)

H     = H_n o ... o H_1 o H_0
H(M)  = H(x; M_0, ... , M_k, state, data, rules)
P_t   = product behavior emitted by H(M)
The key distinction is where agency sits. M_i computes. H_j remembers, retrieves, filters, validates, routes, renders, logs, and enforces policy. H(M) is the full product system the user actually experiences.

Recommendation systems were early harnesses

Systems like Google search, Instagram, and LinkedIn are harnesses around recommendation and ranking models3paperGoogle Research — Ranking systems reference. The models underneath are split into many specialized submodels: encoding a query into an embedding, retrieving results based on the query plus user preferences, reranking those results to prune downstream computation, stitching together content most likely to hold attention, ranking and auctioning that content given the context of what else is on the page, and finally generating an interface around the selected set.

Fig. 1 A representative search-style recommendation workflow. A product such as Google Search can be read through this lens: request context flows through retrieval, generation, ranking, and allocation harnesses before becoming a rendered page. This is a conceptual model, not a claim about any exact implementation. Open the full diagram.

These submodels share embeddings, pass hidden layers downstream into later models like RNNs, and sit inside an intricate harness that has to return results in well under a second. Internally they were called infrastructure, and teams of hundreds maintained them to make the product faster, higher quality, more personalized, cheaper to serve, and compliance-safe. The underlying models were proprietary; the harnesses around them were a meaningful piece of the moat. OpenAI changed that paradigm by exposing frontier intelligence through an API, which let anyone build intelligent systems on top and turned the surrounding infrastructure into the most interesting layer to discuss.

The static-harness era

The first LLM harnesses that caught my eye were ChatGPT, Perplexity, and Cursor. Each was carefully crafted by a small team to give intelligence an interface for people. It quickly became clear that post-training a model against the harness improved quality, latency, and efficiency, and that frontier labs could win product fit by pairing their smartest model with their own harness. A static harness is effective to train against: the range of user behaviors is well understood, on-policy interactions with the harness are verifiable, and a judge model does not need to learn a new harness for every evaluation. We see this in practice with Codex. Opus 4.5 was a strong coding model, but GPT-5.3-Codex put up stronger SWE-Bench Pro numbers once it was trained and shipped through the Codex harness.7sourceOpenAI — Introducing GPT-5.3-Codex

Architecturally, the model still uses next-token prediction to learn patterns across training examples and applies them at inference. Harnesses like Codex or Claude Code give the model a runtime to execute code, tools to retrieve relevant context, and tools to take action. They are improved by software updates downstream of the engineering team’s code and by adding new tools, often called skills or plugins. Beyond that, the harness is fixed and roughly the same for every user.

Formal lensWhy a fixed harness trains well
In the static-harness regime, the product software H is mostly fixed while the model family, prompts, tools, and post-training data improve around that stable interface.
given fixed H
M* = argmax_{M in model_family} E[ Q(tau(H(x; M))) ]
Because H is stable, traces stay comparable across runs. The model can learn the habits of that product harness: what context is packed, which tools appear, how actions are validated, and what terminal states count as success.

Meta-harnesses and per-user evolution

A recent paper on meta-harnesses1paperMeta-Harness: End-to-End Optimization of Model Harnesses, arXiv:2603.28052 proposes that letting a model optimize the harness around its task leads to better performance. By searching over the harness, viewing prior candidate traces, and proposing new options, the outer loop lets the application improve in quality, token usage, and speed. The harness becomes a set of parameters to optimize, not a fixed surface that only changes with a human in the loop.

Autonomously improving harnesses change the paradigm of user-facing applications: from fixed general interfaces with a fringe of customizations, to interfaces that adapt per user. Dynamic per-user harnesses around LLMs have not been widely adopted yet, but this is the area Relayer is moving on quickly. The previous generation of harnesses — Google, Instagram, and so on — is a good reference for what personalized harnesses can look like.

Formal lensMoving search from M to H
The shift from M to H is not that the same model must rewrite itself. It is that model intelligence can now operate on the harness layer. H_t calls M_task for the user-facing run; M_meta may be the same model or a separate model that proposes the next harness.
Hover or focus a symbol for its role.
run H_tThe current product harness: memory, retrieval, tools, prompts, validation, state, and interface behavior. calls M_taskThe model used inside the harness to serve the user-facing task. on x_tThe current task, request, user context, and environment state. -> Y_tThe emitted product behavior: answer, page, workflow state, tool action, diff, or rendered interface. tau_tThe execution trace: inputs, retrieved context, model calls, tool calls, validation results, state changes, latency, cost, and output.
observe FeedbackA function over the output and trace: explicit feedback, implicit behavior, judge scores, task success, errors, and downstream outcomes. ( Y_tThe product output being judged. tau_tThe trace explaining how the output happened. ) -> f_tThe feedback signal produced from the output, trace, user, and environment.
score QThe quality function that turns traces and feedback into a comparable score. ( tau_tThe execution trace being evaluated. f_tThe feedback signal attached to the trace. ) -> q_tThe quality signal used by the improvement loop.
propose M_metaThe model used by the improvement loop to inspect traces and propose harness changes. It may be different from M_task. uses tau_<=tPrior execution traces available to the meta model. f_<=tPrior feedback signals attached to those traces. q_<=tPrior quality scores used to guide proposals. -> Delta H_tA proposed edit to the harness: retrieval policy, memory policy, prompt, tool route, validator, layout, workflow, or interface behavior.
search B_dThe beam of candidate harnesses at search depth d. = top_kKeeps the best k candidate harnesses instead of committing to the first proposed change. ( apply(H, Delta H)Creates a candidate harness by applying a proposed change to an existing harness in the beam. )
select B_DThe final beam after the search budget or depth limit is reached. -> H_{t+1}The next accepted harness, used by the product on the next run.
Feedback is the hinge. The system first observes whether Y_t worked, then asks M_meta to generate possible harness changes. Beam search keeps several candidate harnesses alive, scores them, and selects the next harness only after a candidate improves the quality target under the system constraints.
runtime: H_t calls M_task x_t task + context H_t current harness memory / retrieval / tools / UI M_task Y_t product output tau_t execution trace emits records feedback before Delta H Feedback(...) Y_t, tau_t, user, environment Q(tau_t, f_t) score trace + feedback q_t quality signal f_t beam search over candidate harnesses M_meta reads traces Delta H_t candidate edits B_d = top_k candidates H^1 H^2 H^3 score with Q_hat; keep beam width k H_{t+1} selected harness next run uses selected H
Fig. 2 A meta-harness loop for moving from M optimization to H optimization. The runtime harness calls M_task to emit Y_t and record tau_t; feedback and Q produce q_t; M_meta proposes candidate Delta H edits; beam search keeps the best harness variants before selecting H_{t+1}.

Large-scale consumer systems allocate content using ML models powered by aggregate counts and per-user data. User interactions become a vector representation that proxies that user’s preferences. Counts data aggregates interactions across all users and acts as a signal for ranking candidates4essayLinkedIn Engineering — Engineering the next generation of LinkedIn's feed. At scale, with fast updates, this acts as a proxy for content quality or relevance. Fast updates are what let search results and timelines react to real-world events; the user preference vector is what lets the system predict what you want to see. These systems lean on scale and simple signals like clicks to personalize the product for consumers.

Counts data is not just model training data. It is live harness memory. Every rendered feed produces a trace; every impression, like, skip, share, dwell event, hide, or report updates aggregate state. On the next request, that state changes what the harness retrieves, suppresses, scores, and allocates. The model may be the same mathematical function, but the product behavior changes because H_t is now reading C_{t+1}.

Formal lensCounts as harness memory
State update C_t Counts are persistent harness state: impressions, likes, skips, shares, dwell, hides, reports, conversions, and follows. 
(Y_t, tau_t) = H_t(C_t)(x_t; M, rules)
f_t          = Feedback(Y_t, tau_t)
C_{t+1}      = update_counts(C_t, f_t)
H_{t+1}      = H_t[C_t := C_{t+1}]
Bandit / RL special case:
a_t          = pi_t(x_t; C_t)
Y_t          = H_t(x_t; a_t, M, rules)
r_t          = reward(Y_t, tau_t)
C_{t+1}      = update_bandit_state(C_t, a_t, r_t)
pi_{t+1}     = policy(C_{t+1})
The bracket notation means the harness code may be the same, but the persistent state it reads has changed. A multi-armed or contextual bandit is one RL-style instance of this pattern: pi_t chooses an action such as an item, creative, layout, or feed mix; r_t is the reward signal from clicks, dwell, conversion, hides, or reports; and C_t stores the reward evidence used by the next policy. Counts-based recommendation infrastructure is broader because the same state can also affect retrieval, filtering, ranking, allocation, monitoring, and policy.
Fig. 3 Counts data as harness memory. Interactions in the feed update aggregate counts, which the next retrieval, filtering, ranking, and allocation pass reads before rendering a new feed. This is a conceptual IG-like feed loop, not a claim about any exact implementation.

Sufficient data and discrete feedback signals were the requirements that kept many consumer applications from becoming personalized. LLMs make it possible to get clear insights with orders of magnitude less data because they are trained on the sum of the public internet. They also turn text feedback into an actionable signal. Consumer applications can now use screenshots, videos, text feedback, and interaction timelines as the traces an outer meta-harness loop uses to propose the next version of the harness. User data becomes the trace signal that improves the harness.

What still needs to work

Speed of evolution and a suitable quality function are the two biggest open problems in the auto-improving interfaces I have been building for Relayer. A five-plus minute overhead on iterating the dynamic harness hurts user engagement. Each iteration walks through prior traces, proposes different evolutions, and evaluates them before pushing to the user. The quality function that converts a user’s session into product-quality feedback is essential for making harness iterations improve consistently. Task completeness, user velocity, and short-term task quality need to be measured during the task itself. Long-term feedback signals then need to assign credit back to the different harness iterations that shaped the session.

Two prototypes for how the Relayer harness will evolve around a user’s task: DocLayer5demoDocLayer — auto-improving harness prototype and the Meta IDE workspace6demoMeta IDE workspace — auto-improving harness prototype.