IO LABResearch program ↗
ENRU
← All directionsWORKING PAPER / 001
IO / SYSTEMv0.2 · 08 SEP 2026Working edition · not peer reviewed

Cognitive Autopilot

A model-agnostic runtime for verified action

IO Lab · Independent AI systems researchArchitecture · dated offline evidence
Read the paper ↓Explore the mechanism ↗

00 / ABSTRACT

The unit of success is a verified change in the world.

Cognitive Autopilot treats intelligence as an outcome of a controlled system rather than a property of one model. It receives a goal, maintains explicit task state, compiles a role-specific working context, bounds an action, and checks the resulting evidence before continuing. Foundation models remain replaceable components inside a stable goal-to-outcome contract.

This working paper describes the control loop, context and authority boundaries, recovery semantics and an evaluation design for measuring orchestration uplift. Internal provider-free checks support selected mechanical contracts. They do not establish improved reasoning, live task success or equivalence to a stronger model. The principal contribution is a testable system design.

Contributions of this edition

  1. A stable goal-to-outcome contract with explicit task state and acceptance obligations.
  2. A bounded invocation model separating context, model decisions, authority and observed effects.
  3. A paired evaluation protocol that distinguishes real task success from false acceptance.
FIGURE 01 · MECHANISMConceptual model
Cognitive Autopilot execution and verification loopA goal is interpreted, a context capsule is compiled, an action is executed under a grant, and evidence returns to the state reducer. Verification controls continuation; the model’s completion message is not itself acceptance. 01Goal02Think03Context04Act05Verify
A goal is interpreted, a context capsule is compiled, an action is executed under a grant, and evidence returns to the state reducer. Verification controls continuation; the model’s completion message is not itself acceptance.
  1. 01

    Fix acceptance, budget and authority.

  2. 02

    Choose the next verifiable step.

  3. 03

    Compile a role-specific capsule.

  4. 04

    Execute and capture the world delta.

  5. 05

    Accept, repair, replan or stop.

01 / PROBLEM

A capable model can still receive an inadequate working environment.

In a long task, the goal, evidence, permissions and remaining work change at different speeds. A transcript mixes all of them with speculative ideas, obsolete observations and intermediate outputs. If each invocation must reconstruct the entire task, a failure in state management can look like a failure in reasoning.

For example, a coding agent may report success because a command exited normally even though the required artifact was never produced. Conversely, a useful artifact may exist while a summary claims failure. The runtime needs an explicit account of what was requested, what changed and which observations support completion.

02 / HYPOTHESIS

Measure what the surrounding system contributes.

The experimental hypothesis is that explicit control, compiled context and independent checks improve accepted outcomes for a fixed model under a shared resource envelope. The counterfactual is the same model given the same task, permitted tools and total budget without the proposed orchestration.

ΔQ = (1 / N) Σᵢ [Yᵢ(Autopilot) − Yᵢ(direct)](1)
Paired outcome difference. Y is independently adjudicated task success, not the runtime’s own verdict. The task set, budgets, model settings and stopping rules must be fixed before evaluation.

03 / ARCHITECTURE

One authoritative state. Temporary execution roles.

TaskState records the interpreted goal, acceptance criteria, current plan, milestones, evidence references, budgets and lifecycle status. A deterministic reducer is the only component allowed to commit a transition. Models propose structured actions and assessments; they do not silently rewrite canonical state.

Roles describe responsibilities rather than permanent processes. A simple task may use one Thinker invocation, one Doer and a verifier. More roles are introduced only when a specific ambiguity or evidence gap justifies their cost.

Table 1. Responsibility and authority boundaries
ComponentResponsibilityBoundary
Thinker / NavigatorInterpret the goal; choose a step; review the remaining plan after a milestone.May propose KEEP, PATCH, REPLAN or a user decision; cannot create authority.
Context EngineRetrieve candidates, read exact sources and compile a role-specific view.A search hit is a pointer, not canonical evidence.
Doer + HarnessExecute a scoped action and record observable effects.Tool access is bounded by an explicit grant and the environment.
VerifierEvaluate each criterion from evidence and classify failures.Cannot treat a self-report as an independent observation.
Reducer / Goal GateCommit valid transitions and determine whole-goal completion.A completed step does not imply that all goal obligations are satisfied.

04 / MODEL

A capsule is a contract for one invocation.

Kₜ = (gₜ, rₜ, cₜ, mₜ, Aₜ, bₜ, oₜ, vₜ)(2)
Capsule fields: goal slice g, role r, context c, model/session m, authorized actions A, budget b, output schema o and verification rule v. The tuple is a descriptive system model.
Sₜ₊₁ = Reduce(Sₜ, eventₜ, receiptₜ)(3)
A transition is accepted only if its preconditions, evidence references and authority checks hold. An invalid or incomplete event leaves the relevant completion obligation open.

The verifier assigns pass, fail or unknown to each required criterion. Unknown is not a softer pass: it records insufficient observation. A failed mandatory criterion rejects the step; an unknown mandatory criterion prevents completion. Acceptance additionally requires valid authority and evidence integrity.

This distinction is useful when evidence is partial. A unit test may pass while a live service check is unavailable. The artifact can be retained, but the unresolved live obligation remains visible instead of being converted into confidence.

FIGURE 02 · VERIFICATIONIllustrative scenario

When can a step be accepted?

Change the criteria. “Unknown” keeps an obligation open. This demonstrates acceptance logic, not the performance of a real model.

INCOMPLETE · verification evidence is missing

05 / CONTEXT COMPILATION

The smallest sufficient view must still be sufficient.

The compiler begins with the next acceptance slice and role, then obtains the needed observations from allowed sources. It records source identity, revision or observation time, extraction scope and the reason each item is included. Summaries and indexes may locate material; critical claims require an exact source read.

