Don't Let the LLM Drive - Ornella Bahidika & Joel Allou, Microsoft

LLM reliability in multi-step applications requires treating the model as a performer (talent) constrained by explicit control flow (harness), not as a decis...

By Sean Weldon

Abstract

Large Language Model (LLM) applications in production environments exhibit persistent reliability failures in multi-step workflows despite adequate demonstration performance. This analysis examines harness engineering, a control-theoretic architectural pattern that separates model execution capabilities from decision-making authority. The approach positions LLMs as constrained performers executing discrete tasks within explicit control flows, rather than as autonomous agents managing their own state progression. Empirical evidence from voice tutoring applications demonstrates that this architectural separation enables model downgrading from Claude Opus 4.7 to Claude Haiku 4.5 without performance degradation, while simultaneously reducing latency and operational costs. The framework implements a six-step state machine with externalized control logic for lesson progression, completion detection, and learning validation. These findings suggest that reliability in agentic systems constitutes a control problem rather than a prompting problem, with implications extending to coding agents, operational runbooks, and onboarding workflows.

1. Introduction

The operationalization of Large Language Models in multi-step production applications has revealed a fundamental reliability gap. Applications that demonstrate flawless execution in controlled testing environments frequently exhibit systematic failures during operational deployment, including step omission, infinite loops, and premature completion declarations. This phenomenon represents a critical challenge in the deployment of agentic AI systems, where sequential task execution with state maintenance across interactions is required.

The conventional response to these reliability issues has centered on prompt engineering methodologies - iteratively refining instructions, adding constraints, and increasing prompt complexity to address observed failure modes. This approach implicitly treats reliability as a communication problem, operating under the assumption that sufficiently detailed instructions will guide the model toward consistent behavior. However, production evidence suggests that this paradigm fundamentally mischaracterizes the nature of the reliability challenge.

This analysis examines an alternative architectural framework termed harness engineering, wherein the LLM functions exclusively as an execution engine for discrete, well-specified tasks, while a separate control layer manages state transitions, output validation, and decision logic. The central thesis posits that reliability failures stem not from inadequate model capabilities or insufficient prompting, but from inappropriate allocation of control responsibilities. The framework is evaluated through the Ace Lesson Architecture, a voice tutoring application that implements these principles through explicit state machines and externalized control flow.

2. Background and Related Work

2.1 The Control Problem in Agentic Systems

Multi-step LLM applications, commonly termed "agents," require sequential execution of interdependent tasks with persistent state maintenance. Traditional architectural approaches embed both task execution and control flow logic within the model's reasoning capacity, relying on natural language prompts to specify not only task requirements but also completion criteria, state transitions, and error handling procedures.

Production deployments reveal systematic failure modes that persist despite sophisticated prompt engineering. Models skip intermediate steps in established workflows, enter repetitive execution loops, or incorrectly assess task completion status. The persistence of these failures across prompt refinement iterations suggests that the underlying issue transcends communication clarity and represents a fundamental architectural misalignment.

2.2 The Talent-Director Model

The harness engineering framework employs a theatrical metaphor to clarify architectural role separation. The talent-director model positions the LLM as a performer with exceptional execution capabilities for specific, bounded tasks - analogous to an actor delivering individual lines with nuance and skill. The harness functions as the director, maintaining awareness of overall structure, managing state progression, and determining appropriate next actions. This separation reflects an empirical observation: models demonstrate high competence in constrained task execution but exhibit unreliable performance in self-directed state management and progression tracking.

3. Core Analysis

3.1 Architectural Principles of Harness Engineering

The harness engineering paradigm implements a strict separation of concerns between model capabilities and control logic. The model receives what the framework terms a neural contract for each discrete step: a confined input specification requiring execution of a single, well-defined task with explicit output requirements. The model never determines its position within a workflow sequence, assesses overall task completion, or decides subsequent actions.

Control responsibilities are externalized to the harness layer, which implements three core functions: output validation, state advancement, and next-step determination. The model proposes outputs through execution of its assigned task, but the harness layer decides whether to accept these outputs and what state transitions they trigger. This architectural pattern is summarized in the principle: "Let it talk, but don't let it drive."

The framework addresses the fundamental observation that models are "brilliant at delivering a line, but really terrible at remembering if it's on step three of six." By constraining the model to single-step execution and externalizing memory and progression logic, the architecture aligns model responsibilities with demonstrated model capabilities.

3.2 The Ace Lesson State Machine

The Ace Lesson Architecture instantiates harness engineering principles through a six-step state machine: intro → teach → check → grade → advance → wrap. Each state corresponds to a discrete phase of the tutoring interaction, with explicit transition criteria managed by the harness layer rather than model inference.

Three critical control decisions are engineered outside the model: (1) lesson completion detection, (2) learning validation, and (3) next-step determination. These decisions, which proved unreliable when delegated to model reasoning, are instead implemented as explicit harness logic operating on validated model outputs.

The architecture employs multiple concurrent harnesses, each managing a specific aspect of the interaction. Lesson logs reveal simultaneous execution of a section harness (determining content scope), whiteboard drawing harness (managing visual representations), queue clearing logic (handling interaction backlog), and lesson ending logic (detecting completion conditions). Each harness provides confined inputs to the model, ensuring that model execution focuses exclusively on the required action for each specific step.

3.3 Model Downgrading Without Performance Loss

A critical empirical finding demonstrates that harness engineering enables model downgrading without performance degradation. The Ace Lesson system replaced Claude Opus 4.7, a frontier model with advanced reasoning capabilities, with Claude Haiku 4.5, a smaller model with reduced reasoning capacity and faster inference.

