Reliable Long-Horizon Agents Need a Control Stack, Not Just a Bigger Model

The September 4 AI cycle looks, at first glance, like another capability race. OpenAI is rolling out GPT-6 Astra with a 1.05-million-token context window. Alibaba says Qwen3.8-Max-0902 is better at engineering-scale coding, multi-agent collaboration, and long-horizon autonomous development. NVIDIA is acquiring Hugging Face, one of the central distribution layers for open models and datasets.

But four new research results point in a more useful direction for builders: model capability is only one layer of agent reliability. Production systems also need verified operational knowledge, explicit supervision policies, action-conditioned state prediction, and commitment tracking.

This article turns those results into a practical control architecture.

The capability fallacy

A common design assumption is that a sufficiently capable model will eventually absorb the responsibilities of the harness around it. Give the model more context, stronger reasoning, more tools, and a longer execution budget; then planning, monitoring, verification, and recovery should improve together.

The new evidence does not support that shortcut.

CivBench reports that agents operating for more than 300 turns often fail to query strategically relevant state and execute only 48.2% to 65.8% of commitments within the next ten turns. READY shows that two systems with almost identical autonomous accuracy can require materially different levels of human review to meet the same reliability target. DocHop shows that strong chart understanding does not guarantee reliable reasoning across narrative constraints and multiple charts. Repo-To-Skill shows large gains from adding distilled operational knowledge while holding the model backbone and execution budget fixed.

The implication is structural: capability, knowledge, supervision, monitoring, and evidence are separate control surfaces.

A five-layer control stack

A robust long-horizon agent can be organized into five layers:

1. Model layer — proposes interpretations, plans, and actions.
2. Operational-knowledge layer — supplies compact, versioned procedures relevant to the task.
3. Commitment layer — turns plans into explicit obligations with deadlines and observable completion criteria.
4. Prediction and verification layer — estimates action consequences and checks actual outputs against evidence.
5. Oversight layer — routes uncertain or high-risk cases to the least expensive policy that still meets the reliability target.

These layers should exchange typed state rather than relying on a single conversational transcript.

Task + policy
    ↓
Retrieve verified skills
    ↓
Create commitments with acceptance checks
    ↓
Propose candidate actions
    ↓
Predict and compare consequences
    ↓
Execute within authority boundary
    ↓
Collect evidence and reconcile commitments
    ↓
Accept, retry, escalate, or roll back

A larger context window helps the model see more of this state. It does not replace the state machine.

Layer 1: Treat the model as a proposer, not the source of truth

GPT-6 Astra and Qwen3.8-Max-0902 expand the capability envelope for long tasks. Their long contexts and tool ecosystems can reduce handoff loss and support larger working sets. However, the model should still produce proposals that are checked by the surrounding system.

The harness should own:

• permissions and tool scopes;
• durable task state;
• idempotency and concurrency control;
• acceptance criteria;
• evidence collection;
• retry budgets;
• escalation and rollback.

This division prevents an increase in reasoning capability from silently becoming an increase in authority.

GPT-6 Astra official model visual — source: OpenAI Developers.

Layer 2: Build a governed operational-knowledge supply chain

Repo-To-Skill identifies a missing layer between general model knowledge and successful execution: operational knowledge. Repositories and papers often contain the details required to make a method work, but they are too large and too diffuse to load for every task.

DisCo distills that material into compact skills. Its AREX-Skill library contains more than 5,000 verified skills distilled from 1,000 machine-learning repositories. Under a fixed GPT-5.5 backbone, harness, and execution budget, the skill-equipped system outperformed the no-skill baseline across MLE-bench, PaperBench, FrontierCS, and PassNet.

Figure 1: the Repo-To-Skill/DisCo pipeline — source: arXiv:2609.02749.

For production, the important pattern is not “automatically trust generated skills.” It is a governed supply chain:

Source repository or paper
    ↓ provenance
Candidate procedure
    ↓ sandbox evaluation
Verified skill version
    ↓ scoped retrieval
Observed production use
    ↓ regression monitoring
Keep, revise, quarantine, or revoke

Each skill should include:

• source and version provenance;
• the situations that trigger it;
• bounded steps with completion criteria;
• permissions required;
• tests or checks that justify promotion;
• known incompatibilities;
• owner, revision, and revocation state.

The retrieval system must also be conservative. A correct skill applied to the wrong task is still an execution bug.

Layer 3: Convert plans into commitments that can fail visibly

CivBench introduces a particularly useful metric: RAG@10, which measures whether commitments stated in planning reflections are executed within ten subsequent turns. Across the pilot runs, agents completed only 48.2% to 65.8% of those near-term commitments.

This reveals a difference between plan text and control state. A sentence such as “next I will verify the deployment” is easy to generate and easy to forget. A commitment record is harder to ignore:

{
  "id": "verify-production-route",
  "createdAtStep": 42,
  "dueByStep": 52,
  "requiredEvidence": [
    "HTTP 200 from production URL",
    "expected title present",
    "asset MIME type verified"
  ],
  "status": "open",
  "owner": "worker",
  "onMiss": "pause-and-escalate"
}

The runtime should reconcile open commitments after every meaningful action. If the deadline approaches without evidence, the system should surface the miss, not let a later summary rewrite history.

Useful metrics include:

• commitment completion within N steps;
• overdue commitment count;
• percentage closed with direct evidence;
• percentage silently dropped;
• plan-to-action latency;
• commitments invalidated by changed state.