A capsule contains the objective, current constraints, relevant state, source-backed facts, allowed tools, one directive and an output contract. Contradictory sources should remain marked as a conflict until resolved. Compression that erases the conflict is a semantic failure even if it saves tokens.

Table 2. Role-specific context
RoleMinimum useful viewUsually excluded
ThinkerGoal, acceptance, current plan, blockers and available capabilities.Full tool logs unrelated to the decision.
DoerOne action, exact targets, relevant source content and grant.Other roles’ speculative plans that do not affect the action.
VerifierOriginal criteria, artifact, receipts and independently observable delta.Persuasive success claims without supporting evidence.

Minimality is an optimization target, not a fact inferred from a short prompt. It must be assessed by ablation: remove or add context under a fixed budget and observe whether independently graded outcomes change.

06 / EXECUTION & RECOVERY

Observe effects before deciding what to retry.

The Harness computes effective authority from the intersection of user-granted scope, task policy and environment capabilities. A generated plan cannot expand that intersection. The result of an action is a receipt tied to the invocation and observed delta, not an unrestricted narrative of success.

Before an external side effect, the runtime records the intended action. After execution, it records available receipts and commits the transition. If a crash occurs between the side effect and its checkpoint, recovery first checks whether the action already happened. Blind repetition is unsafe for non-idempotent operations.

The state log can support deterministic transition replay. That is weaker than exactly-once execution in an external system: an external service must expose an idempotency key or a reliable reconciliation mechanism. When its state cannot be resolved, stop with an explicit unknown.

08 / EVIDENCE SCOPE

Mechanical checks are narrower than model quality.

Table 3. Internal evidence recorded in the July 2026 working edition
EvidenceSupported scopeUnresolved scope
Provider-free runtime checksReducer, checkpoints, replay and selected recovery windows.Plan quality and real external side effects.
Context / authority checksRole views, exact-read manifests, scoped grants and receipt validation.Optimal retrieval, adversarial robustness and live tool completeness.
Agent-host checksStructured decoding, session boundaries, default-deny launch and postflight.Live provider quality, end-to-end success and model-routing gains.

These are dated, internally reported checks, not a fresh live audit in this edition. The source repository remains private. This is a working paper rather than a publicly reproducible technical report. A corrected end-to-end Autopilot run and comparative live trials were still open in the cited evidence snapshot.

09 / NEXT EXPERIMENT

A paired comparison with an independent judge.

Start with one frozen software task to validate the protocol, then a held-out task set large enough to estimate a useful effect. Give both conditions isolated copies of the same starting workspace, identical criteria, permitted tools and a shared total resource envelope. Account for every Thinker, Doer, verifier and repair call in the Autopilot condition.

Randomize condition order and record exact model versions, seeds when available, all stopping events and exclusions. The evaluator should inspect final artifacts without knowing the condition. Use executable criteria where possible and a prewritten human rubric for the remainder.

Table 4. Report the full outcome, including the denominator
MetricDefinition
Task successIndependently accepted tasks / all assigned tasks. Report unknowns separately.
False acceptanceIncorrect tasks declared complete / all tasks declared complete; undefined when none are declared complete. Also report the count.
Human repairAdditional interventions and time needed to make the output acceptable.
OverheadTotal cost, wall time and resource consumption, including verification and failed attempts.
Paired upliftWithin-task success difference with task-level confidence intervals.

Ablate context compilation, milestone planning and independent verification separately. Resample at the task level rather than treating repeated runs of the same task as independent observations. Freeze practical-effect thresholds before evaluation; a point estimate alone is not sufficient for promotion.

10 / LIMITATIONS

The strongest unresolved claim is the central one.

  • No live orchestration uplift is established by this edition.
  • A shared model can produce correlated Doer and Verifier errors; role separation alone does not guarantee statistical independence.
  • Incomplete observability and weak acceptance criteria limit the Goal Gate.
  • More control can add latency, cost and additional failure modes.
  • Prompt injection, adversarial tools and distributed side effects need dedicated threat-model evaluations.
  • The ≥90% frontier-quality figure is a research target for a specified system and task distribution, not a measured result.

Fresh knowledge, permissions, runtime checks and recovery remain external responsibilities even if future training improves the model’s action policy. A useful runtime should remain functional without a swarm or a teacher model.

SOURCES

References & intellectual context

These works provide intellectual context and comparison methods. Their results are not experimental evidence for IO Lab’s hypotheses.

  1. Yao, S. et al.ReAct: Synergizing Reasoning and Acting in Language Models 2023 · ICLR
  2. Shinn, N. et al.Reflexion: Language Agents with Verbal Reinforcement Learning 2023 · arXiv preprint
  3. Lewis, P. et al.Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks 2020 · NeurIPS

CITE THIS WORK

Citation & edition

Version 0.2 expands architecture, formal notation, failure semantics and the evaluation protocol. It preserves the July 2026 evidence boundary and introduces no new live-quality result.

IO Lab. “Cognitive Autopilot: A Model-Agnostic Runtime for Verified Action.” IO Lab Working Paper 001, version 0.2, September 8, 2026. https://io-lab.nglain.com/works/cognitive-autopilot
BibTeX
@techreport{iolab2026autopilot,
  author = {{IO Lab}},
  title = {Cognitive Autopilot: A Model-Agnostic Runtime for Verified Action},
  institution = {IO Lab},
  type = {Working Paper},
  number = {001},
  year = {2026},
  month = {September},
  note = {Version 0.2; not peer reviewed},
  url = {https://io-lab.nglain.com/works/cognitive-autopilot}
}

Availability: the full text of this edition is public. The internal repository, raw traces and datasets are not published. No DOI has been assigned.