Andrii Bidochko

• Updated: July 11, 2026
• 7 min read

From Prompts to Contracts: Harness Engineering for Auditable Enterprise LLM Agents

Direct Answer

The paper introduces harness engineering, a systematic framework that converts prototype‑level LLM prompts into auditable, contract‑driven enterprise agents. By moving deterministic logic into code, schemas, and validation layers while keeping source‑grounded claims as the runtime authority, the approach guarantees traceability, safety, and reproducibility for production‑grade AI systems.

Background: Why This Problem Is Hard

Enterprises that experiment with large language models (LLMs) typically start with a handful of prompts and a retrieval pipeline that stitches together external data. While this “prompt‑first” style is fast for proof‑of‑concept work, it collapses under the weight of real‑world requirements:

• Source boundaries: Business logic must know exactly which data source produced each answer, a need that ad‑hoc prompts cannot guarantee.
• Entity routing: Multi‑tenant systems must direct queries to the correct legal entity, department, or customer segment without leaking information.
• Answer contracts: Regulatory frameworks (e.g., GDPR, financial compliance) demand that every response obeys a predefined schema and style.
• Reproducible traces: Auditors need a deterministic audit trail that shows how a particular answer was derived, which is impossible when the only “code” is a mutable prompt.

Current mitigation strategies—such as prompt versioning, external guardrails, or post‑hoc logging—are brittle. Prompt versioning does not prevent a model from drifting away from the intended contract, and external guardrails often over‑reject, sacrificing utility. Moreover, most LLM orchestration platforms treat the model as a black box, leaving compliance teams without a verifiable source of truth.

What the Researchers Propose

The authors present a harness‑engineering pattern that reframes the LLM agent as a composition of three layers:

1. Code‑owned deterministic layer: All static logic—routing rules, schema validation, and contract enforcement—is expressed in conventional code, manifests, and JSON schemas. This layer is version‑controlled and immutable at runtime.
2. Source‑backed claim layer: The LLM remains the sole authority for generating factual content, but each claim is explicitly tied to a provenance record (e.g., a database row, a web‑scraped document, or an internal API).
3. Replaceable composition boundary: A thin, well‑defined interface where the deterministic layer hands off to the LLM and receives a structured response. The boundary can be swapped out for a different model without breaking the surrounding contracts.

In essence, the framework treats prompts as “contracts” rather than “code”. The contract specifies what shape the answer must have, what provenance it must cite, and which entities may receive it. Violations are caught before the answer reaches the end user, turning safety checks from reactive to proactive.

How It Works in Practice

The practical workflow can be broken down into four stages, each mapped to a concrete component:

1. Ingestion & Source Grounding

A data‑ingestion service pulls public‑domain financial filings for a set of Korean corporations. Each document is stored with a unique identifier and indexed in a vector store (e.g., Chroma DB). The ingestion pipeline also emits a source manifest that records the origin, timestamp, and legal entity of every record.

2. Routing & Contract Generation

A routing engine reads the incoming user request, extracts the target entity (e.g., “Samsung Electronics”), and selects the appropriate manifest. It then builds a contract object that encodes:

• Required answer schema (JSON fields, data types, and allowed vocabularies).
• Citation policy (which source IDs must appear).
• Safety constraints (no internal trace leakage, no disallowed language).

3. LLM Invocation at the Composition Boundary

The contract, together with the retrieved context, is sent to a hosted LLM (e.g., an OpenAI or Anthropic model). The model is instructed to produce a response that satisfies the contract, but the model itself is not trusted to enforce the contract.

4. Validation & Auditable Output

A validation layer parses the model’s raw output, checks schema conformity, verifies that every required citation appears, and confirms that no prohibited tokens leaked. If any check fails, the system either retries with a stricter prompt or returns a structured error that includes the exact validation failure.

What distinguishes this approach from a simple “prompt‑plus‑post‑processing” pipeline is the strict separation of concerns: deterministic checks live in code, while the LLM is only ever asked to generate content that is subsequently verified. The composition boundary is deliberately replaceable, allowing organizations to swap models (e.g., from a proprietary API to an on‑premise Ollama instance) without rewriting validation logic.

Evaluation & Results

