The Harness Contract Becomes the Agent Audit

The Paper

The paper is From Prompts to Contracts: Harness Engineering for Auditable Enterprise LLM Agents, arXiv:2607.08028 [cs.AI]. The arXiv API record lists Joongho Ahn and Moonsoo Kim as authors, records submission on July 9, 2026, and cross-lists the paper in Computation and Language and Software Engineering. The arXiv comment says the paper has 32 pages, six figures, 16 tables, and a public reference implementation with evaluation artifacts.

The paper's object is not a general chatbot and not an investment recommendation system. It reconstructs an LLM-based investment-briefing prototype as an auditable enterprise agent, using a bounded public-data slice of five Korean corporate groups, 25 listed companies, and 113 source-backed runtime claims.

The Prototype

A prompt-dominant prototype can be useful for exploration. It combines a system prompt, retrieved context, and a user interface to show what an interaction might feel like. The trouble begins when that prototype becomes a product while the important behavior still lives inside prose instructions. Source eligibility, company routing, answer structure, link policy, trace generation, leakage control, and validation criteria should not be hidden in one expanding prompt.

This page sits beside safety-case release gates, agent run playbooks, agent dependency graphs, AI audit trails, and curated retrieval records. Each asks the same practical question: which part of the system is carrying the promise, and can that promise be replayed?

The Harness

Ahn and Kim use "harness engineering" for a code-owned control layer around a replaceable composition model. Deterministic behavior moves into manifests, schemas, source-backed claims, answer contracts, validation scripts, and traces. The LLM remains useful, but its role narrows toward language composition at a boundary that can be substituted, checked, and recovered from.

The linked GitHub repository makes the pattern concrete. It describes a mobile briefing tool for Samsung, SK, Hyundai Motor, LG, and Hanwha groups. The repository says the app produces short source-linked company briefings from public filings, market data, and news; every visible claim links back to a registered source. Its directories separate source manifests and claims, maintained wiki pages, policy prompts, validation scenarios, deterministic tests, local server logic, and static demo assets.

The interesting move is the source-to-claim pipeline. Raw public sources do not flow directly into prose. They become evidence records, promoted claims, runtime-eligible claims, maintained context, answer plans, and reader-facing answers. The trace is not decorative logging after the fact. It is part of the contract.

Evidence

The paper reports three validation claims. First, the harness preserved source-grounding, entity-routing, trace, output-hygiene, and recommendation-language contracts across fixed validation scenarios, while fault injection showed the validators flagging deliberately broken contracts. The appendix describes 30 fixed scenarios: six per corporate group, covering five company briefings and one cross-company comparison.

Second, the composition model could be substituted without moving the code-owned guarantees. The live-LLM boundary check used three hosted model identifiers and 30 scenarios with three repeats, for 270 composition-boundary runs. The paper reports that code-owned checks passed on all 270 runs; failures were confined to model-composed checks and were caught or recovered rather than silently delivered.

Third, prompting alone did not reproduce the contract. In the enforcement-layer ablation, prompt-only instructions allowed recommendation-language and internal-trace-leakage violations to reach readers. A bolt-on external guardrail blocked those violations but over-refused, dropping utility to 88 out of 120, while the harness preserved 120 out of 120 utility in that ablation.

Limits

The paper is systems-engineering evidence, not proof of investment-answer correctness. It validates contract preservation over a bounded public-data slice and leaves expert review, broader source coverage, private documents, operational logs, and domain-value evaluation for later work. The result says where the guarantees reside, not whether the underlying business analysis is good.

The pattern also has costs. A harness requires source registration, claim promotion, scenario design, validators, trace storage, release checks, and review discipline. That is heavier than a prompt. The point is that enterprise adoption often needs that weight because the promised behavior becomes an organizational control, not a demo flourish.

The Receipt

An agent-harness receipt should name the source manifest, evidence record, claim identifier, entity scope, routing rule, answer contract, prohibited language rule, leakage rule, trace schema, composition model, prompt version, fallback path, validator version, fixed scenario, fault-injection mutation, live-model substitution run, utility count, latency record, release gate, reviewer, and replay artifact.

The governance question is not whether the prompt sounded careful. It is whether the careful part of the system is owned by artifacts that can fail loudly, be versioned, and be inspected after the answer leaves the screen.

Sources

• Joongho Ahn and Moonsoo Kim, From Prompts to Contracts: Harness Engineering for Auditable Enterprise LLM Agents, arXiv:2607.08028 [cs.AI], submitted July 9, 2026.
• arXiv experimental HTML for From Prompts to Contracts, checked for title, authorship, affiliation, architecture, validation design, result tables, appendices, and limitations.
• arXiv API record for arXiv:2607.08028, checked for title, authors, subject categories, submission date, abstract, and artifact comment.
• Reference implementation: hammerbaki/enterprise-llm-agent-harness, checked for source manifests, validation commands, deterministic tests, static demo notes, and design background.

Return to Blog