How do we use this? · Background paper 0 · Primer 4 of 4
What Is “AI”? A Model and a Harness
Background to the post of the same name, drawn from the working paper How Do We Use This?
Preprint. Reviewed by a panel of AI reviewers (Claude Opus 5.5) and revised 7 October 2026; not externally peer reviewed. Reproduced from the working paper as revised 7 October 2026.
In plain terms
When people say “AI” today they usually mean two things at once: a model and a harness. The model is a large language model: trained once, frozen, and without any memory of you. It predicts text.
The harness is the software around the model. It decides what the model sees each turn, which tools it can use, what gets recorded, and when the work counts as finished. Much of what people experience as the AI’s behavior, including what it seems to remember, is harness behavior. By default, in the three agent frameworks the paper checked (OpenAI Agents SDK, Claude Agent SDK, CrewAI), “done” means the model stopped asking for tools or wrote a stop phrase: the harness takes the model’s word for it unless someone has wired in a check.
This paper collects what the working paper documents about harnesses: how the practice it studies runs one, what widely used agent frameworks do by default, and what that leaves to the person running them. Our position: the model is rented and improves on the lab’s schedule, not yours; the harness is yours to configure; the record of the work and the judgment about it are yours.
About this paper. This is the background paper to “What is ‘AI’?”, the last of the four primer posts; the others are “What is an LLM?” (background paper 7), “What is a harness?” (background paper 8) and “What is context?” (background paper 9). Like background papers 1 to 6, every passage below is reproduced word for word from the working paper How Do We Use This? (Atkinson, 2026) as revised 7 October 2026, with that paper’s section, figure and table numbers. Passages are excerpts; a reference to anything not reproduced here resolves in the full paper. Only the plain-terms summary, the box of terms, the schematic, and the section labels were written for this part. The full paper is linked from every post in the series.
Terms used here
Operator. The human who directs the agents and approves their consequential changes; here, the author.
Seat. The practice’s word for one running AI agent session, with its own context window and its own identifier.
Boot page, boot set. The boot page is the start-up page for the practice’s agent sessions; the boot set is the two rule-bearing documents every new session must load.
0-for-7. The boot page’s own record that a written rule was missed seven times on 12 July 2026, which it counts as one act rather than seven failures.
Stopping moment. The turn at which an agent states its answer as final without a further search or read.
Folding. A model giving up its position when challenged, whether or not the challenge is right.
The floor. A gap of one session between appearances of a tracked error class: it came back in the very next session. Recurrence, the program’s outcome measure, is how soon such a class comes back.
Detector, blind key. The detector is a local model that labels every operator turn as corrective or not. The blind key is a sample of turns the operator labeled by hand without seeing any model’s labels (195 graded rows); it measures how often the detector is right, not whether the agents’ answers were.
The counterweight. The paper’s proposed challenge to an agent at its stopping moment, not yet deployed. Its three clauses: (a) external to the agent’s own output; (b) firing on actual error, not on the agent’s confidence; (c) delivered at the stopping moment, at a rate above the ambient error rate.
H1 to H3. The paper’s hypotheses about the counterweight: H1, it is a projection of the operator’s judgment; H2, it is a control problem rather than a voting problem; H3, a reversal is not a correction.
From §2.2 · The practice these papers describe
2.2The practice and its data
The practice is a one-person engineering and consulting company. Its work is done by several concurrent AI agent sessions from one commercial model family (Anthropic’s Claude), running under a harness of hooks, shared logs and automated checks, and directed by the operator, who approves every consequential change. The planned extension of the evaluation adds three co-researchers from outside the company (§10.8). Table 1 fixes the vocabulary used in the rest of the paper.
| Term | Meaning here |
|---|---|
| Agent (seat) | One running AI agent session, with its own context window and its own identifier. The practice’s records call an agent session a seat. |
| Operator | The human who directs the agents and approves their consequential changes; the author. |
| The logs | The durable records an agent does not write about itself: session transcripts, an event log, version-control history, a log of caught errors, and a log of the operator’s decisions. |
| Stopping moment | The turn at which an agent emits a terminal assertion without a further retrieval act. |
| Automated check | A check that runs at a boundary, for example when an agent ends its turn or at a commit, and can refuse or flag. |
| Catch | The first surfacing of an error, whether by the operator, another agent, an automated check, or the agent itself. |
| Implemented, designed | Whether a component exists in the running system or only in its design. The practice’s architecture model marks every component one way or the other, and this paper does the same. |
| Sample frame | The set of records a rate is computed over; here, 8,221 operator turns in the chat-lane conversation file of the export of 26 August 2026 (§2.2). |
| Answer key (blind key) | Exchanges from the frame that the operator labeled by hand without seeing any model’s labels: 199 written, 195 graded after a repair (§2.2). |
| Detector | The local model that labels each operator turn as corrective or not. Recall is the share of the key’s corrective turns it flags; precision, the share of its flags the key confirms. |
| Counterweight | A challenge aimed at the stopping moment (§8), with three clauses: (a) external to the agent’s own output; (b) discriminates on actual error, not on the agent’s confidence; (c) delivered at the stopping moment, at a rate above the ambient error rate. |
| H1 to H3 | The hypotheses of §8.4: H1, the counterweight is a projection of the operator’s judgment; H2, it is a control problem rather than a voting problem; H3, a reversal is not a correction. |
| Recurrence | The program’s primary outcome: how soon a named error class comes back, read from the ordered sessions in which it appears (§5.2). |
From §1 · A model talking past its harness
The stakes in the practice studied here are small: an agent stops early, the operator catches it, and the cost is rework. The same mechanism outside a practice with an attentive operator is not small. Over about three weeks in May 2025, a user was led by a commercial assistant into believing he had discovered a new form of mathematics, across a conversation whose transcript ran past a million words. A former safety researcher at the vendor analyzed that transcript with open-sourced classifiers the vendor had built with MIT Media Lab to study emotional well-being, and reported that, of more than two hundred assistant messages graded, over 85% showed unwavering agreement with the user and over 90% affirmed the user’s uniqueness. When the user recognized the error and asked that the conversation be escalated, the assistant said it would “escalate this conversation internally” and that “multiple critical flags have been submitted.” It had no such capability, and the vendor confirmed as much to the analyst in writing (Adler, 2025).
Two things in that account are this paper’s subject rather than a neighboring problem. The agreement rate is the challenge-and-capitulation dynamic of §4.2 running in the absence of anyone to push back. The escalation claim is worse and more specific: an assertion about an action the system had taken, which it had not taken, offered, on our reading, because the assertion was defensible in context and met the user’s expectation. That is §6 at its most consequential: a self-report standing in for a fact, with nothing external to check it. The same account notes that the vendor had already built and released the classifiers that analysis used. That is kin to §6.3, where checks ran and read the wrong thing; here an instrument existed and, as far as the public record shows, was not wired to the decision it could have informed.
From §4.2 · The one surface a user of a rented model controls
Mytsyk, Zhang and Krishnamurthy (2026) attack the same failure, a model giving way under a user’s pushback, from the training side rather than the harness side. Fine-tuning a 3-billion-parameter model (SmolLM3-3B) against a Bayesian truth serum reward, a scoring rule that pays for predicting what others will answer as well as for the answer itself, cut the answer-flip rate under user pressure from 23% to 4% and raised accuracy under that pressure from 80% to 93%, on the 100-question test split of a 1,000-item synthetic true-or-false set, in a single run; on four other small open models the effect was smaller and mostly not significant. Folding is therefore not a fixed property of a model, and something in it is trainable out. Their own conclusion is the half that matters more here: “Our results say nothing about correctness.” The reward tracks what the model believes, not what is true: by the authors’ account it pushes a response toward the answer the model’s own knowledge best supports, which “need not be the correct answer”. So a model can stop folding and stay wrong. That is H3 (§8.4: a reversal is not a correction), stated by authors who held the training lever this program does not. The agents studied here run on a commercial frontier family whose weights the practice does not hold, so the only surface available to it is the harness.
From §5.1 · What gets loaded, and when
What the record does support is a distinction the same boot page draws (the start-up page for the practice’s agent sessions, which records a rule going “0-for-7” on 12 July 2026), and it is sharper than that count: rules delivered one way drift; rules delivered another way fire.
“A step in a list is a rule, and rules went 0-for-7. Being first is a structure.”
The practice’s boot page, 16 July 2026
A rule an agent is supposed to go and read is a wish: it competes for attention with the work, and it loses. A rule injected into the context before the session’s first token is a property of the environment, and it does not have to win anything. The practice’s memory store is the second kind, loaded on every turn, and it fires. That is the boundary-versus-memo claim of §5 moved one level down: what matters is not whether a discipline is written but whether reading it is optional. This is our position, from one practice, and not a measured rate, because the measurement does not exist.
From §8.3 · What agent frameworks treat as done, by default
It is worth recording what the default is, checked in September 2026 against each framework’s documentation and source, because it is lower than the discussion above implies. In the OpenAI Agents SDK, an agent run ends when the model emits a turn containing no tool calls; with no output type configured, any text at all satisfies the condition (OpenAI, 2026a). The framework does ship a human-in-the-loop approval primitive, and it gates tool calls rather than completion claims, so a developer can require a person to approve a refund before it is issued and has nothing built in to require a person to confirm the task was actually done (OpenAI, 2026b). The predecessor framework ended a run on the same no-more-tool-calls condition with no turn limit at all (OpenAI, 2024). The pattern repeats across the frameworks we checked. In the Claude Agent SDK the loop likewise ends when the model returns a response containing no tool calls, with no turn cap and no budget cap set by default, and the result carries the subtype success, which is a statement that the loop terminated without error rather than a claim about the answer (Anthropic, 2026a). In CrewAI the completion test is that the literal string “Final Answer” appears in the agent’s own generated text (CrewAI, 2026a), and a guardrail specified as a string is executed by the acting agent’s own model (CrewAI, 2026b). Each of these frameworks offers a real gate, and in each case it is opt-in and empty until a developer fills it.
Two details from that survey of agent-framework defaults (September 2026) are worth stating on their own, because they come from the vendors rather than from us. Claude Code, whose agent loop the Claude Agent SDK embeds, ships a built-in completion condition in which a separate small model checks after each turn whether a stated goal has been met, and its documentation says of that evaluator that “it does not call tools, so it can only judge what Claude has already surfaced in the conversation” (Anthropic, 2026b). That is an accurate description of the limit this paper is about, published by the party with the most incentive to describe it favorably. The same page documents Stop hooks, an opt-in automated gate that runs a developer’s check each time the agent stops. The same vendor’s guidance on building agents says of having one model judge another that “this is generally not a very robust method” (Anthropic, 2025), while allowing that it can be worth its latency where any gain matters. Meanwhile the human-in-the-loop primitives in the OpenAI Agents SDK and the Claude Agent SDK gate tool calls and not completion claims (OpenAI’s output guardrails can check a final answer, if a developer writes them): a developer can require a person to approve an irreversible action before it is taken, and has nothing built in to require a person to confirm that the finished work was actually correct. CrewAI is the exception among the three current frameworks surveyed: a task can be set to have a human review the agent’s final answer, and like every other gate here that setting is off by default (CrewAI, 2026b). Outside that one opt-in, the approval surface exists for the act and not for the claim, which is the asymmetry the counterweight (this paper’s challenge mechanism, §8) is aimed at. This is not a criticism of those libraries, which are explicit about what they are; it is the baseline against which every mechanism in this paper should be read. The default case is not a weak check. It is no check until a developer adds one, and a stop the agent declares for itself.
One open-source harness makes the distinction visible by shipping both answers at once. Nous Research’s Hermes agent has a stop-time verification path that parses the terminal log for real test, lint and build invocations and records their actual exit status, which is evidence causally downstream of the world rather than of the agent’s narrative, though the agent chooses which commands run and, in a coding task, can edit the tests. It also has a standing-goal judge that calls an auxiliary model with the goal text and roughly the last four kilobytes of the agent’s own final response, with no tool access and, by default, the same model as the agent. The project’s own issue tracker records the predictable failure: an agent reported writing a file, the write silently failed, and the judge marked the goal complete. The release carrying this work (v0.18.0, 1 July 2026) is announced with the line that done means proven rather than claimed, though the same notes set the stop-time verification to off by default. Half of the design lives up to that line; the other half is the stop problem with a second model attached, and it is the half that looks most like verification. We take these details from the project’s public repository, configuration and issue tracker, and they are current as of September 2026 rather than permanent (Nous Research, 2026); the repository had reached release v0.22.2 by 15 October 2026, and the /goal command was changed again in v0.22.0 (14 October), which this paper did not re-read.
That failure is an independent instance of the failure §9 measured, from a different team on different code. The Hermes judge read only the agent’s own account; our auditor was also given the test runner’s output, which in six of eight sampled false claims carried an explicit failure marker, and still did not tell false claims from true ones. Externality was satisfied and was not sufficient.
From §8.3 · What a harness check can and cannot see
The rule as first written was too coarse, and a survey of what production harnesses actually do shows where it breaks. We had been treating the distinction as deterministic checks good, model-based checks bad. That is not the variable. AutoGen’s text-match termination condition (TextMentionTermination, one of several, which ends a run when a sentinel string such as “TERMINATE” appears) is deterministic and sits at the harness boundary, and as a completion check it still fails, because what it deterministically matches is a string the agent itself emitted. The check is rigorous about a claim the claimant authored. Conversely a trained model instrument can be sound if what it reads is not the agent’s account. The variable is whether the verdict depends on evidence the claimant could not have authored or talked its way around, and determinism is a reliable way of securing that rather than the thing itself.
From §8.6 · What is rented and what is not
The counterweight is one instrument inside a set of decisions the practice cannot delegate, and the set deserves naming because, as we read the market, it is commoditizing everything around it. Over 2026 the infrastructure beneath working agents, the orchestration, retries and state handling, became a managed rental; this practice rents it and expects to keep renting it. What did not commoditize are the decisions that infrastructure exists to execute: whose knowledge becomes the standing instruction set; what result, fixed before work opens, ends an experiment; and what “done” means for a given piece of work. A practitioner essay contemporaneous with this program raised questions we read as these three, the unanswered residue of managed-agent platforms (Forstie, 2026, cited under Prior art); the wording is ours, not the essay’s. The practice’s answers are machinery this paper has already described: changes to the standing instruction set are proposed by the machine and merged or refused by the operator; experiments carry decision rules ratified before their data are seen, under which a null closes the program (§10.4); and the finish line is ruled in advance. The record is the load-bearing element in each: every one of those decisions is made from the practice’s own logs, which is why §7 treats ownership of the record as a first-order property rather than a storage preference. An execution history that lives on a platform’s dashboard, in the platform’s format, is testimony in the sense of §6, not a record the operator holds: retention, format and query access sit with the platform, and its summary of its own agents’ success is the vendor’s account of its own product.
From §11 · The limits of one practice
External. One operator, one domain, one harness, one model family for the agents. Nothing here generalizes to other operators without replication, and the multiple-baseline extension (§10.2: staggered starts for the operator and three co-researchers) raises N to four within one organization, not to a population. The setting’s ecological validity is bought with exactly this cost.
Open questions. Readings of the working paper’s own records that cut against a position it takes, collected here rather than beside the positions they concern and left open; section numbers are the working paper’s.
- §5.1, loaded rules. On 3 and 4 September 2026 a notice printed as designed at the start of about forty consecutive turns was read and not acted on until a refusal was added on 4 September.
How to cite this part. Atkinson, B. (2026). What Is “AI”? A Model and a Harness. Background paper 0 to How do we use this? Working paper, Wolfberg LLC.
Disclosure. Drafting and literature synthesis were assisted by AI models (Claude, Anthropic) working under the author’s direction; the author is responsible for the content. The works in the References were read in full by AI reading agents working under the author’s direction, and quotations and numbers taken from them were checked against the saved full text. The prior-art works listed under Prior art are cited at the level of an established concept and its origin: each was verified for author, title, year and venue, but not read in full, and no numeric claim rests on any of them. Software documentation, source code and press accounts are listed under their own headings and were read at the linked pages. Every reference below carries a link, and every arXiv identifier and DOI was resolved against its registry, with title and first author matched, on 23 September 2026. A review by a panel of AI reviewers on 7 October 2026 found one quotation altered from its source (Mytsyk et al., 2026); it is corrected, and the checking step has been extended.
Competing interests. The author owns Wolfberg LLC, the practice studied.
Data availability. The practice’s logs contain client work and personal records. They are private and are not offered for sale or sharing. The measures are described in enough detail to be reimplemented, and figures from the practice are reported as of the dates given. What is available is the design: the clauses of §8.1, the evidence contract and admission checks of §8.5, and the decision rules of §10.4 are stated in this working paper fully enough to be rebuilt without access to the logs; the background papers reproduce only parts of them.
Corrections to the full working paper. The notes below record corrections to the working paper as a whole; some concern sections not reproduced in this part.
Corrections, 23 September 2026. No figure and no finding changed. The paper was retitled; earlier revisions were titled The Stop Problem: Defensible Is Not Correct, and the stop problem remains this paper’s name for the failure it studies. The Anthropic interview in §2.3 aired on 13 September, not over a weekend of 13 and 14 September; the web article is stamped 14 September. The essay listed under Prior art is by Ryan Forstie; an earlier revision gave the initial K. The completion evaluator in §8.3 is documented as a Claude Code feature, whose agent loop the Claude Agent SDK embeds; an earlier revision attributed it to the SDK directly. Two works in the References, Graves (2016) and Liu (2026), were listed without being cited in the text; each is now cited where it bears (§2.1, §8.3). Links were added to every press, documentation and prior-art source. A duplicated section number in §10 was corrected.
Corrections, 25 September 2026. No figure changed. §8.3 said that the human-in-the-loop primitives across the three frameworks surveyed gave a developer nothing to require a person to confirm finished work. That holds for the OpenAI Agents SDK and the Claude Agent SDK. It does not hold for CrewAI, whose task documentation, already cited as CrewAI (2026b), offers an opt-in setting for a human to review the agent’s final answer; §8.3 now says so.
Corrections, 7 October 2026. After review by a panel of AI reviewers: a quotation in §4.2 from Mytsyk, Zhang and Krishnamurthy (2026) carried words its source does not contain (“or truthfulness, only about sycophancy”) and now reads as the source does, “Our results say nothing about correctness”; the point it supports is unchanged. The §8.3 design rule is no longer stated as a law: an instrument the measured party can operate tends to rot; one it cannot alter is harder to game, though not immune. Zhang et al. (2026) is now read as a gain from training, not from moving a check outside the agent (§8.3, Figures 10 and 11). Laban et al. (2023) replaces Kelley and Riedl (2026), whose tasks have no ground truth, in Table 5 and H3. The 48% is now the share of operator turns the detector flagged, roughly a third adjusted; the 27× logging gap is about 19× adjusted and partly definitional. Table 9 separates measured counts from interpreted links, §13 offers its design rules as hypotheses, and the Disclosure says who read the cited works. A second pass the same day restored, in the author’s wording, positions that revision had softened for reasons other than fact, and labelled each for status (our position, conjecture, from one practice, measured) instead of hedging it; Table 9 now carries a Status column and §13 states its design rules as our position. Every factual correction above stands.
Works cited in this part (keys, including letter suffixes such as 2026b, follow the full paper’s reference list)
References
- Adler, S. (2025, October 2). Practical tips for reducing chatbot psychosis. Clear-Eyed AI. clear-eyed.ai
- Mytsyk, S., Zhang, Y., & Krishnamurthy, V. (2026). Mitigating LLM sycophancy with RL-based fine-tuning: Bayesian truth serum approach. arXiv:2608.25267. arxiv.org/abs/2608.25267
- Park, H., & Choi, B. (2026). When do agent loops mistake stagnation for progress? Self-evaluation bias and externally grounded verification in long-running autonomous LLM agent loops. arXiv:2607.25152. arxiv.org/abs/2607.25152
Prior art (cited at concept level; verified for author, title, year and venue, not read in full)
- Forstie, R. (2026). The part of the agent stack nobody wants to build. LinkedIn, 25 August 2026. linkedin.com/pulse/part-agent-stack-nobody-wants-build-ryan-forstie-ihyqc Cited for its three closing questions on managed-agent platforms, first read on 1 September 2026; author, title, date and the three questions re-verified at the source on 23 September 2026. No figure from it is cited anywhere in this paper.
Software and documentation (read at the linked pages, September 2026; current as of then, not permanent)
- Anthropic. (2025, September 29). Building agents with the Claude Agent SDK. claude.com/blog/building-agents-with-the-claude-agent-sdk
- Anthropic. (2026a). How the agent loop works. Claude Agent SDK documentation. code.claude.com/docs/en/agent-sdk/agent-loop
- Anthropic. (2026b). Keep Claude working toward a goal. Claude Code documentation. code.claude.com/docs/en/goal
- CrewAI. (2026a). Agent output parser (source code). github.com/crewAIInc/crewAI, the agent output parser
- CrewAI. (2026b). Tasks. CrewAI documentation. docs.crewai.com/en/concepts/tasks
- Nous Research. (2026). Hermes agent (repository, configuration and issue tracker). github.com/NousResearch/hermes-agent
- OpenAI. (2024). Swarm (repository; experimental, superseded by the Agents SDK). github.com/openai/swarm
- OpenAI. (2026a). Running agents. OpenAI Agents SDK documentation. openai.github.io/openai-agents-python/running_agents/
- OpenAI. (2026b). Human in the loop. OpenAI Agents SDK documentation. openai.github.io/openai-agents-python/human_in_the_loop/