HiOS: A Device-Specific Agent Framework for Intent Graph Execution

Abstract

An agent procedure can remain semantically valid while becoming ineligible on the device that must execute it. HiOS specifies a device-specific agent framework that separates a portable intent graph from a plan bound to supported tools, model interfaces, adapter schemas, authorized scope, and verification contracts. Its proposed runtime rechecks compatibility and current eligibility before inference, action, and resumption. iOS provides the motivating application context. A Python reference implements receipt binding, reasoning-route guards, and a send guard across a simulated checkpoint boundary for synthetic API and foreground-web adapters. Across 27 author-selected scenarios, it matches the declared terminal statuses: 11 complete, ten pending, and six other outcomes. It makes zero fixture-refused attempts, compared with 16 for a bind-once control. The guards and analyzer share the fixture's admission rules, so this contrast is a rule-consistency check, not independent validation of those rules. Separate, uncomposed studies check all 65,536 four-node directed graphs in extracted native code and enumerate 756 recovery conditions across three policies and three query budgets, yielding 6,804 traces. These results establish bounded component behavior, not end-to-end agent accuracy or physical resource savings. Native integration, real-model comparisons, and device-specific cost calibration remain necessary to test whether explicit device compatibility lowers all-attempt inference expenditure at matched success.

Preserve intent. Adapt execution to the device.

The proposed framework separates the user’s goal, arguments, dependencies, and verification obligations from a plan bound to supported adapters, interface versions, and authorized scope. It calls for compatibility and eligibility checks before inference, actions, and resumption.

1. 01 / UNDERSTANDUser intentionResolve the goal and missing information.
2. 02 / SPECIALIZEDevice-bound planBind current arguments, adapters, and compatibility checks.
3. 03 / EXECUTEEligible executionRecheck resources, permissions, and reachable services.
4. 04 / VERIFYVerified progressPreserve completed work and reconcile uncertain effects.

Proposed framework flow, not a measured execution trace. The synthetic Python reference is separate from the native HiOS app.

The reference has a narrower scope: receipt binding, reasoning-route checks, and a send check after a simulated checkpoint boundary. Its archive write has no corresponding runtime admission guard. The checkpoint reloads a binding through JSON while retaining the fixture in memory; it does not demonstrate operating-system restart recovery or later continuation from a pending outcome.

The central question is which parts of a resolved procedure remain valid as a device’s capabilities and conditions change. A subsequent real-model study must test whether maintaining that validity reduces all-attempt inference expenditure at matched task success.

Component evidence and its limits

The Python reference runs 27 author-selected scenarios across four synthetic profiles and three diagnostic policies, producing 81 traces. The device-contract policy matches all declared terminal statuses: 11 complete, ten pending, three handoff, one infeasible, one clarification, and one deadline failure. It makes zero fixture-refused attempts, compared with 16 for bind-once.

The guards re-implement the fixture’s admission rules, and the analyzer imports the same admission function. Runtime completion consults the fixture’s goal predicate, so zero false-success declarations are structurally constrained. These results check rule consistency and guard placement on the selected inputs; they do not independently establish that the rules are correct or complete. The controls omit checks and rebinding, so the contrast establishes no advantage over capable replanning.

The scenario appendix lists every profile, injected change and stage, expected status, observed policy outcome, and refused-attempt type. It also explains that the expected statuses were authored with the cases, without an independently timestamped protocol establishing that they preceded policy development.

A separate study checks extracted native graph code over all 65,536 four-node directed graphs and 8,688 readiness states on macOS and iOS Simulator, using a different graph algorithm as the oracle. Targeted probes exposed duplicate-ID and completion-tracking defects; after repair, all five probes passed on both platforms. This is bounded structural verification, not validation of the full executor or the Python reference.

The separate recovery fixture crosses 14 write conditions, six observation schedules, three idempotency contracts, and three restart boundaries: 756 conditions per policy and query budget. Three policies at three query budgets produced 6,804 traces. These are constructed conditions and nested sensitivity runs, not independent real-user tasks.

With three queries, reconciliation verified 174/756 cases (23.0%), left 474 pending, and detected 108 failures, with zero unsafe successes or duplicate effects under the fixture’s explicit settlement signal. A snapshot-checking control verified 166 cases but produced 18 duplicate-effect cases. At six queries, reconciliation verified 348/756 (46.0%), while total dispatches plus queries rose from 2,853 to 4,002. The findings depend on the declared service semantics and do not demonstrate inference or energy savings.

Version 0.7 clarifies predicate sharing, checkpoint and guard scope, metrics, and the separation of the three studies. It adds the complete scenario inventory and reproduction commands. The recorded experiment outcomes are unchanged.

Source and verification supplement

The 36-page manuscript includes 8 figures. The source ZIP contains the LaTeX manuscript and its supplement. The verification ZIP includes the component code, synthetic scenarios, raw traces, scenario inventory, and reproduction instructions.

These files accompany the component study. They do not release the native application repository or its history. Inherited Swift snapshots retain their MIT notice; distribution does not assert a new general-purpose reuse license for the research code.

Cite this research

Tian, Jiahe. 2026. HiOS: A Device-Specific Agent Framework for Intent Graph Execution. HiOS Labs Inc. Research. Version 0.7.

@misc{tian2026hiosintentgraphs,
  author = {Tian, Jiahe},
  title = {HiOS: A Device-Specific Agent Framework for Intent Graph Execution},
  year = {2026},
  month = oct,
  note = {HiOS Labs Inc. Research. Version 0.7. Not peer reviewed},
  url = {https://hios.app/research/intent-graph-runtime/}
}

Versioned PDFs: Version 0.7 · Version 0.6 · Version 0.5 · Version 0.4 · Version 0.3 · Version 0.2.

The manuscript discloses AI assistance in prose, methods, code, analysis and preparation, including a model-assisted review. That review is not independent human peer review. The author is affiliated with HiOS Labs Inc., the company associated with the project. This research has no assigned DOI and has not undergone peer review.