This substitution achieved expected performance levels despite the reduced model capabilities, while simultaneously reducing operational costs and latency. The result validates the core thesis: when control flow is properly externalized, the model's role reduces to bounded task execution, which smaller models can perform reliably. The architectural separation allows system designers to optimize model selection for execution capabilities rather than reasoning capacity, since reasoning responsibilities have been transferred to deterministic control logic.

3.4 Generalizability Across Application Domains

The harness engineering framework extends beyond voice tutoring to diverse application domains. The same architectural principles apply to coding agents, operational runbooks, onboarding workflows, and voice model applications. The decision criterion for applying harness engineering is straightforward: if agent reliability resembles "somewhat of a coin flip," control flow should be extracted from the model into explicit harness logic.

This generalizability suggests that the reliability challenges observed in voice tutoring represent a common failure mode across agentic applications. The pattern of building abstractions around the model, rather than requesting that the model manage its own decision-making, offers a systematic solution to reliability challenges in multi-step LLM applications.

4. Technical Insights

4.1 Implementation Patterns

The state machine architecture eliminates ambiguity about workflow progression through discrete, explicitly defined states. Each state transition requires harness validation, preventing invalid progressions that occur when models self-assess their position within a workflow. The six-step structure (intro, teach, check, grade, advance, wrap) provides sufficient granularity to capture tutoring interaction phases while maintaining manageable state complexity.

Model output validation occurs at the harness layer before state advancement, implementing a validation gate that prevents invalid transitions. This pattern ensures that model outputs meet specification requirements before they influence system state, providing a critical reliability mechanism absent in architectures where models directly control their own progression.

4.2 The Neural Contract Pattern

The neural contract pattern structures model interactions through explicit input specifications and single-output requirements. Each model invocation receives a confined input designed to elicit a specific, validatable output. This contrasts with traditional prompting approaches that request complex reasoning about workflow state, completion criteria, and next actions within a single model call.

The pattern reduces model cognitive load by constraining the decision space for each invocation. Rather than reasoning about overall workflow state while simultaneously executing a task, the model focuses exclusively on task execution. State reasoning and progression logic occur in deterministic harness code, where they can be tested, debugged, and modified through conventional software engineering practices.

4.3 Trade-offs and Limitations

Harness engineering requires upfront architectural investment to design state machines, implement validation logic, and structure neural contracts. This represents increased initial development effort compared to prompt-based approaches. However, this investment yields systems where reliability improvements occur through deterministic code changes rather than iterative prompt refinement, enabling conventional software engineering practices.

The framework assumes that workflow structure can be explicitly modeled as a state machine with defined transitions. Applications with genuinely emergent or highly dynamic workflow structures may not fit this pattern. Additionally, the approach optimizes for reliability over model autonomy, which may be inappropriate for exploratory or creative applications where constrained execution is undesirable.

5. Discussion

The harness engineering framework challenges the prevailing assumption that LLM reliability improvements primarily emerge from model capability advances or prompt engineering sophistication. Instead, the evidence suggests that reliability in multi-step applications constitutes a control problem requiring architectural solutions. The observation that "reliability was never a prompting problem, it's a control problem" reframes the challenge from communication optimization to appropriate responsibility allocation.

The successful model downgrade from Opus 4.7 to Haiku 4.5 has significant implications for production deployment economics. If smaller, faster, cheaper models can achieve equivalent reliability through architectural patterns, organizations can optimize for operational efficiency rather than model capability. This finding suggests that the current focus on frontier model capabilities may be misaligned for many production applications, where reliability and cost matter more than reasoning sophistication.

The generalizability of harness engineering across application domains indicates that the reliability challenges observed in voice tutoring represent a common failure mode in agentic systems. The pattern suggests a broader principle: when models are asked to simultaneously execute tasks and manage their own control flow, they exhibit systematic reliability failures. Architectural separation of these concerns addresses the root cause rather than symptoms.

Future investigation should examine the boundaries of harness engineering applicability. Questions remain about optimal state granularity, the trade-off between state machine complexity and model autonomy, and methods for systematically identifying which control decisions should be externalized. Additionally, the interaction between harness engineering and emerging model capabilities warrants investigation, particularly as models develop stronger state-tracking and planning capabilities.

6. Conclusion

This analysis demonstrates that reliability in multi-step LLM applications emerges from architectural patterns rather than model capabilities or prompting sophistication. The harness engineering framework, which separates model execution from control logic through explicit state machines and externalized decision-making, enables smaller models to achieve production-grade reliability while reducing latency and operational costs.

The key contribution lies in reconceptualizing the model's role from autonomous decision-maker to constrained performer executing discrete tasks within explicit control flows. This architectural separation aligns model responsibilities with demonstrated model capabilities, addressing the fundamental observation that models excel at bounded task execution but exhibit unreliable self-directed state management.

Practitioners deploying multi-step LLM applications should consider extracting control flow from model reasoning when reliability proves inconsistent. The pattern of building abstractions around models rather than requesting self-management offers a systematic path to production-grade reliability. As agentic AI systems become increasingly prevalent, architectural frameworks that appropriately allocate control responsibilities will prove essential for operational success.

Sources

About the Author

Sean Weldon is an AI engineer and systems architect specializing in autonomous systems, agentic workflows, and applied machine learning. He builds production AI systems that automate complex business operations.

LinkedIn | Website | GitHub