The authors evaluated the harness on a public‑data slice covering five Korean corporate groups (25 listed companies). They posed three research questions and designed a fault‑injection control to stress‑test the system.

Scenario 1: Contract Preservation Under Fixed Validation

Across 270 runs, the harness consistently enforced source grounding, entity routing, trace hygiene, and language contracts. When the researchers deliberately broke a contract (e.g., omitted a required citation), the validator flagged the violation immediately, proving that the checks are both sensitive and reliable.

Scenario 2: Model Substitution Robustness

The same contract suite was executed with three different hosted models. All three passed the deterministic checks on the composition boundary, confirming that the harness’s guarantees are model‑agnostic. Failures that did occur were confined to the model‑generated side (e.g., hallucinated facts) and were captured by the validation layer, never reaching the user.

Scenario 3: Code‑Owned Guarantees vs. Prompt‑Only Controls

When the deterministic layer was stripped away and only prompt instructions were used, the LLM produced answers that violated recommendation‑language contracts and leaked internal trace identifiers. An external guardrail (a black‑box filter) caught many violations but over‑rejected, reducing usable answers from 120/120 to 88/120. By contrast, the harness preserved full utility (120/120) while eliminating all safety breaches.

These results demonstrate three key points:

• The harness can enforce complex, multi‑dimensional contracts without sacrificing answer quality.
• Contract enforcement is decoupled from the underlying model, enabling seamless upgrades or migrations.
• Code‑owned safety guarantees outperform prompt‑only or external‑guardrail approaches, delivering both compliance and utility.

Why This Matters for AI Systems and Agents

Enterprises that deploy LLM agents face a trilemma: they need high‑quality answers, strict regulatory compliance, and the ability to evolve models over time. Harness engineering resolves this tension by providing a reusable, auditable scaffold that can be layered on top of any LLM.

Practically, the pattern enables:

• Versioned compliance artifacts: Contracts, schemas, and manifests live in a Git‑tracked repository, giving auditors a clear change history.
• Dynamic model swapping: Because the deterministic layer does not depend on model internals, organizations can experiment with cheaper or more secure on‑premise models without re‑engineering safety checks.
• Reduced operational risk: Validation failures are caught early, preventing downstream propagation of erroneous or non‑compliant content.
• Scalable orchestration: The composition boundary can be exposed as a micro‑service, allowing workflow automation tools (e.g., Workflow automation studio) to chain multiple harnessed agents together.

For AI product managers and CTOs, this means they can promise “auditable AI” to regulators and customers while still leveraging the rapid innovation cycle of LLMs. The approach aligns with emerging enterprise AI standards that require traceability and explainability, positioning harness‑engineered agents as a best‑practice baseline for future AI contracts.

What Comes Next

While the study validates the core concept, several open challenges remain:

• Scalability of validation: As contract complexity grows (e.g., multi‑step reasoning or cross‑document synthesis), validation may become a bottleneck. Research into incremental schema checking or compiled contract languages could mitigate latency.
• Adaptive contracts: Current contracts are static; future work could explore contracts that evolve based on user feedback or regulatory updates without redeploying the entire harness.
• Integration with broader AI ecosystems: Connecting harnesses to observability platforms, model‑monitoring dashboards, and automated policy engines will be essential for large‑scale deployments.

Potential applications extend beyond financial analysis. Any domain that requires provenance‑rich, compliant AI—such as legal document drafting, medical decision support, or supply‑chain risk assessment—can adopt the harness pattern. Companies looking to embed auditable agents into their products may start by exploring the Enterprise AI platform by UBOS, which already supports contract‑driven workflows and integrates with popular vector stores.

In the longer term, we anticipate a marketplace of reusable contracts (e.g., “financial‑summary contract”, “privacy‑compliant recommendation contract”) that can be shared across industries, accelerating the shift from ad‑hoc prompting to engineering‑grade AI services.

For readers who want to dive deeper into the original methodology, the full study is available on arXiv.

Andrii Bidochko

CTO UBOS

Andrii Bidochko is an AI entrepreneur and researcher focused on AI agents, reinforcement learning, and autonomous systems. He writes about the technologies shaping the future of machine intelligence, from frontier models and agent architectures to real-world AI applications.