This is the operational equivalent of testing whether an agent does what it says.

CivBench system architecture — source: arXiv:2609.02459.

Layer 4: Predict discriminative consequences, then verify reality

Web agents often choose among several actions that all look locally plausible. Discriminative World Models for Web Agents argues that conventional next-state prediction is misaligned with action ranking. A useful world model must distinguish the state caused by the selected action from states caused by alternatives.

Qualitative predicted-state matching figure — source: arXiv:2609.02885.

The paper's predicted-state matching objective provides a practical blueprint:

1. generate a small set of authorized candidate actions;
2. predict the consequential state for each action;
3. compare candidates using task progress, policy compliance, and reversibility;
4. execute one action;
5. compare the observed state with the prediction;
6. update confidence or stop when prediction error is too large.

The key design choice is to predict decision-relevant differences, not reconstruct every pixel or DOM node. For example, before clicking a web control, the agent may only need to predict:

• whether navigation will occur;
• whether unsaved work will be lost;
• whether the action creates an external side effect;
• which task milestone becomes satisfied;
• whether the action remains reversible.

After execution, verification must use observed state rather than the model's own narrative. Prediction assists selection; evidence determines acceptance.

Layer 5: Optimize the human–AI system, not autonomous accuracy

READY reframes enterprise evaluation. Instead of asking only whether an agent can complete a workflow, it asks what combination of agent and oversight policy meets a specified reliability target at minimum cost.

In its clinical-audit case study, two systems differed by only 0.3 percentage points in autonomous accuracy, yet required 39.2% versus 29.6% human review to qualify at the same 76% reliability target. That gap can dominate operational cost.

Figure 1: READY qualification workflow — source: arXiv:2609.02095.

An oversight router should therefore estimate at least:

• probability of task success;
• expected harm or recovery cost if wrong;
• review cost;
• reversibility;
• evidence completeness;
• distribution shift;
• policy sensitivity.

A simple routing policy might be:

Low risk + reversible + strong evidence      → auto-accept
Moderate uncertainty + cheap verification    → run verifier
High impact or weak evidence                  → human review
Policy violation or unknown authority         → block
Post-action mismatch                          → roll back and escalate

The target metric is not maximum autonomy. It is the least expensive operating point that satisfies the required reliability and safety constraints.

Document reasoning needs inspectable intermediate evidence

DocHop adds another lesson. Models may perform well on individual chart or document questions yet fail when text defines an entity and the answer requires aggregating values across multiple charts. Human accuracy exceeds 90% in the benchmark, while the best evaluated model reaches 62.83%.

DocHop teaser: multi-hop reasoning across documents and charts — source: arXiv:2609.02059.

For enterprise documents, the agent should not jump directly from a dense report to a fluent answer. It should produce an evidence table:

This structure allows deterministic checks for arithmetic, source alignment, and missing evidence. It also reduces the amount of reasoning a human reviewer must reconstruct.

An implementation blueprint

A production runtime can represent the control stack with a small set of typed records:

type TaskState = {
  taskId: string
  objective: string
  riskClass: "low" | "medium" | "high"
  authority: string[]
  skillVersions: string[]
  commitments: Commitment[]
  latestEvidence: Evidence[]
  revision: number
}

type Commitment = {
  id: string
  dueByStep: number
  acceptanceChecks: string[]
  status: "open" | "satisfied" | "invalidated" | "missed"
}

type Evidence = {
  claim: string
  source: string
  observedAt: string
  artifactHash?: string
  confidence: number
}

Then enforce six runtime invariants:

1. No action without authority. Tool availability does not imply permission.
2. No promoted skill without provenance and evaluation. Generated procedures remain candidates until verified.
3. No completed commitment without matching evidence. Narrative completion is not completion.
4. No irreversible action based only on predicted state. Observe prerequisites and use an approval gate.
5. No reliability claim from the same loop that produced the answer. Use held-out tests, deterministic checks, or independent review.
6. No retry without reading current state. Idempotency and revision checks prevent duplicate side effects.

What long context is actually good for

Long context remains valuable. It can hold more code, evidence, policy, and task history in one inference. But its best use is not replacing durable control state. It is giving the model a richer, carefully selected view of that state.

A million-token prompt without typed commitments can preserve a forgotten promise somewhere deep in the transcript. A commitment ledger makes the promise actionable. A long prompt without evidence boundaries can preserve many claims. An evidence graph shows which claims are actually supported. A long prompt without oversight routing can expose more sensitive information to a model. A policy-aware router decides whether the model should see or act on it at all.

Conclusion

The next generation of reliable agents will not be defined by model size alone. They will combine:

• frontier models as bounded proposers;
• verified skills as operational knowledge;
• explicit commitments as executable planning state;
• discriminative world models for action selection;
• direct evidence for acceptance;
• cost-aware human oversight for deployment qualification.

The most important shift is conceptual: stop treating an agent as a long conversation that occasionally calls tools. Treat it as a controlled system whose plans, permissions, predictions, actions, and evidence remain independently inspectable.

That is how stronger models become safer and more useful systems—without asking the model to grade its own homework.

Sources

• GPT-6 Astra model documentation — OpenAI
• Qwen3.8-Max-0902 — Qwen Cloud
• Repo-To-Skill — arXiv:2609.02749
• READY — arXiv:2609.02095
• Discriminative World Models for Web Agents — arXiv:2609.02885
• CivBench — arXiv:2609.02459
• DocHop — arXiv:2609.02059