AI-Native Quest Operating Systems: Persistent Goals Across Apps and Devices
An AI-native quest operating system treats goals, milestones, dependencies, evidence, permissions, and progress as persistent objects that can survive across applications and devices.
Persistent goals need a state model outside the conversation
OpenAI’s state guidance treats run history, resumable snapshots, interruptions, and continuation surfaces as first-class parts of an agent workflow.[1] A quest operating system extends that idea beyond one agent run. The goal itself becomes durable state with milestones, dependencies, evidence of completion, blocked reasons, and user-authored constraints. A phone, desktop agent, work tool, or wearable can all refer to the same goal object without relying on one chat transcript as the only record of truth.
The quest is an object, not a conversation theme
Conversation can interpret and negotiate the goal, but state should preserve what was actually agreed and completed.
Long-running work needs harnesses that preserve handoff artifacts
Anthropic’s work on long-running agent harnesses shows that context compaction alone is not sufficient; agents need structured artifacts and progress-preserving mechanisms to continue reliably across long horizons.[2] A quest OS should therefore store plans, checkpoints, recent decisions, unresolved questions, and receipts outside the immediate context window. When a session resumes, the agent reconstructs the relevant view from those artifacts rather than summarizing from memory every time.
A2A-style task objects point toward cross-agent quest interoperability
Google’s A2A protocol centers collaboration on stateful tasks with lifecycles, messages, status updates, and artifacts.[3] That maps closely to persistent quests. A user’s travel-planning quest might delegate one task to a booking specialist and another to a calendar agent while the top-level goal remains coherent. Interoperability becomes more useful when agents exchange bounded task state rather than free-form narratives about what they think the user wants.
Task status should be machine-readable and user-readable
“Waiting for approval,” “blocked,” “complete,” and “needs clarification” are more useful than an ambiguous conversational pause.
MCP-style primitives can connect the quest to tools without collapsing state and action
MCP distinguishes contextual resources from executable tools.[4] A quest object can be exposed as a resource while actions such as “mark milestone complete,” “schedule next step,” or “share progress” remain explicit tools. This protects integrity: reading progress is not the same permission as editing it. Cross-app systems need that distinction because otherwise any connected agent that sees a goal could accidentally redefine it.
The harness should enforce quest invariants across surfaces
OpenAI’s harness-engineering work emphasizes making architecture, tools, rules, and feedback loops legible and enforceable for agents.[5] A quest OS needs invariants such as unique milestone identifiers, monotonic evidence logs, explicit reopen reasons, permissioned reward issuance, and user-controlled cancellation. These rules allow many interfaces and agents to participate without turning the goal into inconsistent local copies.
One source of truth, many views
Different apps can render the quest differently, but they should reference the same authoritative state and event history.
Cross-device persistence must not become omnipresent nudging
A shared goal can follow the user everywhere without demanding attention everywhere. The quest OS should separate persistence from interruption. A goal can be visible on phone, laptop, and wearable while notification rights remain channel-specific and user-controlled. State should travel more freely than pressure. This prevents “persistent motivation” from becoming cross-device harassment.
Evidence-based completion prevents progress inflation
Milestones should record what verifies completion: a submitted artifact, a calendar event attended, a test passed, a document approved, or explicit user confirmation. AI can infer likely progress, but inferred progress should be labeled and reversible. This makes the system trustworthy when multiple agents contribute.
A percentage should have provenance
Users should be able to ask why the quest is 70% complete and receive an answer based on actual milestone state rather than model intuition.
A quest operating system makes goals portable without making them ownerless
The long-term opportunity is a user-owned layer where goals can persist across products while each agent contributes within bounded authority. Portability should not mean every service can inspect or modify everything. The user decides which goal is shared, which fields travel, which actions are allowed, and when the quest ends. With that governance, persistent goals can become genuine infrastructure rather than another platform mechanism for maximizing engagement.
Quest operating systems also need explicit conflict resolution because goals can compete for the same time, money, attention, or physical capacity. A fitness goal may collide with recovery, a work deadline with family time, or a savings target with a planned purchase. The OS should not allow whichever agent speaks last to win. It can represent priorities, hard constraints, negotiated tradeoffs, and temporary overrides as shared state. When conflicts emerge, the system can surface them to the user instead of silently reshuffling commitments. This preserves agency and makes cross-app coordination intelligible. A persistent goal layer is useful not because it centralizes every decision, but because it gives different agents a common place to discover when their local optimization would damage another part of the user’s life.
Portability also requires export and exit. Users should be able to take goal definitions, milestone history, and selected preferences to another service without carrying opaque vendor-specific scores that cannot be interpreted elsewhere.
Works Cited
- 01OpenAI Developers — Results and State developers.openai.com
- 02Anthropic — Effective Harnesses for Long-Running Agents anthropic.com
- 03Google Developers Blog — Announcing the Agent2Agent Protocol developers.googleblog.com
- 04Model Context Protocol — Server Primitives: Prompts, Resources, and Tools modelcontextprotocol.io
- 05
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.