LLM-as-Code Agentic Programming for Agent Harness
Source: arXiv:2606.15874 · Published 2026-06-14 · By Junjia Qi, Zichuan Fu, Jingtong Gao, Wenlin Zhang, Hanyu Yan, Xian Wu et al.
TL;DR
This paper examines a fundamental architectural flaw in current large language model (LLM) agent frameworks: assigning the orchestration role—that is, managing control flow such as loops, branching, sequencing—to inherently probabilistic LLMs. The authors argue this mismatch causes three persistent issues common in long-horizon tasks: token explosion (growing context size), control-flow hallucinations (erroneous step skipping or repetition), and unreliable completions (failure to execute all necessary steps). These issues stem from delegating deterministic workflow steps to a stochastic sampling process rather than implementation bugs fixable by prompts or stronger models. To address this, they propose Agentic Programming, where the program, not the LLM, controls all deterministic flow and invokes the LLM only for reasoning or generation subtasks. Their design, called LLM-as-Code, structures context as a directed acyclic graph (DAG) reflecting the call stack, bounding context growth by call depth instead of total steps, and encodes multi-agent collaboration naturally as parallel function calls. A case study on GUI automation agents (OSWorld benchmark) demonstrates the approach substantially improves long sequence stability and task success with far fewer steps than state-of-the-art LLM-orchestrated methods.
Key findings
- LLM-as-Code achieves 86.8% overall success on OSWorld with max 15 steps vs 80.4% for best baseline using 100 steps (Table 1).
- Context length grows with call depth (O(depth)) in LLM-as-Code vs O(steps) in LLM-as-Orchestrator, preventing token explosion.
- Control-flow hallucinations (e.g., repeated or skipped steps) are eliminated by removing LLM control of loops and branches.
- Unreliable completion is resolved since deterministic program code governs sequencing, so steps cannot be probabilistically omitted.
- Multi-agent collaboration is implemented as parallel function calls on the DAG, avoiding shared context window bottlenecks.
- Self-programmed evolution lets LLM generate code functions that are tested and committed as deterministic steps, ensuring durable improvement.
- Empirical failure modes of existing orchestrator agents arise from fundamental category error, not prompt or model capability.
- Existing approaches (retry, constrained decoding, bigger context) only reduce but do not eliminate multi-step failure compounding.
Threat model
The threat model is implicit: the adversary corresponds to LLM probabilistic sampling errors leading to control-flow hallucination, token explosion, and unreliable completion when the LLM orchestrates workflow steps. The adversary capabilities encompass inherent model stochasticity causing per-step errors and compounding failures over long tasks. The model does not consider adversarial attacks in a security sense but rather failure modes from the probabilistic nature of LLM decision-making under task complexity and long horizons.
Methodology — deep read
The paper begins by formalizing the threat in current LLM agent designs: the LLM acts as the orchestrator deciding control flow steps by sampling token outputs. This delegation assigns inherently deterministic tasks (looping, branching, sequencing) to a probabilistic system, so correctness guarantees vanish, especially over long horizons (Section 2.1). The authors use a toy example fetching and summarizing 8 URLs to demonstrate that the LLM orchestrator sometimes skips or repeats steps due to sampling decisions.
They further detail the problem in two dimensions: unguaranteed compliance with constraints (like enforcing ordering rules) as decisions are sampled rather than programmed (Section 2.2), and context overload as the model must ingest the entire growing interaction history every turn (Section 2.3). Both cause compounding reliability degradation.
To solve this, they propose Agentic Programming (Section 3) where the workflow control lives in deterministic code. The LLM is invoked only for reasoning or generation subtasks, preserving full flexibility inside calls but unable to alter control paths. This design yields LLM-as-Code, a paradigm layering deterministic program flow (loops, branches) around stochastic LLM calls.
Key is the DAG-structured context representing call history as a call graph, not a flat conversation log. Active calls see their ancestor chain context only, bounding length by call depth. Completed calls return summaries, shrinking context size. This effectively prevents token explosion and preserves reasoning quality.
Multi-agent collaboration is implemented naturally by concurrent agent calls as sibling nodes in the DAG, whose results are merged deterministically to avoid unreliable merges. Self-programmed evolution is supported by letting LLM-generated code proposals be validated and committed as deterministic steps.
The authors provide a concrete case study on the OSWorld GUI automation benchmark where their LLM-as-Code agent outperforms previous SOTA agents in success rate and step efficiency, validating practical gains beyond theory.
Evaluation relies on established baselines from OSWorld leaderboard and internal tests; the paper reports success rates and max steps. No mention of code release or random seeds. Ablations include comparing context growth patterns and task stability.
Overall, the methodology carefully separates stochastic reasoning tasks from deterministic control and scaffolds a robust programmatic harness around the LLM to eliminate systemic failure modes observed in prior agent designs.
Technical innovations
- Formal identification of control-flow orchestration by LLMs as a fundamental architectural category error causing compounding reliability problems in long-horizon tasks.
- Agentic Programming paradigm where deterministic program code governs all control flow and the LLM functions as an adaptable component invoked only for probabilistic subtasks.
- Use of a DAG-structured context representing call graph history, bounding context growth by call depth and collapsing returned calls to summaries, preventing token explosion.
- Structuring multi-agent collaboration as parallel function calls in the DAG, avoiding shared context bottlenecks and enabling deterministic merging of results.
- Self-programmed evolution through LLM-generated functions tested and committed as durable deterministic code, enabling reliable iterative improvement.
Datasets
- OSWorld benchmark — task environment for GUI automation — public leaderboard accessed 2026-06-02
Baselines vs proposed
- Holo3-35B-A3B: Overall success = 80.4% with 100 max steps vs LLM-as-Code: 86.8% with 15 max steps
- OpenAPA w/ Gemini-3.1-pro: Overall success = 78.3% with 100 max steps vs LLM-as-Code: 86.8% with 15 max steps
- Claude Sonnet 4.6 (LLM-as-Orchestrator): Overall success = 72.1% with 100 max steps vs LLM-as-Code (Claude Sonnet 4.6): 86.8% with 15 max steps
Figures from the paper
Figures are reproduced from the source paper for academic discussion. Original copyright: the paper authors. See arXiv:2606.15874.
Fig 1: A comparison of the two agent paradigms on a simple multi-step task. In the left panel (LLM-as-Orchestrator) the
Limitations
- The approach assumes the agent’s workflow structure is known and can be encoded as a program; fully exploratory or open-ended tasks may still require LLM orchestration.
- The evaluation is limited to one case study domain (GUI automation on OSWorld); generalization to diverse agent tasks is not demonstrated.
- No in-depth adversarial testing or robustness evaluation against misbehaving or malicious LLM outputs was reported.
- The approach requires engineering effort to encode workflows as deterministic programs, potentially limiting ease of use vs orchestrator prompting.
- Code release and exact implementation details for reproduction are not clearly stated, limiting reproducibility.
- The impact of LLM model strength variations on performance within the new paradigm is unclear.
Open questions / follow-ons
- How well does the Agentic Programming paradigm generalize to other agent domains beyond GUI automation, e.g., multi-turn dialogue or robotic control?
- What are the tradeoffs in developer effort and flexibility when encoding more complex workflows as deterministic programs around LLM calls?
- Can LLM model improvements or prompt-engineering techniques further reduce errors within the reasoning calls in this paradigm?
- How to best automate or assist self-programmed evolution to efficiently discover and validate improved agentic functions?
Why it matters for bot defense
For bot-defense and CAPTCHA practitioners, the findings highlight a critical architectural pitfall in large language model agent design: entrusting probabilistic LLMs with deterministic control flow inherently leads to reliability and scalability issues. Applying Agentic Programming principles could improve the robustness of CAPTCHA-solving or bot-detection agents by ensuring workflow guarantees via code-controlled orchestration. Likewise, multi-agent coordination within a DAG context may help scale complex workflows without overwhelming prompt context limits or inducing error compounding. However, adopting this approach requires reformulating agent logic as explicit deterministic programs, which might trade off flexibility or speed. Therefore, CAPTCHA designers might selectively use LLM reasoning within deterministic harnesses rather than end-to-end LLM orchestration for critical verifiable tasks, helping prevent hallucination and incomplete runs in sensitive bot interactions. The paper’s emphasis on structural design over prompt fixes encourages a more disciplined agent engineering mindset in bot-defense applications.
Cite
@article{arxiv2606_15874,
title={ LLM-as-Code Agentic Programming for Agent Harness },
author={ Junjia Qi and Zichuan Fu and Jingtong Gao and Wenlin Zhang and Hanyu Yan and Xian Wu and Xiangyu Zhao },
journal={arXiv preprint arXiv:2606.15874},
year={ 2026 },
url={https://arxiv.org/abs/2606.15874}
}