Paper deep dive
We Query, Therefore We Compute: On Oracle Computation beyond the Machine, with an Application to Agents
Kefan Liu, Fengning Ou, Yelin Luo, Jingdi Lei
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 93%
Last extracted: 10/8/2026, 7:23:16 AM
Summary
The paper introduces O-2-PDA-TS, an abstract machine that unifies Agentic Systems and Workflows by treating Large Language Models (LLMs) as Oracles within a two-stack pushdown automaton. It employs two symmetry breakings (Storage and Transitions) to define a Priestess operating system that manages Oracle tasks. The authors propose ArchNights, an extended RISC-V ISA and Linux-style OS implementing this machine, demonstrated via ArchNights-SE on gem5.
Entities (12)
Relation Signals (9)
O-2-PDA-TS ā consistsof ā Priestess
confidence 95% Ā· The machine thus performs two computations, the Oracle's and a Turing-complete one that we call the Priestess.
O-2-PDA-TS ā consistsof ā Oracle
confidence 95% Ā· We treat the LLM as an Oracle and extend a two-stack pushdown automaton...
ArchNights ā implements ā O-2-PDA-TS
confidence 95% Ā· ArchNights implements the machine by design
ArchNights ā isbasedon ā RISC-V
confidence 95% Ā· we propose ArchNights: an extended RISC-V ISA
ArchNights-SE ā runson ā gem5
confidence 95% Ā· ArchNights-SE runs on gem5 as a computer system
Agent ā isplacementof ā O-2-PDA-TS
confidence 90% Ā· produce the Agent and the Workflow as the two placements of a task's program.
Workflow ā isplacementof ā O-2-PDA-TS
confidence 90% Ā· produce the Agent and the Workflow as the two placements of a task's program.
O-2-PDA-TS ā utilizes ā S symmetry breaking
confidence 90% Ā· Two symmetry breakings, S in storage and T in transitions, make a Priestess program the operating system
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Agentic systems use large language models (LLMs) to carry out concrete tasks. Prior work often borrows abstractions such as scheduling, caching or isolation piecemeal from operating systems, so the mechanisms it builds share little common ground, and the shared view of the two forms of agentic system, Workflows and Agents, is limited. We construct an abstract machine that provides both. We treat the LLM as an Oracle and extend a two-stack pushdown automaton with one instruction, which hands the Oracle a whole stack as its query and appends the answer to that same stack. The machine thus performs two computations, the Oracle's and a Turing-complete one that we call the Priestess. A stack that the program only appends to grows autoregressively, as an agent's context does. Two symmetry breakings, S in storage and T in transitions, make a Priestess program the operating system of the programs the Oracle runs, and produce the Agent and the Workflow as the two placements of a task's program. For internally autoregressive Oracles, the two computations synchronize at the end of every answer under certain conditions, and through that synchronization we model caching and analyse scheduling. No guarantee that holds for every Oracle can fix which content crosses between the two computations, but such a guarantee does fix the boundary itself. The construction V fits the machine to a von Neumann computer. To show that it is realizable, we propose ArchNights, an extended RISC-V ISA and a Linux-style operating system implementing the machine by design. ArchNights-SE runs on gem5 as a computer system, becomes an agentic system when it runs an LLM as the Oracle, and will be open source. Agentic systems can then be designed as computer systems are. With a foundation built and a unified view, future work can share invariants and bounds, each with its conditions.
Tags
Links
- Source: https://arxiv.org/abs/2610.09243v1
- Canonical: https://arxiv.org/abs/2610.09243v1
Trouble viewing inline? Open PDF directly ā
Full Text
458,576 characters extracted from source content.
Expand or collapse full text
We Query, Therefore We Compute: On Oracle Computation beyond the Machine, with an Application to Agents Kefan Liu1,2 Fengning Ou3 Yelin Luo2,4 Jingdi Lei5 1Institute of Computing Technology, CAS 2University of Chinese Academy of Sciences 3Nanjing University 4Institute of Automation, CAS 5Nanyang Technological University Kefan.Liu@outlook.com reverymoon@gmail.com Yelin_Luo@outlook.com jingdi001@e.ntu.edu.sg Extended Abstract Agentic systems use large language models (LLMs) to carry out concrete tasks. Prior work often borrows abstractions such as scheduling, caching or isolation piecemeal from operating systems. An analogy reaches only as far as what it borrows, so the mechanisms share little common ground on which to state or compare them. Moreover, agentic systems appear in two forms, Workflows and Agents, and the shared view that subsumes them is limited. We thus construct an abstract machine that provides this common ground and a unified view. We treat the LLM as an Oracle and extend a two-stack pushdown automaton with an instruction that queries the Oracle with a whole stack and appends the answer to that same stack. The machine thus performs two computations: the Oracleās, and a Turing-complete one that we call the Priestess. For the Oracleās computation, a stack that the program only appends to grows autoregressively, as an agentās context does. We then colour the two stacks, type the machine with call-by-push-value, give it two modes and break its symmetry in storage and in transitions. The storage (S) symmetry breaking makes the Oracle execute a program only in the Oracle colour, while content stays data in the Priestess colour. Under T, the Oracle mode can switch to the Priestess mode only at a fixed entry. Together they make the O-2-PDA-TS, on which a Priestess program is the operating system of the programs the Oracle runs. On this machine, when an LLM is the Oracle, a task whose program runs on the Oracle is an Agent. When the taskās program is placed differently, we find the Agent and Workflow forms on this machine. At this point the machine is defined and the operating system is derived, but what invariants hold between the Oracle and the Priestess remains open. We then study Oracles that are autoregressive inside, and link their one-step transitions to the machineās history through the encoder and decoder of the Oracle. The two computations synchronize at the end of every answer that yields, and through that synchronization we model caching and analyse scheduling behaviour, once for both forms. We further analyse the boundary between the Oracle and the Priestess and find that no guarantee that holds for every Oracle can fix which content crosses, but that such a guarantee does fix the boundary itself. To build a practical machine, we first ask which Oracle can be part of it, and then analyse how to fit the Oracle into the Priestess. The answers to these questions are the construction V, which fits the O-2-PDA-TS to a von Neumann computer. To show that the machine is realizable, we propose ArchNights: an extended RISC-V ISA and a Linux-style operating system. Accordingly, when it runs an LLM as the Oracle, ArchNights becomes an agentic system. ArchNights implements the machine by design, and we implement ArchNights-SE, in gem5ās syscall-emulation mode, as a computer system. ArchNights-SE will be open source. We further discuss ArchNights-FS, which is designed to run on real hardware. On this machine, agentic systems can be designed as computer systems are. With a foundation built and a unified view, future work can share invariants and bounds, each under the conditions it states. 1 Introduction Agents predate language models [1, 2], but only large language models [3] gave them a practical executor for open-ended tasks, and the abilities of these models as agents have grown quickly since then [4]. Agents are now used in real work, such as writing software [5]. How well, and at what cost, a model carries out a task also depends on the harness that runs it, the program that gives the model its context and tools, and acts on its answers [6]. With its scaffolding, a model has come to be viewed as a computer [7], and the harness has become a system in its own right. We follow the terminology of Building Effective Agents [8], which distinguishes Workflows from Agents by how control is organized: in a Workflow, model and tool calls follow predefined code paths, and in an Agent, the model dynamically determines its actions and tool use. Workflow engines such as n8n, Dify and Coze execute models or other computations at nodes of an orchestration, while systems such as Claude Code, Codex, Pi Agent and DeepSeek Harness repeatedly invoke a model, dispatch its tool calls and return their results as the task proceeds [9, 10, 11, 12, 13, 14, 15]. In practice, the two forms are increasingly composed. A Workflow node may run an Agent, while an Agent may use task modes that impose workflow-like structure, such as drafting a plan before execution. We call a system that runs Agents an Agent harness, and one that runs Workflows a Workflow engine; Appendix A defines these and the other terms used in the paper. 1.1 Two Clouds over Agentic Systems As agentic systems multiply, their study is becoming systematic. Where is the security boundary of a model? What is the cache of an agent? What separates a personās output from a modelās? Such questions arise whenever a concrete problem is analysed, and prior work has answered many of them, each from its own perspective. Take the cache as an example. For those who build agents, the cache is the context a program keeps and reuses; for those who serve models, it is the modelās attention state, its KV cache [16, 17, 18]. Both are right and have solved real-world problems, yet few works examine their foundations or the relation between the two views. Work on agentic systems abounds (Ā§7), new solutions appear, and harnesses are revised from day to day. Research on agentic systems is growing, yet is at present obscured by two clouds. The first cloud: foundations. On foundations, the research goes in two directions. One is formal: calculi and languages that give agent programs a semantics and prove what they cannot do, such as Ī»A _A [19], ZipperGen [20], LLMbda [21] and the Calculus of Intelligence [22], as well as rule languages enforced at run time, such as AgentSpec [23]. The other is structural: designs and systems built by analogy with operating systems, such as AIOS [24], the AgentOS papers [25, 26] and the AOS papers [27, 28]. Quine takes one abstraction further, realizing agents as POSIX processes that the hostās kernel isolates [29]; its operating system is the hostās and stands between processes. Both directions have produced real results: a lint for agent configurations [19], a verified interpreter that is itself a harness [21], and runtimes in use. Yet the formal works define languages, and none states what makes one part of an agentic system the operating system of another, or what that part guarantees. An analogyās theory reaches only as far as the analogy, and a new question needs a new analogy before it can even be asked, so the mechanisms built on analogies share little common ground on which they can be stated and checked. The two views of the cache are one example: each is stated in its own sideās terms, with no ground common to both. The second cloud: unification. Work on Workflows and Agents usually starts from one of the two. FMOS states the problem and treats workflows and agentic loops as two execution forms over shared primitives, with guarantees under a virtualization condition assumed at its interface [30]. Harness as a Language derives both from one primitive of a language, and defines no operating system [31]. A concrete mechanism is still built in one form and studied apart from its counterpart in the other. The cache is one example. One line of work decides what to do with the state of an agentās task while its tool call runs [32, 33]; another decides which prefixes of a workflowās steps to keep or prefetch, by how soon each will run [34]. On one machine both target the same interval, between two calls that share a prefix, in the Agent form and in the Workflow form (Appendix E.3). āThis duplication of work is tiresome. Furthermore, it makes the [systems] involved seem inherently arbitrary. We would prefer to study a single, canonical [system]ā [35, Ā§1.2.1], where āsystemsā replaces Levyās ālanguagesā, one that subsumes both forms. Ā§3 shows that one does. Beyond the two clouds. The third question, what separates a personās output from a modelās, asks for what neither cloud names: invariant properties or bounds that hold no matter who or what answers the queries, a language model or a person. On the machine a person and a language model are alike as the source of answers, provided a semantics can be defined for parsing the personās words. What separates their outputs is how each is called (Ā§5). None of the three questions is asked for its own sake. Their answers let future work design agentic systems as computer systems are designed, with each design choice argued from the theories or the experience of computer systems. Ā§6 designs ArchNights in this way. 1.2 One Instruction, Two Symmetry Breakings Our solution rests on two methods. Relativization separates the language model from the rest of the computation as a black-box Oracle and makes their interaction a machine. Symmetry breaking makes one part of that machine the operating system of the other. Two further steps extend the machine to the questions of the field and to hardware: opening the Oracle by one step, and realizing the machine on a von Neumann computer. Figure 1 follows one agent session through the construction, and Figure 2 shows the whole of it. 1declarationfile_read, file_patch, run, ā¦ ā® 2userfix the typo in notes.txt ā® 3answerfile_read(notes.txt) ā® 4reply"# notes / - prepare teh meeting agenda" ā® 5answerfile_patch(notes.txt, teh ā ā the) ā® 6replydone ā® 7answerFixed: teh ā ā the. ā® task stack (an Oracle stack)Q0Q_0Q1Q_1Q2Q_2r0r_0p0p_0r1r_1p1p_1r2r_2Qt+1=Qtā rtā ptQ_t+1=Q_tĀ· r_tĀ· p_t(a) a stack thatonly grows (Ā§2)forceto x1x_1forceto x2x_2returnservefile_readservefile_patchyield: trap to ātrap _trapreply, then uretthe task in O-modethe kernel in P-mode(b) a program theOracle runs (Ā§3)prefillprefilldecodeprefilldecodeprefilldecode(c) a cache alongthe prefix chain (Ā§4)written bythe Priestess (the kernel)the Oracle (the model)ā® the yield symbol Figure 1: One history, three readings. A session in which an agent fixes a typo, as the records of one task stack. The Priestess (the kernel) writes the blue records and the Oracle (the model) writes the amber ones. Each record ends with the yield symbol ā® . All of them lie on one Oracle stack and so have colour O (Definition 2.3), and blue and amber show only who wrote them. (a) As a stack (Ā§2): each query is the whole history so far, and the next query extends it by the Oracleās answer rtr_t and the kernelās reply ptp_t, so the history grows autoregressively (Proposition 2.7). (b) As a program (Ā§3): an answer that ends with ā® traps to the one service entry ātrap _trap, and the kernel serves the request in P-mode and appends its reply before it re-enters the task with uret. In call-by-push-value, the history is ā_āx1.ā_āāāx2.ā force\ file\_read\ to\ x_1.\ force\ file\_patch\ to\ x_2.\ return\ result. (c) As a cache (Ā§4): a private cache that keeps every state computes each token of the history once, by prefill where the Priestess wrote and by decode where the Oracle wrote. This needs the hypotheses of Proposition 4.10, among them that the tokenizer encodes the text between yield symbols piece by piece, that the model is called one whole answer at a time and writes each answer back as it generated it, and that the kernel only appends records ending with ā® . PDA2-PDAPriestess computationO-2-PDAO-2-PDA-Sstorage onlyO-2-PDA-Ttransitions onlyO-2-PDA-TSPriestess above OracleO-2-PDA-TSVa second stack (Ā§2.1)one Oracle instruction (Ā§2.3)S (Ā§3.2)T (Ā§3.3)TSV (Ā§5)an operating system (Definition 3.8) Turing completeS, on storage: where a program the Oracle runs sitsT, on transitions: who decides the next transitionArchNightsO-mode: what the Oracle runsP-mode: what the Priestess runsProgramsLibraryKernelISA init, the shell and the core tools, each a text that the Oracle runs as a program the shellās loop that reads the user, initās loop that restarts the shell, and the check on host commands the tool calls (operators) the Oracle may make, listed at the start of every taskās history the code that runs each tool call, in a kernel module; one table generates the list and the argument checks each taskās history, the context that the Oracle reads, kept in a memory segment of its own PRTS: the scheduler, fork and exec, a virtual file system, checkpoints, and drivers that call LLMs or people the Oracle mode, a privilege level below user mode with no code of its own, run by microcode 64-bit RISC-V, plus instructions that ask what the Oracle can do, call it, and enter the Oracle mode gem5 ArchNights-SE: PRTS on gem5ās syscall-emulation (SE) mode ArchNights-FS, a design, on gem5ās full-system (FS) mode: ZOOT in user mode, Linux in supervisor mode Figure 2: The construction. Left: the abstract machines from the PDA to the O-2-PDA-TSV. S and T are the two symmetry breakings, which can be taken in either order and together make a Priestess program the operating system of the tasks the Oracle runs. V realizes the O-2-PDA-TS on a von Neumann computer. Right: ArchNights, the prototype that implements the O-2-PDA-TSV on gem5, with what runs in O-mode on the Oracle side (amber) and what runs in P-mode on the Priestess side (blue). The bottom row, not split by side, holds the two realizations. ArchNights-SE runs the kernel PRTS on gem5ās SE mode, and ArchNights-FS (dashed) is a design with the kernel ZOOT. One instruction. By one instruction we connect an oracle of computability theory to a Turing-complete machine, a two-stack pushdown automaton written as a program. The instruction ās oracle\ s hands the Oracle the whole content of the stack s and appends the answer to that same stack. The result is the Oracle 2-PDA, O-2-PDA (Ā§2). Its computation divides in two: the computation inside the Oracle, and the Turing-complete rest, which queries the Oracle; we call it the Priestess. We colour one stack O, after the Oracle, and the other P, after the Priestess. Two stacks make the machine Turing complete and give each colour a stack of its own. Nothing is assumed of the Oracle, and yet the machine carries a language modelās inference: while the program only appends to a stack, the history that the Oracle sees on it grows autoregressively from call to call (query, answer, tool result, query), as a modelās context does (Figure 1(a)). We call this growth the autoregressive form. It belongs to the interaction, not to the model. Two breakings. The machine is symmetric, though: its colours are labels, and nothing in it distinguishes an operating system from the other programs. We type it with call-by-push-value [36], in which an entry on a stack is either data or a suspended program, much as a pageās permissions say whether it may be executed. We then break the symmetry twice (Ā§3). The storage breaking S decides where the Oracle may find a program. It may find one on an Oracle stack, a stack coloured O. On a Priestess stack, a stack coloured P, the Oracle finds no program, and whatever it answers there is data. The transition breaking T decides who chooses the next transition. It adds an O-mode, in which the machine queries one Oracle stack again and again and appends each answer, with no Priestess instruction between the queries, until an answer ends with a fixed yield symbol. Control then traps to one fixed label in the Priestessās code. Outside O-mode the machine is in the privileged P-mode, where the Priestessās code chooses the next transition. The machine with both breakings is the O-2-PDA-TS. For readers who build agents, O-mode is the model generating, a tool call is a yield, and the dispatcher that runs the tool and returns its result is the Priestessās code in P-mode. For readers from operating systems, O-mode stands to P-mode as user mode to the kernel, and a yield trap is a system call. Table 1 sets these terms out by side, and Ā§3 defines them formally; Ā§4.4 says where the correspondence stops. Appendix E.6 separates the two breakings into a general machine and derives the safety boundary and the trusted computing base on it, and Appendix E.7 asks what the several levels of privilege of an ordinary computer amount to. An operating system, derived. Under this choice of S and T the colours are ordered, in storage and in mode, with P above O. A Priestess program therefore confines the tasks that the Oracle runs: it decides what they see, when they run and what answers they receive, and they reach it only at one fixed entry. Such a Priestess program is an operating system, and its contract is an invariant of the machine (Theorem 3.4; Figure 1(b)). Under the contract, a task that the Oracle runs reads and writes only its own stack, control returns only at the fixed entry, and to the Priestess every answer is data: none becomes a code address, and none grants itself a right to execute. The contract is derived from the rules, for every Oracle, and it says what a kernel on this machine may rely on. Both breakings restrict as little as possible, since a stronger form of either would cost the Workflow form. Neither is a check that a program could pass or fail, so the contract holds for every program as well (Ā§3.3). With a budget, control also comes back to the Priestess on a good machine, one on which no history reached in O-mode is rejected (Figure 5). Each breaking could be designated the other way, but the two differ in what reversing them would take: reversing S would relabel the two colours (Appendix E.6), while reversing T rewrites the transition rules (Appendix E.5). An operating system forms only when the two are opposed, that is, when the side where a taskās program resides is not the side that T privileges. With privilege reversed, the Oracle is the operating system, the Priestess is confined to its own stacks, and each item of the contract has a counterpart with the roles exchanged, so the construction reaches the two quadrants in which a person is trusted and the program is confined. Two placements. With a language model as the Oracle, the two placements of a taskās program are the two forms of agentic systems. An Agent carries its program in its history, on the Oracle side, and the Priestess is its operating system. A Workflowās program is Priestess code, on the privileged side, so no operating system mediates it and the modelās output is data. A hybrid has part of its program on each side. āWorkflowā and āAgentā thus have two senses. As implementation forms they differ in whether an operating system mediates the task, a distinction we derive on the machine. As design paradigms, the sense of Building Effective Agents above, they differ in whether the modelās output or the programās code decides the next step. Either form can carry either paradigm, with a proper compiler, so the machine is one architecture in which to analyse their combinations. With privilege reversed and a trusted Oracle, such as a person, the same placements are humanācomputer interaction and automated systems, respectively. Their machine confines the program completely but cannot check the judgement of the Oracle it trusts. An Agent can always run in Workflow form, through an interpreter in the Priestess that makes the same queries with the same answers. The guarantees of the fixed entry and of task confinement then become obligations of the interpreterās code. A Workflow runs as an Agent task if a compiler translates it into content the Oracle runs. An Agent harness on an ordinary computer implements the machine in its host code. Caching, scheduling and safety. The contract holds for a black box, so it says nothing about what depends on the Oracleās interior, such as the cache. Ā§4 opens that one black box, for the Oracles that are autoregressive inside. It takes in the history through an encoder, which for a language model is its tokenizer, and the two views of the cache in Ā§1.1 are then two levels of one hierarchy, from the history down to the modelās KV cache. What the hierarchy recomputes in excess is exactly what re-encoding the history discards. For certain Oracles and kernels (Figure 1(c)), a private cache that keeps every state computes each token of a history once while the kernel only appends to it. Compaction and truncation rewrite the history and break this reuse, at a price stated by the cache model, and LMCache reports that truncation can halve the hit ratio of a prefix cache [37]. For scheduling, the Priestess side (a harness or a workflowās program) knows which histories it will submit next, and the Oracle side (an inference server) knows what it has cached. Each sideās scheduler works from an estimate of the other. The cache model quantifies the costs of keeping, discarding or swapping a taskās state while its tool call runs [32], and the choice among the three needs one more input, which comes from the Priestess side: when the task returns. Without it, the best that a deterministic Oracle-side choice between keeping and discarding can guarantee is twice the cost of a choice that knows. Safety, here the safety of the agentic system rather than of the model, needs no assumption on the Oracleās interior. Another invariant of the machine is its safety boundary. The Priestess wrote whatever an Oracle call reads, apart from the answers the Oracle appended to that stack, and the Oracleās answers reach the Priestessās control only at the trap and at three instructions that read content. The boundary does not make the machine a defence against prompt injection: a guarantee that holds for every Oracle can fix where content crosses, but not which content crosses. The boundary says instead where each defence outside the Oracle has to sit. Appendix E examines the caches, schedulers and defences on these models, as case studies. Each of these results is a property of the machine of Ā§1.2, derived from it. Two questions that opened Ā§1.1 are these results seen from the other side: where the security boundary of a model lies is what the safety boundary fixes, as the place where content crosses, and what the cache of an agent is is the history end of that one hierarchy. On a von Neumann computer. The construction V of Ā§5 makes the O-2-PDA-TS compatible with a von Neumann computer, and the result is the O-2-PDA-TSV. The stacks are segments of one memory, with a base, a top and a limit, and the Oracle operation is one instruction, with no code in O-mode. O-mode feeds the Oracle its own answers, and this iteration is the Oracleās own computation only when the Oracle is autoregressive inside. V therefore lets O-mode run only Oracles that are autoregressive inside (Ā§5.1 states the price of this choice), while P-mode may call any Oracle. The Oracle learns its requests from a declaration in its history, and one semantic delegation call, evaluated by the Priestess, can stand for several system calls. The results above are of the kind that Ā§1.1 asks for beyond the two clouds: invariants or bounds that hold no matter who or what answers the queries, or for every Oracle that meets a stated condition. Where a statement cannot take this form, as the Lynchpin hypothesis of Ā§5.4 cannot, we say so. Headline properties. Several of these results are statements that the works of Ā§1.1 do not make, because each needs two ingredients at once: a quantifier over every Oracle, or over every Oracle that meets a stated condition, and an operating system derived on the same machine as the Oracleās computation. ā¢ The contract is an invariant. Whatever the model answers, a task writes only its own stack and reaches the kernel only at one entry. What remains to assume is that a realization follows the runs of the machine (Ā§7.1). ā¢ One statement for both forms. An Agent task can always run in Workflow form with the same queries and answers, and the properties below hold of a task whichever side its program is placed on (Ā§3.5). ā¢ Cache and scheduling. For an Oracle that is autoregressive inside, an Oracle call is one hierarchy from the history down to the modelās KV cache, whose excess recomputation is exactly the encoderās loss, and, for certain Oracles and kernels, a private cache that keeps every state computes each token of a history once while the kernel only appends to it. The Priestess side knows the next keys and the Oracle side knows its cache, so each sideās scheduler works from an estimate of the other (Ā§4.3). ā¢ Safety. A guarantee for every Oracle fixes where content crosses, and none fixes which content crosses, a limit that needs the quantifier over every Oracle to be stated at all. We claim only that the works cited do not make these statements, not that no other formalism could. 1.3 ArchNights To show that the machine can be realized, we build ArchNights, a prototype that follows the O-2-PDA-TSV on gem5, the architecture simulator among the most used in computer-architecture research [38, 39]. ArchNightsā instruction set extends the RV64 ISA [40, 41] with an Oracle mode that lies below user mode and has no addressable code, and with an Oracle instruction compatible with RoCC, Rocket Chipās interface for custom coprocessors [42]. The simulated processor runs the Oracle mode by microcode. The prototypeās Linux-style kernel, PRTS, takes control back from every task at one fixed entry, confines ordinary tasks to a virtual file system, and checkpoints and compresses their histories. ArchNightsā distribution has a system library, an init system, a shell and core tools. On this machine every system call costs the Oracle a round trip and a piece of its history, so the system library moves work out of the Oracleās history into the kernel by semantic delegation (Ā§5.4): it registers operators as tool calls, each of which packs several system calls into one and is evaluated in P-mode by either trusted or verified code. ArchNights-SE, which runs in gem5ās syscall-emulation mode, will be open source. We evaluate it to show that the machine can serve as the basis of an agent harness. With deepseek-v4.1-flash as the Oracle, ArchNights-SE performs comparably on Terminal-Bench 2.1 [43] to two reference harnesses run with the same model in the same setting: mini-swe-agent [44] and Terminus 2, the benchmarkās own agent (Ā§6.6). Given a virtual display and audio output, ArchNights-SE produces a music video of world.execute(me);, working both as an agent harness and as a general-purpose computer. ArchNights-FS is a full-system design, with a kernel of its own, for a physical processor that implements this instruction set. Ā§6 argues ArchNightsā design choices one by one against the machine. 1.4 Contributions The contribution of this paper is one construction, in three parts. 1. The machine (Ā§2). The O-2-PDA: a two-stack pushdown automaton, Turing complete, extended with one instruction that queries a black-box Oracle with the whole content of a stack and appends the answer to it. While the program only appends, the history on a stack grows autoregressively, as an agentās context does (Proposition 2.7). 2. The operating system derived on it (Ā§3). Two symmetry breakingsāS on storage, T on transitionsāmake a Priestess program the operating system of the programs the Oracle runs. They are the weakest that keep the two placements of a taskās program apart for every program (Proposition 3.12). The kernel contract K1āK4 is an invariant of the machine, for every Oracle (Theorem 3.4); with a budget, control also returns (Proposition 3.7). Agent and Workflow follow as the two placements of a taskās program (Definition 3.10). 3. The realization (Ā§5ā6). The construction V fits the machine to a von Neumann computer: stacks become segments of one memory, the Oracle operation is one instruction, and O-mode has no addressable code. ArchNights, an extended RISC-V ISA with a Linux-style kernel, runs on gem5 and demonstrates that the machine can be built and can serve as the basis of an agent harness (Ā§6.6). Claims of this paper. Every property derived on the machineāthe kernel contract, the two placements, the cache model, the safety boundaryāis evidence for the construction: each answers a question that Ā§1.1ās two clouds do not ask. Three assumptions are used along the way and are named where they are used: factorization at the yield symbol (Definition 4.3), Frame-faithfulness (Ā§4.1), and the Lynchpin hypothesis (Ā§5.4). The kernel contract, the two placements and the safety boundary assume none of the three. A companion prototype demonstrates that the machine is realizable. What the construction leaves openācomplexity, refinement, asynchronyāis listed in Ā§8. Instances of the theory (Ā§4, Appendix E). The following statements are not further contributions. They are instances: their number, in the vocabulary of the fields they touch, is how the construction shows itself to be coherent. Each holds under the hypotheses named. Statement Hypotheses Where Kernel contract K1āK4; crossing invariant noneāevery Oracle Theorem 3.4, Corollary 3.5 Control returns (K5) budget; good machine Proposition 3.7 An Agent can always run in Workflow form none Proposition 3.11 Frame synchronization internally autoregressive Oracle; factorization at ā® Theorem 4.4 Excess recomputation is the encoderās loss + Frame-faithfulness Proposition 4.9 Prefix chain across tool calls; each token computed once + kernelās epoch discipline Proposition 4.10 Keep-or-discard without the return time costs a factor of two deterministic policy Proposition 4.11 Safety boundary: where content crosses noneāevery Oracle Theorem 4.12 No guarantee fixes which content crosses ā Proposition 4.13 Non-claims. Statements about language models rest on the assumption of Ā§4 or on reported observations; the Lynchpin hypothesis (Ā§5.4) is a working hypothesis; the prototype implements the machine without a refinement proof, and this paper gives it no security guarantee. Reading the paper. Ā§2ā4 are the theory, and Ā§5 and 6 build the machine and realize it. Readers with other interests can take shorter paths: Interest Path Theory, programming languages Ā§2ā4 with Appendices B and C; then Appendices E.5 and E.6, and Ā§7.3 and 7.4 Operating systems skim Ā§2.4 and 2.5; read Ā§3, Ā§4.2 and 4.3, and Ā§5 and 6 with Appendix D; then Appendices E.6 and E.7 Building agents Ā§2.5 and 3.5; the statements of the results of Ā§4; then Table 10 and Appendix E Safety Ā§3.4, 4.4 and 5.2; then Appendices C.10, E.4 and E.6 Humanācomputer interaction, automated systems Ā§3.4 and 3.5, and the person as an Oracle in Ā§5.4; then Appendix E.5 Oracle side (amber) Priestess side (blue) computation the Oracle: the source of the answers, treated as a black box; an LLM or a person (Ā§2.3) the Priestess: the Turing-complete computation that queries the Oracle (Ā§2.3) letters O names the colours, the modes and the order of the sides, and nothing more (Ā§2.2, Ā§3) P likewise stack Oracle stack: the only kind that may hold a program the Oracle runs (S) Priestess stack: whatever the Oracle produces there is data (S) mode O-mode: the Oracle answers again and again until an answer yields; no Priestess code runs between the queries (T) P-mode: the Priestess program chooses the next transition (T) a taskās program Agent form: the program is the taskās history, which the Oracle runs Workflow form: the program is Priestess code; the modelās output is data control crossing an answer ending with ā® yields: it traps to the one fixed label ātrap _trap, the system call the kernel enters tasks with uret and serves their traps; its library declares the services (Defs. 3.3, 3.8) task and history: the unit of work the system runs, and the content of its task stack (Definition 3.8). Step and Frame: one internal step of an autoregressive Oracle, and one whole answer (Ā§4.1). Table 1: The two sides at a glance. Terms that the Introduction uses before their definitions, split by side as the figures are. This is a map: the full dictionary is Appendix A, whose Table 11 lists the symbols of Ā§3. 2 The Machine: O-2-PDA āLet us suppose that we are supplied with some unspecified means of solving number-theoretic problems; a kind of oracle as it were. We shall not go any further into the nature of this oracle apart from saying that it cannot be a machine.ā ā A. M. Turing, 1939 [45, Ā§4] With these words Turing introduced oracle machines. We take his first point: until Ā§4 we go no further into the nature of the Oracle and assume nothing of its interior. Turingās oracle cannot be a machine. Ours may well be one: a language model on hardware of its own. Ā§4 looks inside. We start with a two-stack pushdown automaton, written as a program, and add one instruction that consults the Oracle: the program supplies the query as the whole content of one stack; the instruction appends the answer to that same stack. The stack becomes a record of the interaction. As long as the program only appends to it between queries, each query contains the whole preceding history, and the history grows autoregressively, as a language modelās context does (Proposition 2.7). 2.1 Two-Stack Pushdown Automata, Written as Programs A pushdown automaton (PDA) is a finite-state control with one stack. In state form it is a tuple (Ī,Ī£in,Ī£,Ī“,Īø0,ĪF)( , _in, ,Ī“, _0, _F) of a finite set of states Ī with a start state Īø0 _0 and final states ĪF _F, an input alphabet Ī£in _in, a stack alphabet Ī£ , and a transition relation Ī“. From the current state, the next input symbol or none, and the top of the stack, it chooses a next state and a word that replaces the top. Non-deterministic PDAs recognize exactly the context-free languages [46]. A two-stack PDA (2-PDA) has the same control and two stacks, and each transition reads both tops and replaces both. The second stack changes the class of machine: the stacks can hold a Turing machineās tape to the left and to the right of its head, so the two models compute the same functions [47, 46]. A 2-PDA is therefore Turing-complete. We write the 2-PDA as a program, in the style of Shepherdson and Sturgisās register machines [48]: the finite control becomes a numbered list of instructions, and the state becomes a program counter. Notation. Ī» is the empty word. A stackās content is a word whose right end is the top. For words u and v, uā vuĀ· v is their concatenation; for a symbol x, wā xwĀ· x is w with x pushed. topā”(wā x)=xtop(wĀ· x)=x and top(Ī»)=ā„top(Ī»)= , where ā„āĪ£ ā . uāwu w means that u is a prefix of w. A store Ļ maps each stack to its content, so Ļā”(s)Ļ(s) is the content of stack s. Definition 2.1 (program-style 2-PDA). Fix a finite alphabet Ī£ and two stacks, a and b. A program is a finite sequence Ī =(Ī¹1,ā¦,Ī¹n) =( _1,ā¦, _n) of instructions: Instruction Meaning āsāx push\ s\ x push xāĪ£xā onto stack s ās pop\ s pop the top of s āsāxāl jeq\ s\ x\ l jump to label l if topā”(Ļā”(s))=xtop(Ļ(s))=x, where xāĪ£āŖā„xā āŖ\ \ halt stop A configuration is a pair (ā,Ļ)( ,Ļ) of a label āā1,ā¦,n+1 ā\1,ā¦,n+1\ and a store Ļ. The step relation ā is: ā¢ if Ī¹ā=āsāx _ = push\ s\ x, then (ā,Ļ)ā(ā+1,Ļ[sā¦Ļ(s)ā x])( ,Ļ)ā( +1,Ļ[s Ļ(s)Ā· x]); ā¢ if Ī¹ā=ās _ = pop\ s and Ļā”(s)=wā xĻ(s)=wĀ· x, then (ā,Ļ)ā(ā+1,Ļ[sā¦w])( ,Ļ)ā( +1,Ļ[s w]); if Ļā”(s)=Ī»Ļ(s)=Ī», there is no successor and the machine is stuck; ā¢ if Ī¹ā=āsāxāl _ = jeq\ s\ x\ l, then (ā,Ļ)ā(l,Ļ)( ,Ļ)ā(l,Ļ) when topā”(Ļā”(s))=xtop(Ļ(s))=x, and (ā,Ļ)ā(ā+1,Ļ)( ,Ļ)ā( +1,Ļ) otherwise; ā¢ if Ī¹ā= _ = halt or ā=n+1 =n+1, the configuration is final. A run is a sequence of configurations linked by ā, starting from (1,Ļ0)(1, _0) for some initial store Ļ0 _0. An unconditional jump āl goto\ l abbreviates, all on one fixed stack s, a sequence of āsāxāl jeq\ s\ x\ l instructions, one for each xāĪ£āŖā„xā āŖ\ \. Since the sequence tests every possible top, one of these instructions jumps to l. One program runs, one instruction per step. What a 2-PDA program computes is the Turing-complete computation. Once the Oracle is added in Ā§2.3, it is the 2-PDA part of the machine. 2.2 Split Stacks and Their Colours A 2-PDA simulates the components of a computer [47]. Its two stacks hold a tape on either side of the head, and its control holds finitely many registers, each with finitely many values, which in the program style it represents by duplicating code for each value. A symbol at depth i is accessed by moving the i symbols above it to the other stack and back in reverse order, and the same transfers exchange two symbols. One construction from this simulation is used throughout the paper: a stack can be split into several stacks. Lemma 2.2 (split). Let the two stacks a and b hold finitely many logical stacks, each a segment of a or of b, separated by marker symbols that lie outside the alphabet of the logical stacks. Every push, pop or jeq on a logical stack s that has a successor on s is realized by a finite block of 2-PDA steps such that, at the end of the block, s has changed as the instruction prescribes, control continues where the instruction prescribes, and every other logical stack holds the same symbols in the same order as at the start. An instruction with no successor on s leaves the machine stuck, as it would be on a stack of its own. The block moves the segments above s onto the other stack, acts on s, and moves them back in reverse order (Appendix B). We call the finite sequence of steps that realizes one instruction on a logical stack a block, and we call the end of a block an observable step. Without splitting, every step is observable. From here on we describe the machine at its observable steps, with the logical stacks as its stacks. A stack produced by splitting is derived from the stack it was split from. Definition 2.3 (colouring). Stack a is coloured P and stack b is coloured O. Every derived stack carries the colour of the stack it was derived from, so each stack has a colour, O or P. At an observable step, a symbol has the colour of the stack it lies on, and a symbol that is moved inside a block keeps the colour of the logical stack it belongs to. The letters denote the Priestess and the Oracle, the two computations Ā§3 names. At this point the colours are only labels. Every instruction may therefore act on every stack, and exchanging the two colours everywhere maps programs to programs and runs to runs. Write Īµ for this exchange. The colours mark where Ā§3 breaks this symmetry: each breaking adds a structure that Īµ fails to preserve. 2.3 The Oracle and Its Instruction The Oracle answers queries over its own alphabets, and an encoder and a decoder translate between the Oracleās alphabets and the machineās. Definition 2.4 (Oracle, encoder, decoder). An Oracle (A,E,D)(A,E,D) consists of: ā¢ Oracle-side alphabets ĪQ _Q and ĪR _R, with sets XAāĪQāX_A _Q^* of queries and YAāĪRāY_A _R^* of answers; ā¢ an answer relation AāXAĆYAA X_AĆ Y_A in which every xāXAxā X_A has at least one answer; ā¢ machine-side query and reply alphabets Ī£Q,Ī£RāĪ£ _Q, _R ; ā¢ an encoder E:Ī£QāāXAE: _Q^* X_A, which may be partial, and a decoder D:YAāĪ£RāD:Y_Aā _R^*. Together they are the Oracleās codec. These components define the machine-side answer map Oā”(w)=Dā”(y):(Eā”(w),y)āAāĪ£Rā,wādomā”(E),O(w)=\\,D(y):(E(w),y)ā A\,\ _R^*, w (E), which is non-empty for every wādomā”(E)w (E). A word outside domā”(E)dom(E) is rejected. Convention (non-empty answers). Every answer is non-empty: Oā”(w)āĪ£R+O(w) _R^+ for every wādomā”(E)w (E). An empty answer appends nothing, so a program that queries the same stack again asks the same query. When the Oracle is iterated on its own history, as it is from Ā§3 on, an empty answer can return the machine to the configuration it left, and the iteration may never end. Appendix C.8 states where the convention holds by construction, where a realization must maintain it, and which results use it. The answer relation need not be a function: the same query may have more than one possible answer. We reason about which answers are possible, never about how likely they are, so the results of this section quantify over all possible answers and hold as well when the answer is chosen adversarially among them. Definition 2.5 (Oracle instruction; O-2-PDA). Add to the 2-PDA with the stacks of Definition 2.3 the instruction āsāle oracle\ s\ l_e, where lel_e is a label: ā¢ if Ļā”(s)ādomā”(E)Ļ(s) (E), then (ā,Ļ)ā(ā+1,Ļ[sā¦Ļ(s)ā r])( ,Ļ)ā( +1,Ļ[s Ļ(s)Ā· r]) for each rāOā”(Ļā”(s))rā O(Ļ(s)); ā¢ otherwise (ā,Ļ)ā(le,Ļ)( ,Ļ)ā(l_e,Ļ): the encoder rejected the query. The resulting machine is the O-2-PDA (Figure 3). The instruction reads the whole content of one stack and writes the answer next to it, on that same stack. On a tape, it reads a contiguous region and writes new symbols right after it. An accepted call appends one of the possible answers to the stack, and each possible answer yields a possible successor configuration. Ī Ī¹1 _1Ī¹ā=āsāle _ = oracle\ s\ l_eĪ¹n _nb : OOrraa : PĻā”(s)Ļ(s)EEAADDOracle (A,E,D)(A,E,D)readappend rrrejected: continue at lel_e Figure 3: The O-2-PDA. The program Ī runs on two stacks, coloured P (blue outline) and O (amber outline). The instruction āsāle oracle\ s\ l_e reads the whole content of the stack s, here a. The encoder E maps it to a query, and the decoder D maps an answer of A to a word rāOā”(Ļā”(s))rā O(Ļ(s)), which is appended to s. The word r is filled amber because the Oracle wrote it, and since it lies on a, it has colour P in the sense of Definition 2.3. When E rejects a query, the machine continues at lel_e. The Oracle instruction is the only access the Turing-complete computation has to the Oracle. The Oracleās internal computation (for a language model, a forward pass on hardware of its own) belongs to the O-2-PDA but not to its 2-PDA part. An Oracle is the whole triple (A,E,D)(A,E,D): one answer relation with two encoders gives two Oracles, and the machineās behaviour, including which queries are rejected, may differ between them. A rejection is the encoderās decision, not the answer relationās, and it is also how a bounded input is modelled: an encoder that accepts only words up to some length rejects the rest. The label lel_e matters only when a query is rejected, so Ā§1.2 writes the instruction as ās oracle\ s. Because the 2-PDA is Turing complete, lel_e adds no power when domā”(E)dom(E) is decidable: the program could test membership itself. On a machine that is not Turing complete, the jump could add power, since such a machine may be unable to decide domā”(E)dom(E). Conditions that link the Oracleās own process to the history on the machine are the subject of Ā§4 and are not assumed here. Lemma 2.2 extends to the Oracle instruction on a logical stack, by a block that gathers the operand alone onto one physical stack and back again (Appendix B). Lemma 2.6 (locality). At every observable step, the O-2-PDA changes at most the stack that its instruction names, and a jeq changes no stack. Proof. The rules of Definitions 2.1 and 2.5 update Ļ only at the stack that their instruction names, and a jeq changes no stack. Where the stacks are logical stacks on a and b, Lemma 2.2 and its extension to the Oracle instruction restore every other logical stack at the end of each block. So at every observable step the O-2-PDA changes at most the stack that its instruction names. ā In particular, a step on one stack leaves every stack of the other colour as it was. A real Oracle. The definition and the convention require three properties of an Oracle on every query its encoder accepts: that it answers, that the answer is non-empty, and, since an Oracle instruction is one step, that it answers in finite time. A real implementation may satisfy none of these requirements. A model behind an API may time out, fail or refuse, and a person may not answer at all. A real Oracle is total if, on every query its encoder accepts, it returns a non-empty answer in finite time. A total Oracle is an Oracle in the sense of Definition 2.4, and Ā§4 and 6 discuss what a realization does when the Oracle is not total. A word that the encoder does not accept is rejected before the Oracle sees it, and the program continues at lel_e. 2.4 What the Instruction Adds Oracle pushdown automata have been studied as one-stack devices for reducibilities among context-free languages [49], whereas the machine here has two stacks. A program computes a partial function when its input is written on a at the start, b is empty, and its output is the content of a in a final configuration. Compare an O-2-PDA with an oracle Turing machine [45] that has the same Oracle and may also ask whether a word lies in domā”(E)dom(E). With a deterministic Oracle, the two compute exactly the same partial functions, by simulating Turing machines on two stacks [47]. One direction keeps each stack on its own track of the Turing machine, copies the queried track to the query tape and appends the answer to the track; the other simulates the Turing machine on two stacks and, before a query, gathers the tape onto one stack and moves the query word alone onto the other. So taking a whole stack as the query adds no power, split stacks add none either, and the Oracle instruction adds no power beyond the Oracleās. What it adds is a form (Ā§2.5): each answer is appended to the query that produced it. A von Neumann machine stores program and data side by side in one random-access memory [50]. As an abstract machine it is the random-access stored-program machine [51]. Its instructions are fetched from memory rather than given as a fixed list beside it, and its control has a finite set of registers besides the program counter. Ā§5 realizes the machine of Ā§3 on such a computer. 2.5 The Autoregressive Form Let F assign a non-empty set Fā”(h)F(h) of words to each word h in a set domā”(F)dom(F). A sequence of words h0,h1,ā¦h_0,h_1,ā¦ is an autoregressive process driven by F if, for every t such that ht+1h_t+1 is defined, htādomā”(F)h_t (F) and ht+1=htā xtā ptwith āxtāFā”(ht).h_t+1=h_tĀ· x_tĀ· p_t x_tā F(h_t). The words ptp_t are interjections, not produced by F. Without interjections (pt=Ī»p_t=Ī» for every t), each new segment is generated from the whole history so far. Proposition 2.7 (autoregressive form). Consider a run of an O-2-PDA and a stack s. Suppose that the run executes āsāle oracle\ s\ l_e at observable steps n0<n1<āÆn_0<n_1<Ā·s, that none of these queries is rejected, and that, between ntn_t and nt+1n_t+1, every instruction with operand s is a push or a jeq. Let QtQ_t be the content of s just before step ntn_t. Then, for every t such that nt+1n_t+1 exists, Qt+1=Qtā rtā pt,Q_t+1=Q_tĀ· r_tĀ· p_t, where rtāOā”(Qt)r_tā O(Q_t) is the answer written at ntn_t, and ptāĪ£āp_tā ^* is the word of symbols pushed onto s between ntn_t and nt+1n_t+1, in order. So Q0,Q1,ā¦Q_0,Q_1,ā¦ is an autoregressive process driven by O, with the programās pushes as interjections. In particular QtāQt+1Q_t Q_t+1, and each answer rtr_t is drawn from O applied to the entire history QtQ_t. Proof. Step ntn_t replaces QtQ_t by Qtā rtQ_tĀ· r_t (Definition 2.5, query accepted). Consider an observable step n with nt<n<nt+1n_t<n<n_t+1: ā¢ if its instruction is a push on s, it appends one symbol to s; ā¢ if it is a jeq, or its instruction has another operand, it leaves s unchanged (Lemma 2.6). By hypothesis there is no other case, so by induction on these steps the content of s is always Qtā rtā pQ_tĀ· r_tĀ· p, where p is the word pushed onto s so far. At nt+1n_t+1 this gives the claim. ā The form belongs to the interaction between the program and the Oracle, not to the Oracle: the program stores the history, each call appends an answer to it, and the Oracle may produce that answer by any internal process. The form the query history takes is therefore fixed by the program and the Oracle instruction alone; Ā§4 adds conditions on the Oracleās interior without revising it. In Figure 1(a) the sessionās queries are Q0āQ1āQ2Q_0 Q_1 Q_2, each the whole history so far. If the program answers requests that the Oracleās output contains, the interjection ptp_t is that reply, and the history is the familiar context of an agent: history, model output, tool result, history (Ā§3). A program that pops from s, or rewrites it, starts a new history, and the proposition applies again from the next query. A language model continues the text it is given [3], and a chat-style use of a language model has this form, since each call queries the history so far, extended by the modelās previous output and whatever the program appends. In such a use, a context bound is an encoder that rejects longer words. We take every construction in its simplest form: synchronous, without concurrency, fault tolerance or recovery. Later sections take up liveness (Ā§3), safety (Ā§4), and asynchrony and finite capacity (Ā§5 and 6). We prove no time or space bound: the cost statements of Ā§4 count Steps and tokens, and an excursion may take as many O-mode transitions as its budget allows. So the O-2-PDA is a Turing-complete machine whose one new instruction appends the Oracleās answer to the stack it queries. Its stacks split into as many as a computation needs, a call touches only its operand, and a stack accumulates an autoregressive history while the program only appends to it. Its colours, however, are still labels, and the machine is symmetric between them. Ā§3 breaks that symmetry. 3 The Operating System: Two Symmetry Breakings An operating system must distinguish the programs it governs from the code that governs them. On the machine of Ā§2 nothing does: every instruction may act on either colour of stack. A type system from call-by-push-value gives us a language for when the machine treats content as data and when it runs it as a program. Two symmetry breakings then fix the reading of stored content and the transfer of control. The storage breaking S types the Oracleās operand by its colour: on a Priestess stack the Oracle only answers, and what it produces there is data, while on an Oracle stack it may run a program. S restricts the reading, not the runs. The transition breaking T separates task execution from privileged service and decides how control passes between them. The machine with both, the O-2-PDA-TS, has an operating system, and Agent and Workflow emerge as two placements of a taskās program on this machine. From here on we write Oracle stack and Priestess stack for a stack coloured O and a stack coloured P, and O-mode and P-mode for the two modes T introduces. The computation inside the Oracle is the Oracleās internal process, encoding, computing and decoding included; the Priestess computation is the Turing-complete part of the O-2-PDA. The names Oracle and Priestess also denote what belongs to each computation: its stacks, its side of the machine and its execution. The letters O and P, by contrast, name only the colours, the modes and the order of the two sides. Appendix A separates stacks, colours, types, modes and computations. 3.1 Data and Thunks: a CBPV Fragment Call-by-push-value (CBPV) [36] distinguishes stored values from computations that run. We use a fragment of it and none of its metatheory (Ā§7.4): the fragment gives a vocabulary for when stored content is data and when it runs. It is used here for semantic analysis, which differs from analysis at the level of the binary, and a rigorous development of the machine in the full calculus is left for future work. The contract of Ā§3.4 is derived from the transition rules, and the types give the contract its meaning. For now the same rules apply to stacks of both colours, and the restrictions come with S and T. Definition 3.1 (the CBPV fragment). CBPV has two classes of type. Value types A are the types of things that are; computation types B are the types of things that run. A::=|UāB::=FāA::= D U\,B B::=F\,A Here D is the type of data, a data symbol or a word of them; UāBU\,B is the type of a thunk, a value that suspends a computation of type B; and FāAF\,A is the type of a computation that produces a value of type A. The terms are V::=xāā£āM::=Vā£Mx.Nā£V array[]@l@V::=x d thunk\,M\\ M::= return\,V M\ to\ x.\,N force\,V array with the typing rules, where a context Ī assigns value types to variables, Ī,x:Aā¢x:AĪā¢:Īā¢M:BĪā¢āM:UāBĪā¢V:UāBĪā¢āV:BĪā¢V:AĪā¢āV:FāAĪā¢M:FāAĪ,x:Aā¢N:BĪā¢Māx.N:B array[]@c@ ,x:A x:A d: D\\[12.91663pt] M:B thunk\,M:U\,B V:U\,B force\,V:B\\[12.91663pt] V:A return\,V:F\,A\\[12.91663pt] M:F\,A ,x:A N:B M\ to\ x.\,N:B array So āM thunk\,M suspends M as a value, āV force\,V runs what the thunk V suspends, āV return\,V produces V, and Māx.NM\ to\ x.\,N runs M, binds its value to x and continues with N. Only values are bound and stored, so a computation is stored by thunking it. The typed O-2-PDA. We attach a value type to each stored symbol to specify how it may be used. The type is metadata, like a page-table permission, which states whether a page may be executed but does not change the page. The stack therefore still holds symbols of the alphabet of Ā§2. An element is : d: D, a data symbol, or :UāB c:U\,B, a stored value that represents a suspended computation. A stackās content as a whole can be read as data, of type D, or as a thunk, a program for the Oracle. For a stack s with content w=Ļā”(s)w=Ļ(s), the Oracle instruction performs the computation ā”(w):FāO(w):F\, D, whose value for an accepted query is an answer in Oā”(w)O(w). CBPV gives the call two readings of the same stored content. ā¢ Program reading, as a force. The stored content represents a thunk of ā”(w)O(w), of type Uā”(Fā)U(F\, D), and forcing the thunk runs that computation. ā¢ Data reading, as a return/to. The stored content is the data value w:w: D. The call returns a word r:r: D, and ā”(w)ār.NO(w)\ to\ r.\,N binds it for the Priestess code N that follows. Both readings use the same instruction, which appends the answer to its operand. They differ in whether the stored content is the program being run or the data supplied to a computation. Colours do not occur in the typing rules. They meet the types only in the two breakings, which restrict the reading of the Oracle instruction by the colour of its operand. The typed machine thus poses the question of this section: when is stored content a program for the Oracle, and when is it data? 3.2 Storage Symmetry Breaking S Definition 3.2 (storage symmetry breaking S). On a Priestess stack, every element has type D, and the Oracle instruction is typed only as ā”(Ļā”(s))ār.NO(Ļ(s))\ to\ r.\,N: a computation that returns a data value, which the code that follows binds. On an Oracle stack, content may have type UāBU\,B, and the Oracle instruction may be typed either way. The O-2-PDA-S is the typed O-2-PDA with S. In words: whatever the Oracle produces on a Priestess stack is data, and only an Oracle stack can hold a program the Oracle runs. S restricts only the reading of the Oracle instruction on a Priestess stack, constraining how the instructionās operand is typed rather than whether the instruction exists; Appendix E.6 returns to what the other choice would cost. The Priestessās own instructions may still read and write either colour, including the Oracle stacks on which it supplies task content and service replies. S fixes where the Oracle may act, and so who is the subject of an Oracle call: on an Oracle stack the Oracle runs a program, and on a Priestess stack it only answers, with a value that the Priestess program binds and uses. The underlying step is the same in both readings, so erasing the types preserves the runs of Ā§2: S by itself changes no run. What S breaks is Īµ . Exchanging the two colours maps a system in which the Oracle runs a program to one in which content of the other colour is handed to it as a program, and the typing admits only the first, so Īµ is not an automorphism of typed machines. On the O-2-PDA-S this designation is a relabelling: erasing the types maps the machine whose subject colour is O to the one whose subject colour is P, and this paper fixes it to O without loss. That S restricts no run is deliberate, not incidental. The contract of Ā§3.4 holds for every program and every run, an adversarial history among them, so the distinction between data and program must be one that nothing checks and nothing bypasses: a designation derived from the colours asks nothing of a program, so there is no well-formedness condition for a program to fail. The symmetry, not the machine, is what S breaks. It fixes how the content of each stack is read, and once T is added, that reading decides where control may enter: uret is typed as a force, so it enters only an Oracle stack (Definition 3.3). For the Oracle, S declares the Priestess stacks non-executable. In an implementation, storage boundaries can be enforced by a view, which limits the storage an execution can name, or a check, which tests whether a named access is permitted. Page mappings provide views, permission bits and hardware tags provide checks, and page tables combine the two. A check may also be static: a type system rules out disallowed accesses before execution, as in Singularityās process isolation [52]. Ā§4.4 returns to these protections and to the type bypasses that occur when the distinction between program and data is violated. On our machine the Oracle is given only the content of its operand, and the locality lemma (Lemma 2.6) restricts the effect of each call. T, next, confines a whole execution to that boundary. 3.3 Transition Symmetry Breaking T S fixes which stack holds a program the Oracle runs, and T fixes who decides the next transition. Privilege enters here, and it applies only where control changes hands. With S alone, each Oracle instruction makes one call and returns to the Priestess program at ā+1 +1, or at lel_e on rejection: the Oracle determines the appended answer, and the program determines the continuation. Alongside the mode in which Priestess code runs, T adds a mode in which successive Oracle calls on one task continue without an intervening Priestess instruction until an answer ends them. The mode identifies which component is executing, so the rules can allow different operations in the two modes, and an access is legitimate or not according to the mode that performs it. A mode that is granted some operations and denied others is a privilege level. Definition 3.3 (transition symmetry breaking T). Fix a symbol ā®āĪ£R ā _R, the yield symbol, and a label ātrap _trap of the program, the trap label. Replace the configurations of the machine by configurations in two modes, P-mode and O-mode, and add one instruction, āu uret\ u, for u a stack. The rules: ā¢ P-mode. A configuration āØ,ā,Ļā© P, ,Ļ runs the program. Its instructions are those of the machine without halt. The Oracle instruction has a P-mode rule only on Priestess stacks, and continues at ā+1 +1, or at lel_e on rejection, whatever its answer. āu uret\ u enters āØ,u,Ļā© O,u,Ļ . ā¢ O-mode. A configuration āØ,u,Ļā© O,u,Ļ runs no Priestess instruction. It calls the Oracle on the stack it entered on, u. With w=Ļā”(u)w=Ļ(u), āØ,u,Ļā©āāØ,ātrap,Ļ[uā¦wā r]ā©for ārāOā”(w)ā ending with āā®,āØ,u,Ļā©āāØ,u,Ļ[uā¦wā r]ā©for ārāOā”(w)ā not ending with āā®. array[]@l@ O,u,Ļ ā P, _trap,Ļ[u wĀ· r] \\ rā O(w) ending with ,\\[2.15277pt] O,u,Ļ ā O,u,Ļ[u wĀ· r] \\ rā O(w) not ending with . array A transition from O-mode to P-mode is a trap. An answer that ends with ā® is a yield, and the trap it causes is a yield trap. On this machine every trap is one. Runs start in āØ,1,Ļ0ā© P,1, _0 . An excursion is a maximal O-mode segment, together with the uret that starts it and, if it is finite, the trap that ends it. The O-2-PDA-T is the O-2-PDA with T, and the O-2-PDA-TS is the O-2-PDA-S with T, on which āu uret\ u is typed as āu force\,u and so, by S, allowed only on an Oracle stack. In words: the Priestess decides when the Oracle runs a program of its own, and on which stack; the Oracleās answers decide when that program stops; and when it stops, control goes to one fixed place in the Priestessās program. A P-mode Oracle call, by contrast, returns to the Priestess program whatever its answer, and that program may inspect the answer and branch with its own instructions. The Priestess program stops when execution runs past its last label. T designates no colour but a mode: a privilege is the set of operations a mode is granted, and the privileged mode is the one that runs the program. Reversing that choice is therefore not a relabelling but a second set of rules, the reversed ordering of Appendix E.5. Like the designation of S, Tās is fixed for the machine and revised by no run; unlike Sās, what T decides is not how content is read but which of two executions a configuration may take, and so it is visible in runs. S restricts the reading and leaves every run standing; T restricts the transitions. In CBPV terms, P-mode on the O-2-PDA-TS evaluates Priestess computations, whose Oracle instructions are return/ to on Priestess stacks; āu uret\ u is āu force\,u for the thunk on u, and only Oracle stacks hold thunks; and O-mode is the evaluation of that force, which the Oracle carries out. O-mode ends by forcing the thunk k=ā”(ātrap):Uā”(Fā)k= thunk( _trap):U(F\, D), the Priestess code from the trap label. T itself consults no type, so it applies to the untyped machine as well, and the two breakings can be taken in either order (Figure 2). Each leaves out what the other supplies: the O-2-PDA-S has the types without the modes, so nothing yet distinguishes the Oracleās execution from the Priestessās, and the O-2-PDA-T has the modes without the types, so the Oracle may be sent to run any stack, Priestess stacks included. Only the two breakings together make the Oracle run nothing but Oracle stacks, in a mode of its own. Good machines. Definition 3.3 specifies O-mode rules only for queries the encoder accepts, and in O-mode no program tests acceptance first. A machine, together with its Oracle and codec, is good if every query reachable in O-mode is accepted, so that each excursion continues or yields. The decoder matters here, since it may write symbols the encoder does not accept. A machine that is not good has a third outcome, a fault: the encoder rejects the history in O-mode, and Definition 3.3 gives no successor. Faults belong to exception handling, outside this section. Ā§4 gives a condition on the codec under which a machine is good. Ā§6.1 treats a realizationās handling of faults as one more trap to ātrap _trap, a trap that leaves the store as it was; with this trap the return of control (Proposition 3.7) needs no good machine. Transfer of control In CBPV Who decides what entry: P to O, āu uret\ u the Priestess forces the thunk on u the Priestess decides when to enter, and which stack the Oracle sees trap: O to P, a yield trap to ātrap _trap the Oracle call forces k, which reads what the excursion appended since the Priestess last wrote u the Oracleās answer decides when; where is fixed return: the reply v appended to u, then āu uret\ u k returns v to the task, which binds it with to the Priestess decides what v is, and when the task receives it a P-mode Oracle call, with no switch ā”(Ļā”(d))ār.NO(Ļ(d))\ to\ r.\,N binds the answer as a value the Priestessās code: it continues at ā+1 +1, or at lel_e on rejection Table 2: Where control passes between the Priestess and the Oracle on the O-2-PDA-TS, as machine transitions and in CBPV. Above the thick line, the mode switches: the Priestess enters a task, the task traps, and the Priestess returns to it. A trap and the return after it are one call of k, ākāx force\ k\ to\ x. Below the thick line, a P-mode call passes control to the Oracle and back without a switch. stack coloured OOstack coloured PPforcereturn/toforcereturn/to(a) typed O-2-PDA: symmetricUāBU\,B D D DOracle stackPriestess stackforcereturn/toreturn/toforce(b) after S: storageP-mode āØ,ā,Ļā© P, ,Ļ -mode āØ,u,Ļā© O,u,Ļ āu uret\ u(force thethunk on u)yield trapto ātrap _trap(force k)P-mode call:return/toanswer notending with ā® (c) after T: mode Figure 4: The two breakings. (a) The typed O-2-PDA: on every stack the Oracle instruction may be read as a force or as a return/to. (b) After S: on a Priestess stack (blue) every element has type D and the Oracle instruction is only a return/to (force struck out); on an Oracle stack (amber) content may have type UāBU\,B, and both readings remain. (c) After T: āu uret\ u enters O-mode on the Oracle stack u, O-mode appends answers to u until one ends with ā® , and the yield trap continues at ātrap _trap. P stands above O. Table 2 shows each transfer of control as a machine transition and in CBPV. When forced, k takes no argument. It reads the request from the stack on which the excursion ran, and produces the reply. The transfers preserve the CBPV distinction: Priestess code enters a task by forcing its Oracle-stack content through uret, an Oracle call in O-mode forces only k, and a P-mode call binds a data result. These restrictions follow from the transition rules, and therefore hold for every program. Ordered by privilege, the two sides form a two-point lattice with P above O (Figure 4), in which the Priestess governs task entry and service, while O-mode execution is confined to its task. Before the breakings the colours were unordered labels. Minimal breakings. Both breakings restrict as little as possible, and for the same reason: a stronger form of either would rule out a placement of a taskās program. S constrains how the Oracle instructionās operand is typed; a form that took the instruction away on the side that treats content as data would leave no Workflow form and no hybrid, and would be a different machine (Appendix E.6). T adds a mode beside the one the program runs in and keeps the P-mode call on Priestess stacks as it was, so a Workflowās calls are made as before. Neither is a check that a program could pass or fail: S designates how stored content is read, and the side T privileges is derived from the transition rules, not chosen beside them. What that buys is the quantifier: the contract of Ā§3.4 holds for every program and every run, an adversarial history among them. Proposition 3.12 (Ā§3.5) makes āas little as possibleā precise: it states the criterion behind the two breakings and shows that no other pair of exclusions meets it. 3.4 The Kernel Contract Together, S and T let the operating system defy the program with a power from beyond. The program runs, but the other side decides which stack it runs on, when it runs, what replies it receives and where its control returns. The first four guarantees are safety properties, which hold on every finite prefix of every run. The fifth, that control comes back at all, needs a budget and a good machine, and follows the first four. Theorem 3.4 (the kernel contract, K1āK4). For every Oracle, every program and every run: ā¢ K1 (an excursion writes only its stack). An excursion changes no stack but the one it entered on, and that one only by appending answers. ā¢ K2 (an excursion reads only its stack). In O-mode the Oracle reads only the stack the excursion entered on: its own earlier answers, and what the Priestess wrote there, the initial content included. ā¢ K3 (control returns only at the trap label). Every transition from P-mode to O-mode is an uret, and every transition from O-mode to P-mode is a trap to ātrap _trap. ā¢ K4 (an answer is data to the Priestess). A P-mode call changes only its operand, appending the answer, and continues at ā+1 +1, or at lel_e on rejection, whatever the answer. Every P-mode label in the run is 11, ātrap _trap, ā+1 +1, or a label written in Ī , and no rule writes Ī . So no answer, whether a P-mode call returns it or an excursion appends it, becomes a code address or instruction text. Proof. ā¢ K1. In an O-mode transition from āØ,u,Ļā© O,u,Ļ , each case of Definition 3.3 updates Ļ only at u: it appends the answer to Ļā”(u)Ļ(u). An excursion is a sequence of such transitions, so the claim follows by induction on it. ā¢ K2. The O-mode rule takes as input Ļā”(u)Ļ(u) alone. By K1 and the locality lemma, u changes only by O-mode appends on itself, or by Priestess instructions with u as operand, the P-mode call among them. ā¢ K3. Immediate from the rules: only uret leads from P to O, and every O rule that leads to P goes to ātrap _trap. ā¢ K4. The first part is derived from the P-mode rule of Definition 3.3. For the labels, induct on the run: each P-mode ruleās successor label is ā+1 +1 or a label written in the instruction, and after an excursion it is ātrap _trap by K3. No rule modifies Ī .ā Each guarantee is derived from the transition rules (K2 also uses the locality lemma), and none consults a type. The contract therefore holds on the O-2-PDA-T already, and S gives it its meaning: what an excursion runs is a program, and what a P-mode call returns is data. K1 and K2 together are spatial isolation. In Figure 1(b) the answer file_patch(notes.txt, teh ā the) is an O-mode yield. By K3 it reaches the kernel only as a request at ātrap _trap, and by K4, whatever it says, no rule makes it a code address. K4 also says what it means to receive an answer as data: the call returns to the continuation fixed by the instruction. Whatever the Priestess program then does with the answer (branch on its top symbol, or use it in a later query), it selects among the successors that its labels allow, or leaves the machine stuck. The answer never grants itself an execution right. The program can still run an answer as part of an O-mode task, but only explicitly, by copying it to an Oracle stack and entering that stack with uret. Corollary 3.5 (the crossing invariant). Content passes between the two modes in two ways only. ā¢ O to P only by a force. Content produced in O-mode reaches P-mode only through the force of k, the trap at ātrap _trap that ends the excursion producing it. The trap hands over what the excursion appended. ā¢ P to O only by a return. Content that the Priestess produces reaches O-mode execution only by a return: the Priestess writes the stack, and uret enters it. A resumption with no write is a return with an empty reply, and the initial content of a stack is the first write. Proof. O to P: by K1 an excursion changes no stack but its own, and by K3 every return of control is at ātrap _trap, so if P-mode reads a symbol that was produced in O-mode, that symbol was produced in an excursion that has already trapped. P to O: the Priestess changes an Oracle stack only with that stack as operand, by the locality lemma, and enters O-mode only by uret, by K3. So if the Oracle reads in O-mode a symbol that the Priestess produced, that symbol was written before an uret. ā The budget. Liveness requires that something good eventually happens [53, 54]. The standard Oracle of computability is a set, whose membership test is a total function and returns at once. An Oracle that is a partial function may never return on some inputs, and a real Oracle may fail and never return. On the machine every query has an answer, so each Oracle transition returns. What need not end is an excursion, which runs as long as the Oracle never answers with ā® . Real systems limit waiting with timeouts such as a watchdog, and for an Oracle the bound can be set on its internal steps, which for a language model means a limit on output tokens. A budget bounds the excursion. Definition 3.6 (budget). Change Definition 3.3 as follows: āuāĪ² uret\ u\ Ī² takes a budget Ī²āāĪ² with Ī²ā„1Ī²ā„ 1, a configuration in O-mode carries the remaining budget, and with w=Ļā”(u)w=Ļ(u) and rāOā”(w)rā O(w), āØ,u,Ī²,Ļā©āāØ,ātrap,Ļ[uā¦wā r]ā©if ārā ends with āā®ā (a yield trap),āØ,u,1,Ļā©āāØ,ātrap,Ļ[uā¦wā r]ā©if ārā does not end with āā®ā (a budget trap),āØ,u,Ī²,Ļā©āāØ,u,Ī²ā1,Ļ[uā¦wā r]ā©if āĪ²>1ā and ārā does not end with āā®. array[]@l@ O,u,Ī²,Ļ ā P, _trap,Ļ[u wĀ· r] \\ r ends with (a yield trap),\\[2.15277pt] O,u,1,Ļ ā P, _trap,Ļ[u wĀ· r] \\ r does not end with (a budget trap),\\[2.15277pt] O,u,Ī²,Ļ ā O,u,Ī²-1,Ļ[u wĀ· r] \\ Ī²>1 and r does not end with . array The kernel distinguishes the two kinds by the history: since answers are non-empty, the task stack ends with ā® after a yield trap and not after a budget trap. Proposition 3.7 (K5: control returns). On the machine with budgets, Theorem 3.4 and Corollary 3.5 hold as stated, and on a good machine every excursion entered with budget Ī² traps at ātrap _trap within Ī² O-mode transitions, for every Oracle. Proof. The new rules change only the remaining budget and the point at which an excursion traps. Every trap still goes to ātrap _trap and every O-mode transition still appends only to u, so the proofs of K1āK4 and of the corollary apply unchanged. On a good machine every O-mode configuration has a successor, each O-mode transition either traps or lowers the budget by one, and at budget 11 every transition traps. ā K5 is the fifth item of the kernel contract. It bounds transitions, not elapsed time, so a watchdog on a single Oracle step is the realizationās concern. A request may now span several excursions ended by the budget. The budget is a slice measured in O-mode transitions, which Ā§4 makes Steps or Frames, and preemption is never finer than one such transition. Without a budget, control returns only at yield traps, and tasks in O-mode are scheduled cooperatively. Figure 5 sums up the five items and how they depend on one another. the crossing invariant (Corollary 3.5)O to P only by a force; P to O only by a returnwhat it toucheswhere control goesK1 writes only its stack,and only by appendingK2 reads only its stackK3 entered only by uret,returns only at ātrap _trapK5 with a budget Ī²,returns within Ī² transitionsK4 a call changes only its operand, by appending the answer,and continues at ā+1 +1, or at lel_e, whatever the answer;every label is literal, so no answer is a code addressanexcursion(O-mode)P-modeK1, K3 and K4 follow from the rules of T, and K5 from those of the budget;K2 and the crossing invariant also use the locality lemma Figure 5: The kernel contract, K1āK5 (Theorem 3.4, Proposition 3.7). Amber: what holds for an excursion; blue: what holds in P-mode. The left column shows what a step may touch, and the right column shows where control goes next. An arrow points from a result to one that uses it: K2 rests on K1, K4 on K3, and the crossing invariant on K1 and K3. K5 (dashed) needs a budget and a good machine. The other four hold on every run, and on the O-2-PDA-T already. Once a trap has brought control back to P, Priestess code may inspect the task and copy its content from either colour of stack to the other. The invariant does not forbid this, since it governs only when content becomes available to execution in the other mode. Whatever program an Oracle stack carries, its traps reach the Priestess at the same trap label, and the Priestess chooses when the program runs, for how long, and what replies it receives before each resumption. A Priestess program can thus schedule the programs on Oracle stacks and handle their requests. This is the role of an operating system. The operating system in CBPV. With the types, this role is what sets such a program apart from every other. The machine has two kinds of force, and only two: an uret, which forces the thunk on an Oracle stack, and a trap, which forces k, the code at the trap label. A Priestess program that governs the programs on Oracle stacks is the code at both ends: it issues every force of a thunk on an Oracle stack, and it is the computation every trap forces. The Oracle calls of any other Priestess code force nothing (S). So an operating system is the Priestess code that forces the thunks on Oracle stacks and is forced by them; all other Priestess code only returns and binds. Table 2 is this reading at each transfer of control. Definition 3.8 (operating system). On the O-2-PDA-TS, an operating system is a kernel together with a library. The kernel is a Priestess program that enters Oracle stacks with uret and serves their traps with its code at the trap label, the service entry. The library declares the kernelās services to the tasks. A task is a unit of work the system runs. The Oracle stack that the kernel enters on behalf of a task is its task stack, and the content of the task stack is the taskās history. The library Ī provides tasks with an interface to the kernelās services. It consists of a request language LĪāĪ£Rāāā®L_ _R^* and a declaration Ī“Ī _ placed on every task stack. The declaration is the Oracle-side part of the library: it describes the available services. The corresponding Priestess-side handlers are implemented in the kernel. At a yield trap, the taskās request is the content appended in O-mode since the Priestess last wrote the task stack. The initial content counts as a write. What the kernel then writes on the task stack before entering it again is its reply. To use the request, a kernel records the boundary after its last write and reads the content appended beyond it, and a kernel with several tasks records which task stack it enters. A yield trap is a system call when its request belongs to LĪL_ . The kernel dispatches such a request to the corresponding handler and handles other requests as errors. Theorem 3.4 with Proposition 3.7 is the kernel contract: whatever the Oracle, every kernel can rely on these storage and control boundaries and, on a good machine, also on the return of control under a budget. Each kernel builds its scheduling and services on them. The contract is a property of the machineās rules, not of a kernel: a kernelās scheduling and services lie outside it and need a verification of their own, as seL4 and CertiKOS give their kernels [55, 56]. Table 11 in Appendix A collects the terms of this section. Definition 3.9 (program side, privileged side). Fix the architecture: the data of Definition 3.3 except the program (the alphabets, the stacks and their colours, ā® and ātrap _trap), together with the Oracle. A system on it has a program decomposed into kernel code K (kernel and library together) and task code C; task data Ī , the initial contents of the stacks of its tasks; and the declaration Ī“Ī _ , if any. A family is a set of systems that share the architecture, K and Ī“Ī _ , and differ only in C and Ī . ā¢ The program side of a task is where its program, its executable part, sits: the Oracle side when the program is content of its task stack that the Oracle runs, and the Priestess side when it is task code C. ā¢ The privileged side is the side holding the privileged mode of T. On the O-2-PDA-TS it is the Priestess. An operating system mediates a task when the task runs in O-mode and the kernel serves its traps. The Oracle runs Oracle-stack content only in O-mode (Definition 3.3), so a task runs in O-mode exactly when its program is on the Oracle side, and an operating system mediates a task exactly when the taskās program side differs from the privileged side. The separation gives the two sides different roles: the task supplies the computation, while the privileged side governs its access to services. In these terms, the taskās program identifies the acting subject, and privilege identifies the trusted party. An operating system stands between them when they occupy different sides. It defines itself through its opponent: the program acts, and the operating system determines the conditions under which it may act. S makes the acting subject definable, for it fixes which stacks can hold a program the Oracle runs; T gives that program a mode in which it runs and fixes the trusted party, the side holding the privileged mode. The two roles differ in kind. The acting subject is designated: the system decides, task by task, the side whose storage holds the taskās program. The trusted party is not designated beside it but derived from the rules, since T gives the privileged mode to the side that runs the program, and the two rows of Table 3 are two machines rather than two settings of one. Reversing the privileged side gives the dual: the Oracle is trusted, and the Priestess is confined. With a human as the Oracle, the human is then the operating system of the computer program and decides the services available at the programās interaction boundaries. Appendix E.5 gives this dual a machine, on which each item of the contract has a counterpart with the roles exchanged, and the bottom row of Table 3 shows its two placements. 3.5 Agents and Workflows on One Machine With a language model as the Oracle, the two placements of a taskās program are the two forms of agentic system. Definition 3.10 (Agent form, Workflow form, hybrid). ā¢ Agent form. The kernel code is fixed, and the tasks of a family differ in the content of their task stacks, where the Oracle finds the program it runs. The program side is therefore the Oracle, while the privileged side is the Priestess. Their separation makes the kernel and its library an operating system. Oracle output is program by default: once appended to the history, it becomes part of what the Oracle runs next. The task meets the operating system through the force/return boundaries of Corollary 3.5. ā¢ Workflow form. The taskās program is Priestess task code that calls the Oracle in P-mode, and no task stack is entered. Its program side and privileged side are both the Priestess, so the task runs directly on the machine, with no operating system mediating it. Here the Oracle supplies data to an existing program: its returned value is bound by to and used by the Priestess continuation. The program may inspect the result, branch on it, or explicitly interpret or promote it as program content (K4). ā¢ Hybrid. A task has program parts on both sides: Priestess task code may start Agent tasks, or an Agent may use a service implemented by task-specific Priestess code. The two parts retain their respective forms of interaction. The Agent part runs as a program served by the operating system. Its yield trap forces a service computation, and the kernel returns a value before resuming it with uret. The Workflow part runs in P-mode and uses Oracle answers through the data reading, binding a returned value to the continuation with to. Data becomes program there only by the Priestessās explicit interpretation or promotion (K4). A hybrid brings these two forms together, with each program part classified by the side on which it executes. A shared client library linked into task code belongs to C: it executes as part of the task, even when many tasks use it. A fixed body of code alone therefore does not determine the form. The form is determined by where the taskās program executes and how it meets the other side. This is a machine-level account of the distinction drawn in Building Effective Agents [8]: a Workflow follows control paths written in Priestess task code, and an Agent carries its program in the Oracle-side history and directs its process through successive requests. Table 3 sets the two placements beside the reversed assignment of privilege. Trusted party ā / acting subject ā Oracle Priestess Priestess (this machine; an untrusted Oracle such as a language model) Agent: an Agent operating a computer; the Priestess is the operating system Workflow: non-OS; Oracle output is data Oracle (privilege reversed; a trusted Oracle such as a human) humanācomputer interaction: a human using a computer, the counterpart of an Agent operating one; non-OS, the program is on the trusted side automated systems: a Priestess program runs by itself, confined, and the human decides at the switches; the human is the operating system Table 3: The four combinations of acting subject and trusted party. Non-OS marks the two cells where the acting subject is the trusted party: the taskās program is on the privileged side, so no operating system mediates it (Definition 3.9). The bottom row has privilege reversed, on the machine of Appendix E.5. Two readings, and form versus paradigm. Every interaction is one transition read from two sides. From the Oracle side, an excursion runs the history as a program and calls on the Priestess through a yield trap, and the Priestess supplies the service as an Oracle would; from the Priestess side, uret starts a computation whose appended content the program inspects at ātrap _trap. The same exchange is a service request in one reading and a returned result in the other, and in CBPV the same transition is a force in one reading and a return in the other. A P-mode call is likewise a program step that returns a data value for the Priestess, and a computation over supplied content for the Oracle. In both cases the two readings describe the same machine transitions. The Agent and Workflow forms are therefore implementation forms: they concern where the taskās program is placed. How that program chooses its next action is its design paradigm. A Workflow may follow a plan the model generated, and an Agent may carry out a predefined procedure. So either form can realize either paradigm, given a suitable compiler. Ā§4 uses the distinction: because both forms run on this one machine, it states its models once, and its cache model, its return bound and the safety boundary hold of a task whichever side the taskās program lies on. Simulation across the sides. The distinction between form and paradigm becomes clearer when a computation is moved from one side to the other. An Agent computation can be implemented by an interpreter in Priestess code that reproduces the Oracle loop in P-mode, or translated into such code by a code generator. Either way, the code preserves each taskās queries and appended answers and directs completed excursions to the service entry. The result has Workflow form, and its P-mode calls preserve the data-result behaviour of K4. Conversely, a Workflow can run as an Agent task given a compiler, which maps the Workflow with its inputs to Oracle-side content with the same effect on the Priestess stacks when the kernel serves it. A family of Workflows then runs as Agent tasks on a fixed kernel, and K1āK4 hold for them; K5 also holds when the kernel enters them with budgets on a good machine. We run such computations with the same Oracle and compare them by their final contents on the original stacks, taken as sets of possible results for a nondeterministic Oracle. In CBPV an interpreter replaces one force of a thunk by a loop of return/ to calls on a Priestess stack, and a compiler goes the other way. The interpreter always exists: Proposition 3.11 (an interpreter for Agent tasks). For every program K of the O-2-PDA-TS there is a program KāK of the O-2-PDA-S that has no uret and runs the same tasks as K, making the same Oracle queries with the same answers. The construction (Appendix B) renames each task stack to a fresh Priestess stack and replaces each uret by a loop that calls the Oracle there and jumps to ātrap _trap when the top is ā® . The convention of non-empty answers makes the test exact, and with budgets the loop maintains a counter. The interpreter makes the role of T explicit. The task computation can be carried out by ordinary Priestess code, and in the interpreter, that code itself confines each task to its history and routes completed excursions to the service entry. With T, by contrast, these boundaries belong to the machineās rules and apply to every kernel. The interpreter does the work of an operating system within a single protection domain, and T is what gives that work a privileged position. A Workflow can also be installed as a kernel service handler that runs the Workflow in P-mode with its original queries and answers when an Agent issues the request; the task is then a hybrid. Where a harness and a scaffold sit. The interpreter is a program running inside the machine. An ordinary Agent harness sits at another level: its host code provides the machine on which the Agent runs. In the familiar modelātool loop, model execution corresponds to O-mode, a tool request triggers a yield trap, and the toolās reply is returned to the task before execution resumes. The task history carries the Oracle-side program, and the dispatcher and its tool handlers play the kernel and the library. The harness therefore exhibits the Agent form, although one host program combines the machine, the kernel and part of the library. ArchNights separates the three. A scaffold is the system library together with the programs a task may run, that is, the kernel-and-library side of the machine (Ī“Ī _ , LĪL_ and the handlers). It exposes its operations to the task as thunks: the declaration names them, a request forces one, and the Priestess evaluates it in P-mode. Placing the Workflows and Agents. The paradigm is the Workflow paradigm when control follows code paths written in advance and the Oracleās output at most selects among them, and it is the Agent paradigm when the Oracleās output determines which steps there are. Prompt chaining, routing, parallelization and evaluator-optimizer [8] have Priestess task code that fixes the stages and the control structure, so they have Workflow form. Their paradigm is also the Workflow paradigm, since routing and the evaluatorās verdict select among paths written in advance. In orchestrator-workers, a P-mode program asks the Oracle for a decomposition and starts workers from it, which gives Workflow form with the Agent paradigm [8]. Autonomous agents carry the program in the task history, and model iteration selects actions and tool requests that the harness dispatches, which gives Agent form with the Agent paradigm. Hybrids, such as agents calling Workflow tools, Workflow nodes running Agent tasks and harness skills that build task DAGs, have task-specific program parts on both sides. Why these two breakings. This section chooses one criterion and derives the rest from it: both placements of a taskās program exist and stay apart, and what the machine guarantees holds for every program and every Oracle, with no condition asked of a program. An Oracle execution can be classified by its operand colour, Oracle or Priestess, and by whether a yielded answer forces the service entry or completes. Two of the four combinations are admitted: an Oracle stack whose yield forces the service entry, which is O-mode, and a Priestess stack whose answer completes, which is the P-mode call. The first is the only admitted one in which the machine forces the service entry, and the second is the only admitted one in which the Priestess uses the Oracle on its own data. Each breaking excludes one of the other two: S excludes the one in which Priestess content would be run, and T excludes the one in which the Oracleās program would complete without reaching the service entry. T excludes an Oracle stack whose answer completes, and Proposition 3.11 realizes the same behaviour on a Priestess stack; S excludes a Priestess stack whose answer forces the service entry, since Priestess content is never forced. The criterion leaves no other choice of the two exclusions. Proposition 3.12 (the breakings are forced). Give the O-2-PDA the modes of Definition 3.3, but admit uret only on the stacks whose colour lies in a set U, and the P-mode Oracle call only on those whose colour lies in a set C, with no condition on the program. A task can run in Agent form only if Uā ā Uā , and in Workflow form only if Cā ā Cā . For every program, every Oracle and every run, no P-mode call reads an answer appended in O-mode if and only if Uā©C=ā Uā© C= . So exactly two such machines meet the criterion: the one with U=OU=\O\ and C=PC=\P\, which is S together with the P-mode rule of T, and the same machine with the colours exchanged. The proof is in Appendix B. A P-mode call that read an excursionās answers would hand the Oracleās program to a Workflow as its data, and the two placements would no longer stay apart; the condition is the In item of the safety boundary (Theorem 4.12) in P-mode. No weaker restriction of this kind meets the criterion, and no stronger one keeps both placements. A condition on the program, such as the safety of Definition E.4, is weaker, but it asks something of every program, which the criterion rules out. The rest of T follows from the same criterion. Its mode is what the Agent form needs, since the Oracle runs a program by being queried again and again with no Priestess instruction between the queries; and its one trap label is what K4 needs for every Oracle, since an exit whose label an answer could select would make that answer a code address. What the section derives is therefore the breakings from the criterion, the contract from the rules (Theorem 3.4), and the operating system of Definition 3.8 as the code at the two forces that the breakings leave. A harnessās dispatcher is a kernel because it is the code at those two forces, not by definition. So the contract is established as an invariant of the machine, and Agents and Workflows are the two placements of a taskās program under it. We leave to Ā§4 what depends on the Oracleās interior, the cache first of all. 4 Eclipse: Between Oracle and Priestess A solution found for one form of agentic system usually needs to be translated before it applies to the other. Ā§3 puts both forms on one machine, where the Oracle and the Priestess stand in a twin relation, like the two stars of VFTS 352, an overcontact binary [57]. Taken as one whole, the pair lets a problem be modelled once, and the model then applies to either form through the link between the two sides. So far the Oracle has been a black box, and every result of Ā§3 holds for every Oracle. But a cache of the Oracleās computation is hard to analyse from outside. Turing went no further into the nature of his oracle. We go one step further: this section assumes that the Oracle is autoregressive inside, the paperās one assumption about the Oracleās interior. The machineās queries already have the autoregressive form as long as the program only appends to them (Proposition 2.7). With an autoregressive interior the two processes can be linked through the codec (Ā§4.1), and the link underlies a model of the cache (Ā§4.2) and an analysis of scheduling (Ā§4.3) that hold for both forms. The assumption is needed for these and for nothing else. The safety boundary of Ā§4.4 does not use it: like the contract, the boundary is an invariant of the machine. An Oracle that is not autoregressive inside therefore loses the cache model, and with it the cache affinity the schedulers weigh, but keeps the contract and the safety boundary. This section builds the model and the analysis. Appendix C gives their details, and Appendix E applies them to the encoders, caches, schedulers and defences the field has built. 4.1 Encoder and Decoder, Step and Frame The codec of Definition 2.4 links the two processes. Earlier work often assumes the Oracleās alphabets are the machineās. We keep them apart, so that the codec is fixed first and the machine-side alphabets are what it accepts and produces. In this section w and v are machine-side words, and x, y and z are Oracle-side ones; QtQ_t is the history at the t-th call, as in Proposition 2.7; lcpā”(x,xā²)lcp(x,x ) is the longest common prefix of two sequences, and |x||x| is the length in symbols. We write Eā”(w)E(w) only for wādomā”(E)w (E). Definition 4.1 (internally autoregressive Oracle). An Oracle (A,E,D)(A,E,D) (Definition 2.4) is internally autoregressive if it is given ā¢ an inclusion ĪRāĪQ _R _Q and a terminator ĻāĪRĻā _R, and ā¢ a step relation Ī½āĪQāĆĪRĪ½ _Q^*Ć _R, its one internal step, such that its answers are what the steps generate, A(x)=y1āÆyk:yi+1āĪ½(xy1āÆyi) for i<k,yk=Ļ,yiā Ļ for i<k, array[]@l@A(x)=\\,y_1Ā·s y_k:y_i+1āĪ½(x\,y_1Ā·s y_i) for i<k,\\ y_k=Ļ,\ y_iā Ļ for i<k\,\, array and its decoder works symbol by symbol, D(y1āÆyk)=D(y1)āÆD(yk)D(y_1Ā·s y_k)=D(y_1)Ā·s D(y_k), with Dā”(Ļ)=ā®D(Ļ)= and ā® in no other Dā”(y)D(y). We call an Oracle that is internally autoregressive an AARA_AR Oracle, after the A of its interior, and we call one that is not internally autoregressive an AnARA_nAR Oracle. One machine may consult both kinds, and Ā§5 asks which may run in O-mode. The inclusion is needed because the Oracle reads its own output. Without it, a step could produce an illegal input for the next. The terminator decodes to the yield symbol, so an answer ends exactly where an excursion yields. Inside an answer the Oracleās history grows by one symbol per step, but across calls it need not, as shown below. A step relation depends only on the concatenation of the query and what has been generated, so internal autoregression constrains the answer relation only where one query extends another by generated symbols, and the answers do not determine which step relation produced them (Proposition 4.6). Step and Frame. A Step is one internal step: the Oracle appends one symbol of ĪR _R to its history, and the machine receives that symbolās decoding. A Frame is the sequence of Steps from a query to the terminator; it is an answer of A, and its decoding ends with ā® . The Frame interface answers w with a decoded Frame, Oā”(w)=Dā”(y):yāAā”(Eā”(w))O(w)=\D(y):yā A(E(w))\, the answer map of Definition 2.4 itself; the Step interface answers w with a decoded Step, Dā”(z):zāĪ½ā”(Eā”(w))\D(z):zāĪ½(E(w))\. The Frame interface is an Oracle, and the Step interface is one when no symbol of ĪR _R decodes to Ī», as the convention of non-empty answers (Ā§2) asks. In O-mode the Frame interface makes one transition per Frame, which traps, while the Step interface makes one per Step and traps at the Step that decodes to ā® . The two interfaces differ in how often the Oracle encodes. Through the Step interface, two consecutive Steps compute z1āĪ½ā”(Eā”(Qt)),z2āĪ½ā”(Eā”(Qtā Dā”(z1))).z_1āĪ½ (E(Q_t) ), z_2āĪ½ (E(Q_tĀ· D(z_1)) ). After the first Step the Oracleās internal history is Eā”(Qt)ā z1E(Q_t)Ā· z_1, but the second encodes the longer machine-side word, and that encoding need not extend Eā”(Qt)E(Q_t). If a, b and aābab are all Oracle symbols and the encoder prefers the longest match, the history a is encoded [a][a] and the history aābab is encoded [aāb][ab]: appending b does not extend [a][a] but replaces it, and the Oracleās internal state, built for [a][a], has to back up. The Frame interface encodes only at the start of a Frame, and inside a Frame the Oracle extends its own history. Definition 4.2 (loss and backtrack). For machine-side words w and v, the loss of extending w by v is lossEā(w,v)=|Eā”(w)|ā|lcpā”(Eā”(w),Eā”(wāv))|,loss_E(w,v)=|E(w)|- |lcp (E(w),E(wv) ) |, the number of symbols of Eā”(w)E(w) that the encoding of wāvwv does not retain. For a set G of pairs (w,v)(w,v), the backtrack at G is LEG=sup(w,v)āGlossEā(w,v)L_E^G= _(w,v)ā Gloss_E(w,v), with supā =0 =0. Two sets are used: the Step pairs, where w is any word and v is the decoding of one Step, and the Frame pairs, where w is empty or ends with ā® and v ends with ā® . These are properties of the codec, so every bound on them holds on every run. A runās pairs lie among these sets: its Step pairs always, and its Frame pairs when the kernelās writes end with ā® . The loss is a Step-level form of bounded variation [58] (Appendix C). Separator. A condition on one symbol removes the backtrack where a Frame ends. The yield symbol ā® is a separator for E if E first splits its input at every ā® , emits the terminator Ļ for each ā® , and encodes each piece independently, by an encoder that maps the empty word to the empty sequence and never emits Ļ. The yield symbol then marks the boundary of a Frame on both sides. Only one consequence of a separator is used below, and it follows at once from the definition. Definition 4.3 (factorization at the yield symbol). E factorizes at ā® if Eā”(Ī»)=Ī»E(Ī»)=Ī», no word without ā® has Ļ in its encoding, and for every word wāā®āvādomā”(E)w\, \,v (E) the words w, wāā®w\, and v lie in domā”(E)dom(E) and Eā”(wāā®āv)=Eā”(w)ā Ļā Eā”(v).E(w\, \,v)=E(w)Ā·ĻĀ· E(v). Frame-faithfulness. Whether the Oracleās own history also follows the machineās is a property of the Oracle with its codec, not of the encoder alone. Call an Oracle with its codec Frame-faithful if Eā”(Dā”(y))=yE(D(y))=y for every Frame y it can generate: the encoder writes back, symbol for symbol, what the Oracle generated. This follows from neither internal autoregression nor factorization. For example, a model can be internally autoregressive and still sample a tokenization that the encoder would not produce; it is then not Frame-faithful. Appendix C.8 collects where Frame-faithfulness holds, how it fails, and which results need it, and Appendix C.9 describes in these terms the ways a realization keeps, drops or hides a modelās reasoning. The theorem has a part for each side. Theorem 4.4 (Frame synchronization). Let E factorize at ā® , and let w be empty or end with ā® . 1. The encoder. Eā”(wāv)=Eā”(w)ā Eā”(v)E(wv)=E(w)Ā· E(v) for every v with wāvādomā”(E)wv (E); in particular Eā”(w)āEā”(wāv)E(w) E(wv). 2. The Oracle. If the Oracle answers w with a Frame y, and wāDā(y)ādomā”(E)w\,D(y) (E), its own history Eā”(w)āyE(w)\,y is the encoding Eā”(wāDā(y))E(w\,D(y)) of the machine-side history exactly when Eā”(Dā”(y))=yE(D(y))=y, and otherwise neither is a prefix of the other; if wāDā(y)ādomā”(E)w\,D(y) (E), the question does not arise, and the encoder rejects the history the Frame would extend. So after every Frame on such a history, the history of a Frame-faithful Oracle is the encoding of the machineās. Proof. (1) If w is empty, Eā”(w)=Ī»E(w)=Ī». Otherwise w=wā²āā®w=w , and factorization gives Eā”(w)=Eā”(wā²)āĻāEā(Ī»)=Eā”(wā²)āĻE(w)=E(w )\,Ļ\,E(Ī»)=E(w )\,Ļ and Eā”(wāv)=Eā”(wā²)āĻāEā(v)E(wv)=E(w )\,Ļ\,E(v). (2) By (1) with v=Dā”(y)v=D(y), Eā”(wāDā(y))=Eā”(w)āEā(Dā”(y))E(w\,D(y))=E(w)\,E(D(y)), which is Eā”(w)āyE(w)\,y exactly when Eā”(Dā”(y))=yE(D(y))=y. Otherwise, since y and Eā”(Dā”(y))E(D(y)) both end with Ļ and contain it nowhere else, neither is a prefix of the other. ā Part (1) holds whatever the Oracle generates: the encoding follows the machine-side history and never backs up across a ā® . Three of its consequences are used below. (i) The loss stays in the open Frame. Write a history as w=wā²āwā²w=w w , where wā²w is empty or ends with ā® , and wā²w , the unfinished Frame, contains no ā® . Then Eā”(w)=Eā”(wā²)āEā(wā²)E(w)=E(w )\,E(w ), and Eā”(wā²)E(w ) is a prefix of Eā”(wāv)E(wv) for every v, so lossEā(w,v)ā¤|Eā”(wā²)|loss_E(w,v)ā¤|E(w )|. In particular, a Frame pair loses nothing. (i) Prefix trees. If h1āh2āāÆh_1 h_2 Ā·s are histories that are empty or end with ā® , then Eā”(h1)āEā”(h2)āāÆE(h_1) E(h_2) Ā·s. Histories grown from a common such history h share Eā”(h)E(h), so their encodings form a prefix tree. (i) The completed Frames agree. When the Oracle answers w=wā²āwā²w=w w with a Frame y, its own history Eā”(w)āyE(w)\,y and the encoding Eā”(wāDā(y))E(w\,D(y)) of the machine-side history both begin with Eā”(wā²)E(w ), so they agree on every completed Frame and can differ only in the last, Eā”(wā²)āyE(w )\,y against Eā”(wā²āDā(y))E(w \,D(y)). Part (2) says when they agree on that one too. A separator describes a tokenizer that splits its input at a registered special token before encoding the pieces. Whether a given tokenizer does so is a property of its implementation, to be checked per tokenizer; the check need not analyse BPE merges, which happen only inside the pieces. Inside an open Frame the loss remains, and how large it is depends on the encoder. BPE as implemented, with a proper dictionary, has a finite lookahead, which depends on the dictionary alone and beyond which a prefix of the tokenization is stable [59]. Its Step backtrack is therefore finite and depends on the dictionary. An encoder with only two symbols, by contrast, can have an unbounded one. Appendix E.1 assesses the work on tokenizers against these two conditions, factorization at ā® and the backtrack inside an open Frame. Figure 6 draws the two parts of Theorem 4.4. (a) one way, by the encoder (Theorem 4.4(1))machineencodingw1āā®w_1\, 2āā®w_2\, ā²w Eā”(w1)āĻE(w_1)\, ā”(w2)āĻE(w_2)\, ā”(wā²)E(w )EEEEEEthe encoding never backs up across a Frame boundary;only the open piece wā²w may be encoded anew(b) the other way, by the Oracle (Theorem 4.4(2))OraclemachineencodingEā”(w)E(w)y, generatedwwDā”(y)D(y)Eā”(w)E(w)Eā”(Dā”(y))E(D(y))DDEEequal exactlywhenEā”(Dā”(y))=yE(D(y))=y Figure 6: Frame synchronization, both ways. (a) When the encoder factorizes at ā® , the encoding of a history is the concatenation of the encodings of its pieces up to each ā® (answers and the kernelās records alike, each ending with Ļ), followed by that of the open piece wā²w . Only the open piece may be re-encoded differently as the history grows. (b) After the Oracle answers a history w (empty or ending with ā® ) with the Frame y, its own history is Eā”(w)āyE(w)\,y, while the machine records wāDā(y)w\,D(y), whose encoding is Eā”(w)āEā(Dā”(y))E(w)\,E(D(y)). The two are equal exactly when the Frame re-encodes to itself, and otherwise they diverge inside the Frame. Amber: what the Oracle generated. So a Step advances both autoregressive processes by one internal transition of the Oracle, and may make the encoding back up, but only inside the open Frame; a Frame advances both by a round of transitions that ends in the single separator, and the encoding never backs up across it. The two processes are synchronized Frame by Frame, one way by the encoder when it factorizes at ā® (Theorem 4.4(1)), and the other by the Oracle when it is Frame-faithful and answers a history that ends at a Frame boundary (Theorem 4.4(2)). Each query is encoded afresh, so a difference in the last Frame never outlasts the next query. The decoder needs no condition of its own, because it works symbol by symbol (byte-level vocabularies are the exception). Closure and observability. Iteration in O-mode continues only while each history is a word the encoder accepts. A machine on which this always holds is what Ā§3 calls a good machine, and a condition on the alphabets gives one. Proposition 4.5 (closure). Suppose Ī£RāĪ£Q _R _Q and domā”(E)=Ī£Qādom(E)= _Q^*, and that every excursion starts on a history in Ī£Qā _Q^*. Then, whatever the Oracle, every query made in O-mode is accepted, and the machine is good: every reachable O-mode configuration has the successors Definition 3.3 gives it. Proof. By induction on the excursion. It starts on a history in Ī£Qā _Q^*. Each O-mode transition appends an answer in Ī£RāāĪ£Qā _R^* _Q^*, so the history stays in Ī£Qā=domā”(E) _Q^*=dom(E). ā The starting condition is a discipline of the kernel: it holds if the initial content of every task stack and everything that the kernel writes onto a task stack lie in Ī£Qā _Q^*. Proposition 5.1 says what fails without the inclusion and how a codec repairs it. The Priestess side sees the Oracle only through the interface it calls. A property of the Oracleās computation is observable through an interface if the answers returned through that interface determine it. This notion is defined for the Oracle, not the observable steps of Ā§2. Through the Step interface the number of Steps is observable, one answer per Step, but through the Frame interface it need not be. Proposition 4.6 (Steps are not visible in Frames). Suppose ĪR _R contains distinct symbols t, t1t_1, t2t_2, other than Ļ, with Dā”(t)=Dā”(t1)āDā(t2)D(t)=D(t_1)\,D(t_2). Then for every query q there is an internally autoregressive Oracle that answers q with the decoded Frame Dā”(t)āā®D(t)\, both after two Steps and after three. So, for some internally autoregressive Oracles, an observer that sees only decoded Frames cannot tell how many internal Steps they took. Proof. Let x=Eā”(q)x=E(q), and let Ī½ā”(x)=t,t1Ī½(x)=\t,t_1\, Ī½ā”(xāt)=ĻĪ½(x\,t)=\Ļ\, Ī½ā”(xāt1)=t2Ī½(x\,t_1)=\t_2\, Ī½ā”(xāt1āt2)=ĻĪ½(x\,t_1t_2)=\Ļ\, and Ī½ā”(z)=ĻĪ½(z)=\Ļ\ for every other z. Then Aā”(x)A(x) contains tāĻt\,Ļ and t1āt2āĻt_1t_2\,Ļ, and both decode to Dā”(t)āā®D(t)\, . ā The Oracle of the proof is not Frame-faithful, nor is any Oracle that answers a query with the same decoded Frame after different numbers of Steps: a Frame-faithful Oracle takes exactly |Eā”(Dā”(y))||E(D(y))| Steps on a Frame y, so an observer who knows the encoder derives the number of Steps from the decoded Frame. Without Frame-faithfulness, an Oracleās internal transitions need not be observable through the Frame interface, unless the Oracle exposes more than the Frame, such as a count of its Steps. For a language model, the encoder is the tokenizer and the decoder is the detokenizer. A Step is one token, or one sequence of up to k tokens with multi-token prediction [60]. An inference engineās generate interface can expose Steps; most agents, by contrast, use chat interfaces (/v1/chat/completions, /v1/responses and /v1/messages), which wrap the history in a template on the providerās side. What remains observable through them is the Frame and whatever metadata the provider reports, such as a token count. Proposition 4.6 says what is lost without such metadata. 4.2 Two Caches, One Hierarchy In Agent applications the client and the server each optimize their cache and their computation. To optimize them together, both sides need one model of the problem and a fair estimate of the other sideās state. On the O-2-PDA the Oracle and the Priestess are different processors with different storage. We model both as systems of one kind, connect them through the codec and the Frame, and read the result on the KV cache. The unit of computation is one transition of the machine, from QtQ_t to Qt+1Q_t+1: one decode step at the Step interface, a Frame at the Frame interface. A miss of the Oracleās store is rematerialized by a prefill, while a hit reuses the KV cache. Stores as functions. We define memory, cache and backing store as functions, in the types of Ā§3. A store maps keys, which need not be linear addresses, to values. One operation builds everything else: a store placed above a function answers the keys it holds and passes the others down. Definition 4.7 (store, hierarchy, system). Fix a set K of keys and a set V of values, of type D. ā¢ A store C costs tCt_C per lookup and holds a working set WC:āW_C:K , a finite partial map. ā¢ For a store C and a function f on keys, C over f is the function (Cā³f)ā(k)=WCā(k)if ākādomā”(WC),fā”(k)otherwise.(C f)(k)= casesW_C(k)&if k (W_C),\\ f(k)&otherwise. cases The first case is a hit; the second is a miss, where the store holds a thunk of the computation below it and the access forces it. The cost is c(Cā³f,k)=tC+[kādom(WC)]c(f,k),c(C f,k)=t_C+[\,k (W_C)\,]\;c(f,k), where [P][P] is 11 if P holds and 00 otherwise. ā¢ A hierarchy is C1ā³C2ā³āÆā³Cnā³fC_1 C_2 Ā·s C_n f, grouped to the right. The function that it defines is its access, and f is its bottom: a backing store, which holds every key it is asked for, or a rematerialization, a computation that produces the value again. The level directly above a backing store is the memory. A hierarchy whose levels act on different key sets may include a translation level between them: a map Īŗ from the keys above it to the keys below, with W=ā W= and t=0t=0, which changes no value and only renames the key. A bottom may likewise be post-processed by a function h of the value, and the pair is a hierarchy with bottom hāfh f. ā¢ C is coherent with f if WCW_C agrees with f wherever it is defined. For a store C coherent with f, Cā³fC f is the functionāstore pair āØf,Cā© f,C , a memo of f. ā¢ A system is a processor with a hierarchy. A computation on it reads through the access, and its cost is its compute cost and its access cost, the cost of the accesses it makes. Coherence makes a cache transparent: if every level is coherent with what lies below it, the access is the bottom, and a level changes the cost of an access, never its value. We study the functional properties of the store, so we assume every level is coherent at all times, as if a write were visible at every level at the next time. Since Cā³fC f is again a function on keys, hierarchies compose as functions do (Construction C.1, Appendix C). A miss at the bottom of one system is a call into another, so two systems connect into one hierarchy. In the same way, when each function of a chain calls the next, the chain with the memos of its functions is a hierarchy with one level per function, and an access is paid down to the first memo that hits. The Oracleās computation. For one transition, the Oracle computes yāAā”(x)yā A(x) on the encoded history x=Eā”(Qt)x=E(Q_t) at the Frame interface, or zāĪ½ā”(x)zāĪ½(x) at the Step interface. Its processor is an accelerator, its keys are encoded prefixes, and what it reads is not its earlier answers but the state they left, so the store keeps states. Definition 4.8 (state presentation, prefix reuse). Let the Oracle be internally autoregressive with step relation Ī½. A state presentation is a set S of states with an initial state s0s_0, a transition Ļ:ĆĪQā :SĆ _Q , and a map Ī± from states to sets of symbols of ĪR _R, such that Ī½ā(x)=Ī±ā(s^ā(x))Ī½(x)=Ī±( s(x)), where s^ā(Ī»)=s0 s(Ī»)=s_0 and s^ā(xāĪ³)=Ļā”(s^ā(x),Ī³) s(xĪ³)= ( s(x),Ī³). It is truncatable if s^ā(x) s(x) yields s^ā(xā²) s(x ) at no cost for every prefix xā²x of x. A state cache holds pairs (z,s^ā(z))(z, s(z)). The cost of computing s^ā(x) s(x) from the entry for z is costā”(z,x)=|x|ā|lcpā”(z,x)|,cost(z,x)=|x|-|lcp(z,x)|, the number of applications of Ļ after truncating to the common prefix. With several entries, the cost is the least of these. Every internally autoregressive Oracle has the trivial presentation s^ā(x)=x s(x)=x, so the definition fixes a cost model, counting applications of Ļ , without excluding any Oracle. For a transformer, s^ā(x) s(x) is the KV cache of the prefix x: one application of Ļ is one token of prefill or decode, truncation drops entries, and āØs^,Cs^ā© s,C_ s is the KV cache as a functionāstore pair, whose hits reuse a state and whose misses are rematerialized by a prefill. Tiers of the KV cache in host memory and storage are levels below it [61, 62, 37]. Since s s is a function and the sampling happens in Ī±, a state cache changes no answer set, and the machine with it has exactly the executions of the machine without it. This is why the state cache can be modelled as a functionāstore pair although the Oracle is not a function, and why the Oracleās cache and its scheduling can be modelled as the Priestessās are on a CPU. Apart from rematerialization, only the keys differ (addresses on a CPU, histories for the Oracle), so the cache model of this section applies to both systems. The key of an access is the encoded history: a query looks up the longest cached prefix z of its encoding x and pays costā”(z,x)cost(z,x). Within an append-only epoch, defined below, no entry is updated in place, since the history only grows. Entries are deleted by an eviction or by a truncation to a prefix. At Frame granularity the encodings of histories grown from a common history form a prefix tree (consequence (i) of Theorem 4.4), and the store can be organized as one, as SGLangās radix tree organizes its KV cache [17] and vLLM shares the blocks of a common prefix [16]. An Oracle call is one hierarchy. Consider an Oracle call with answer rt=Dā”(yt)r_t=D(y_t), ytāAā”(Eā”(Qt))y_tā A(E(Q_t)). Reading QtQ_t is the Priestessās own access. The derivation below composes functions, while the Oracleās answer relation is set-valued, so fix a recording Ļ first: a function on states that picks one answer for each, Ļā(s^ā(x))āAā(x)Ļ( s(x))ā A(x) at the Frame interface and Ļā(s^ā(x))āĪ½ā(x)Ļ( s(x))āĪ½(x) at the Step interface. One exists, because Ī½ā(x)=Ī±ā(s^ā(x))Ī½(x)=Ī±( s(x)), and Ļ carries s^ā(x) s(x) through the symbols generated after x, so Aā”(x)A(x) depends on x only through s^ā(x) s(x). Every run of the recording is a run of the machine (Appendix C), so it is a witness the hierarchy can be built on, and a hit of a cache returns the recorded answer. The call then passes through three stages, each of which can be memoized. The memo of the encoder is an encoding cache āØE,CEā© E,C_E , that of the state presentation is the state cache āØs^,Cs^ā© s,C_ s , and that of the call as a whole is an answer cache COC_O keyed by the history. By Construction C.1 the call is one hierarchy, COā³DāGĻāāØs^,Cs^ā©āāØE,CEā©,C_O D G_Ļ s,C_ s E,C_E , where GĻG_Ļ generates the recorded answer from the state, by Ī± and Ļ , to the end of the computation. Read right to left: the history is encoded, the state of the encoding is looked up and on a miss rematerialized by a prefill, and the generated symbols are decoded. The levels differ in what they can reuse. If the Oracle is a black box, only the answer cache, keyed by whole histories, is available. Within an append-only epoch these histories strictly grow, so no entry is hit again. If the Oracle is internally autoregressive and the encoder factorizes at ā® , the encoding cache and the state cache reuse prefixes, organized as the prefix tree above. From the entry of a history, a miss on an extension of it costs, beyond the growth of the encoding, exactly the encoderās loss. Proposition 4.9 (excess recomputation is the loss). For all machine-side words w and v, costā”(Eā”(w),Eā”(wāv))=(|Eā”(wāv)|ā|Eā”(w)|)+lossEā(w,v).cost (E(w),E(wv) )= (|E(wv)|-|E(w)| )+loss_E(w,v). So, for (w,v)(w,v) in a set G of Definition 4.2, a state cache recomputes at most LEGL_E^G beyond the growth of the encoding, and at most LEG+1L_E^G+1 when the encoding grows by at most one symbol. If E factorizes at ā® and w is empty or ends with ā® , the cost is |Eā”(v)||E(v)|: nothing is recomputed at a Frame boundary. Proof. The two sides subtract the same common prefix: cost=|Eā”(wāv)|ā|lcp|cost=|E(wv)|-|lcp| and lossE=|Eā”(w)|ā|lcp|loss_E=|E(w)|-|lcp|. The bounds follow from the definition of the backtrack. In the last case Eā”(wāv)=Eā”(w)āEā(v)E(wv)=E(w)\,E(v) by Theorem 4.4(1). ā Epochs and the encoding cache. An append-only epoch of a task stack u is a maximal segment of a run in which the kernel changes u only by push. Within one, the histories at the starts of successive excursions on u satisfy hi+1=hiāriāvih_i+1=h_i\,r_i\,v_i, where rir_i is what the i-th excursion appended and viv_i is what the kernel pushed before the next. The proof of Proposition 2.7 applies, with K1 for excursions on other task stacks and K4 for P-mode calls. Any other rewrite of u, replacing or restoring the history for instance, starts a new epoch. The encoding cache memoizes E on the prefixes that end at a Frame boundary. For each stack on which the Oracle is called, the cache stores the encoding of the last query up to its last ā® , or of the empty word if the query has none. If E factorizes at ā® , the codec therefore reads and encodes only the unfinished Frame at the last call and what was appended since. The cache stays coherent while the stack only grows. Across a tool call the Oracle holds the state of the query followed by what it generated, Eā”(q)āyE(q)\,y, and the next query is qāDā(y)āvq\,D(y)\,v. With both directions of the synchronization, Eā”(q)āyE(q)\,y is a prefix of the encoding of the next query. Proposition 4.10 (the prefix chain across tool calls). Let a task stack u be in an append-only epoch, with the Oracle called on u through the Frame interface, and suppose that (i) E factorizes at ā® ; (i) the Oracle with its codec is Frame-faithful; (i) the hypotheses of Proposition 4.5 hold; and (iv) the content of u at the start of the epoch ends with ā® , and so does every word that the kernel pushes onto u. Item 3 also requires that the presentation is truncatable, in the sense of Definition 4.8; the trivial presentation s^ā(x)=x s(x)=x is. Then: 1. If the Oracle answers a query q on u with the Frame y and the kernel then pushes v, the next query qā²=qāDā(y)āvq =q\,D(y)\,v has Eā”(qā²)=Eā”(q)āyāEā(v)E(q )=E(q)\,y\,E(v): the next query extends the Oracleās own history by the encoding of the kernelās push alone. 2. Give u a private state cache: empty when the epoch starts, used only by u, kept between transitions, never evicted. Then the first query on u costs its whole encoding, and each later one costs only |Eā”(v)||E(v)|, where v is what the kernel pushed since the last Frame. Up to an O-mode transition with query q and Frame y, the applications of Ļ on u number |Eā”(qāDā(y))||E(q\,D(y))|: every symbol of the encoding is computed once, by prefill or by generation. 3. With the private state cache of item 2, let the encoding cache update its entry for u at every call. Then after each call on a query q with Frame y the encoding cache holds Eā”(q)E(q) and the state cache holds s^ā(Eā(q)āy) s(E(q)\,y); for a truncatable presentation the latter yields s^ā(Eā(q)) s(E(q)) at the cost of item 2, so one key (the stack and the length of its history) reaches both entries. Proof. Every query on u ends with ā® : the first is the content at the start of the epoch followed by pushed words, and each later one appends a Frame (whose decoding ends with ā® ) and pushed words. (1) Theorem 4.4(1), applied at the end of q and at the end of Dā”(y)D(y), gives Eā”(qā²)=Eā”(q)āEā(Dā”(y))āEā(v)E(q )=E(q)\,E(D(y))\,E(v), and Eā”(Dā”(y))=yE(D(y))=y by Frame-faithfulness. (2) Generating y leaves s^ā(Eā(q)āy) s(E(q)\,y) in the cache, and by item 1 the next query costs costā”(Eā”(q)āy,Eā”(qā²))=|Eā”(v)|cost(E(q)\,y,E(q ))=|E(v)|. The first query costs its whole encoding, each Frame costs its |y||y| Steps, and each push costs its |Eā”(v)||E(v)|. By item 1 at every earlier call, and with Eā”(qāDā(y))=Eā”(q)āyE(q\,D(y))=E(q)\,y by Theorem 4.4(2) and Frame-faithfulness, the encoding of qāDā(y)q\,D(y) is the concatenation of these pieces. (3) Since q ends with ā® , the entry of the encoding cache is Eā”(q)E(q). On the first query the state cache starts empty and processes Eā”(q)E(q); on a later one, by item 1, it already holds the state of Eā”(q)E(q) without the encoding of the last push, and the call processes that encoding. ā Figure 1(c) draws item 2: the records that the Priestess wrote are prefilled, the Frames that the Oracle wrote are decoded, and nothing is computed twice. With a cache shared across tasks the number of computations is an upper bound, since another task may already hold a state that u reuses. Since one key indexes both caches, the start of a new epoch invalidates both at once. The chain breaks in three places. When the kernel rewrites the task stack, replacing or restoring the history, a new epoch starts, and its first query costs costcost from the nearest cached prefix to the new encoding. When a Frame does not re-encode to itself, the state cache recomputes |Eā”(Dā”(y))|ā|lcpā”(y,Eā”(Dā”(y)))|>0|E(D(y))|-|lcp(y,E(D(y)))|>0 symbols beyond the push, by the cost of Definition 4.8 and because y and Eā”(Dā”(y))E(D(y)) diverge. This happens when a model samples a tokenization the encoder would not produce, or when a chat interface re-renders the history through a template on the providerās side. A related mismatch, which token healing repairs, is known at the boundary between a prompt and its continuation [63, 64] (Appendix E.1). And at a budget trap inside a Frame (Definition 3.6) the history need not end with ā® , and the state that the Oracle holds need not be that of the historyās encoding. What the machine adds is a place for each of these mechanisms (Table 4) and, for prefix sharing and its break at the end of an epoch, a statement that can be checked against it. The mechanisms themselves are not new: prefix trees of KV caches [17], paged KV memory [16], keeping, discarding or swapping the cache at tool calls [32], and program-aware scheduling [65, 66, 67] all exist. Reuse of segments that are not prefixes [68, 69, 18] falls outside Definition 4.8. And the statement is made once for both forms. In the Agent form, within an append-only epoch, the queries on a task form a chain, because between two of them the task changes only by its own appends (K1) and by the kernelās pushes, while excursions on other tasks and P-mode calls leave it alone (K1, K4). The chain thus follows from the contract, given the kernelās epoch discipline. In the Workflow form, the queries of the P-mode calls on a Priestess stack d form a chain if the program never pops d, by Proposition 2.7, since no excursion writes d (K1). The chain is then a property of the program text. The condition can be checked syntactically, and it is sufficient but not necessary. Table 12 in Appendix C sets the two chains side by side. Appendix E.2 places the mechanisms of serving systems on this model, together with reuse beyond prefixes and the rewrites by which agent systems manage their context (compaction and paging), each of which starts a new epoch. 4.3 Two Schedulers With several Oracle requests and several Oracles in a system, assigning the evaluations to the processors that run them is a scheduling problem, as assigning tasks to cores is for a CPU scheduler. This subsection analyses the problem instead of modelling it: it assigns each scheduler to its side, says what each side knows, and prices one decision that needs both (Proposition 4.11). A scheduler assigns computations to the systems that can run them: each computation is a systemās computation, bound to its value argument. A computation costs its compute cost and its access cost, found recursively down the hierarchy (Definition 4.7, Construction C.1). A scheduler has cache affinity when it places a computation on the system whose stores already hold the keys that computation will access, and it balances load when it spreads the compute cost evenly. The two can pull apart, since the system that holds a computationās keys may be the busiest. The Oracle and the Priestess may run on one processor or on two, each with its own caches. On the machine they meet only at the switches and at P-mode calls (Corollary 3.5), so between those points each sideās work is local to it, and a new scheduler can be built beside the existing one and coordinate with it through the known relation between the sides. Each configuration is either in O-mode on one task stack or in P-mode, and a P-mode call is a single transition, so the Oracleās execution of a task and the Priestessās never overlap. One identifier per task serves both sides, as the taskās identifier does on a von Neumann computer. Each side has a scheduler, and each schedules both its own side and the other. The Priestess-side scheduler orders the Priestessās work and schedules the Oracle side by choosing which task to enter with uret and, under a budget, for how long. In the Agent form it is the operating systemās scheduler. The Oracle-side scheduler (an inference serverās batching and its order of prefill and decode, for instance) orders the Oracleās computations. It also schedules the Priestess side, since a P-mode call completes when the Oracle has computed the answer, and only then does the program that issued it continue. In the Workflow form no operating system mediates the task, and the Oracle-side scheduler belongs to the serving side. The machine represents the Priestess-side scheduler as kernel code. The Oracle-side schedulerās decisions show only in when answers arrive, and time is not in the model. At every configuration in P-mode the Priestess side holds the machine-side content of each Oracle access it may submit next: the history of each task it may enter (K2) and the operand of each call it may issue. The Oracle side, by contrast, receives only the queries submitted to it. So the Priestess side knows the next keys, and the Oracle side knows its cache. Each works from an estimate of the other, built from what the other exposes, since the model gives neither side the otherās state. Appendix E.3 works this out for a taskās state while its tool call runs [32]. Keeping, discarding or swapping the state are three costs of the cache model, and the decision needs one more input from the Priestess side: when the task returns. Time is not in the machine, but what this knowledge is worth can be quantified once the interval is given a duration from outside the machine. Proposition 4.11 (the price of not knowing the return). Let a task yield, and let the Oracle side hold the state of its history from the trap until the kernel enters the task again, after a time T>0T>0. Keeping the state costs Ī¼>0Ī¼>0 per unit of time. Discarding it costs nothing until the task returns, and then R>0R>0, the cost of rebuilding the state, in the same unit. A retention policy keeps the state until a time Īøā[0,ā]Īøā[0,ā] and discards it then if the task has not returned, at the cost cĪøā(T)=Ī¼āTif āTā¤Īø,Ī¼āĪø+Rif āT>Īø.c_Īø(T)= casesĪ¼ T&if Tā¤Īø,\\ Ī¼Īø+R&if T>Īø. cases 1. Every policy pays at least optā”(T)=minā”(Ī¼āT,R)opt(T)= (Ī¼ T,R), and a policy chosen with knowledge of T pays exactly that. 2. For every Īø, supT>0cĪøā(T)/optā”(T)ā„2 _T>0c_Īø(T)/opt(T)ā„ 2, with equality exactly when Īø=R/Ī¼Īø=R/Ī¼. So for every Īµ>0 >0, a policy chosen without knowledge of T pays more than (2āĪµ)āoptā(T)(2- )\,opt(T) for some T. Proof. (1) If Tā¤ĪøTā¤Īø the policy pays Ī¼āTĪ¼ T, and otherwise Ī¼āĪø+Rā„RĪ¼Īø+Rā„ R; either is at least optā”(T)opt(T). Knowing T, take Īø=āĪø=ā if Ī¼āTā¤RĪ¼ Tā¤ R and Īø=0Īø=0 otherwise. (2) For Īø=0Īø=0 the ratio is R/(Ī¼āT)R/(Ī¼ T), and for Īø=āĪø=ā it is Ī¼āT/RĪ¼ T/R once Ī¼āTā„RĪ¼ Tā„ R; both are unbounded. For 0<Īø<ā0<Īø<ā, let T decrease to Īø from above. The cost stays Ī¼āĪø+RĪ¼Īø+R while optā”(T)opt(T) tends to minā”(Ī¼āĪø,R) (Ī¼Īø,R), so the ratio tends to 1+R/(Ī¼āĪø)1+R/(Ī¼Īø) if Ī¼āĪøā¤RĪ¼Īøā¤ R and to 1+Ī¼āĪø/R1+Ī¼Īø/R otherwise. Each limit is at least 22, and equals 22 only when Ī¼āĪø=RĪ¼Īø=R. At Īø=R/Ī¼Īø=R/Ī¼ the ratio is 11 for Tā¤ĪøTā¤Īø, and 2āR/R=22R/R=2 for T>ĪøT>Īø, since then Ī¼āT>RĪ¼ T>R. ā The proposition is the rent-or-buy problem of competitive analysis [70], which arises in snoopy caching as the choice of how long to retain a cache block [71]. The machine adds two things to it: the cost R, which the cache model prices (beyond the push, the costcost from the nearest cached prefix, and the whole encoding of the history when none is left; Definition 4.8), and the side on which T is decided. The Oracle side has the queries and its own answers, and neither determines T. It may predict T from the request it generated, but it chooses its policy without knowing T. The kernelās service decides when the task is entered again, so T is decided on the Priestess side, and so is what can be known of it before the task returns. Without that knowledge, the deterministic policy with the best guarantee keeps the state for R/Ī¼R/Ī¼, until keeping has cost what rebuilding would; the factor is exact while the cost of keeping is constant over the interval, which is what the proposition assumes. A randomized policy brings the expected ratio down to e/(eā1)e/(e-1), and no lower [72]. A prediction of T, such as one built from a running toolās report [73], lets a policy come close to optopt when the prediction is good and keep a bound when it is not [74]. Swapping adds a third choice, which the proposition leaves out. In the Workflow form the same interval lies between two calls that share a prefix, and the programās schedule holds what T stands for [34]. A cache miss of a language model is a prefill, far costlier than a miss on a processor, so cache affinity weighs more than it does for a CPU. By Definition 4.7, an Oracle-side scheduler can still borrow from CPU scheduling once it models the hit and miss costs of its levels. The decisions that use the relation between the sides are the Priestess sideās, because it holds the next keys. With the Priestess in view, the server can make part of its state visible to the client, or the client can track a list of keys, to raise the hit rate. Program-aware servers [65, 66, 67] and program-agnostic ones [16] are the two halves. SGLang stands between them, since its frontend passes a programās forks to the runtime [17]. Table 4 sorts the systems that the field has built, by which sideās scheduler they are and which side they schedule. Appendix C treats granularity, several Oracles and finite capacity. Scheduler Schedules its own side Schedules the other side Oracle side the Oracleās computations: batching, paging and sharing of the state cache [16, 17, 75, 76, 18], its tiers [61, 77, 62, 37], and its placement across devices [78] when a program continues: scheduling each call by the program it belongs to [65, 66, 67], and the state of a task kept, dropped or swapped while its tool call runs [32, 33, 73], and the shared prefixes of a workflow kept or prefetched by how soon each will be used [34] Priestess side the programās own work, tools and environments: planned calls dispatched in parallel [79, 80], tool resources [67]; in PRTS, the ready queue the Oracleās work: which task enters O-mode, when, and for how long, in PRTS the slice; the strategy by which a programās calls are executed, changed by effect handlers [81]; programs that drive the generation loop and the cache inside the server [82] Table 4: Cache and scheduling: what each sideās scheduler schedules. 4.4 Safety: the Boundary Safety requires that something bad never happens [53, 54], and K1āK4 and Corollary 3.5 are safety properties. They say what an excursion and a P-mode call may touch, and how content passes between the modes. A defence must also know where content reaches control. For the duality of Oracle and Priestess there are two kinds of bad thing. Bad data is executed when the Priestess writes malicious data for the Oracle to run, or wrongly executes data the Oracle returned. A bad execution touches data when the Oracle issues a malicious system call, or the Priestess induces the Oracle to generate malicious code. Prompt injection [83] is of the first kind. Like the contract, and unlike the rest of this section, the theorem below holds for every Oracle. Theorem 4.12 (the safety boundary). For every Oracle, every program and every run of the O-2-PDA-TS, with or without budgets: ā¢ In. Whatever an Oracle call reads beyond the answers that its own mode appended to its operand, the Priestess wrote there. An O-mode transition reads only the stack its excursion entered on, which holds the answers appended to it in O-mode and what the Priestess wrote there, the initial content included. A P-mode call reads only its operand, a Priestess stack, which holds the answers of earlier P-mode calls on it and what the Priestess wrote there, the initial content included. ā¢ Out. The successorās mode and label, and whether there is a successor, depend on stack content at four kinds of transition only: the O-mode transition and three P-mode instructions. An O-mode transition depends on whether the encoder accepts the history and whether the answer yields. Its successor is in O-mode on the same stack or in P-mode at ātrap _trap. Of the P-mode instructions, a jeq depends on the top of its operand, a pop on whether its operand is empty, and an Oracle call on whether the encoder accepts its operand, whatever the answer. No content becomes a label or instruction text. Proof. In. For an O-mode transition this is K2 with Corollary 3.5, which hold with budgets by Proposition 3.7. A P-mode call on d takes Ļā”(d)Ļ(d) alone (Definition 3.3), and d is a Priestess stack. Under S an uret enters only Oracle stacks, so by K1 no excursion writes d, and, by the locality lemma and K4, d changes only by Priestess instructions with d as operand and by P-mode calls on d. Out. Immediate from the rules of Definitions 2.1, 2.5, 3.3 and 3.6. A configuration at n+1n+1 is final and a push continues at ā+1 +1, whatever the content. An uret enters O-mode on the stack it names, with the budget it names. A P-mode Oracle call continues at ā+1 +1 or at lel_e, by acceptance alone (K4). A jeq continues at its label or at ā+1 +1, by the top of its operand, and a pop continues at ā+1 +1 unless its operand is empty, when there is no successor. An O-mode transition has a successor only if the encoder accepts the history, and that successor is at ātrap _trap or in O-mode on the same stack, according to whether the answer yields or, with budgets, the budget is spent. No content becomes instruction text, since no rule writes Ī , and none becomes a label, since every P-mode label is 11, ātrap _trap, ā+1 +1 or a label written in Ī (K4). ā The two items draw one line between the two computations, a line we call the safety boundary. On the way in, the line is the Priestessās writes to an operand. On the way out, it is the trap, whose target is fixed and whose moment is decided by the Oracleās answers or the budget. The line is also the three Priestess instructions that read content, which we call the gates. The machine fixes where content crosses between the two computations, and the code at the crossing decides what may cross. Each bad thing crosses the boundary. Malicious data for the Oracle to run reaches the Oracle only in a Priestess write, the initial content counting as one. An instruction injected into a toolās result, for instance, enters a task as part of the kernelās reply. A malicious system call is an answer, and it reaches the Priestess first at ātrap _trap. Data that a P-mode call returns, including any malicious code, acts on the Priestessās control only through gates, and runs on the Oracle only after a Priestess write and an uret. A Priestess that induces the Oracle to generate malicious code does so through the operand it writes. The code comes back at the trap or as a P-mode answer, and it acts on control only through the gates. So no bad thing of either kind passes around the boundary, and a check placed there sees every one, provided the initial content is checked with the rest. The rules thus fix where complete mediation [84] must be placed. Whether each crossing is checked there is decided by the code. Proposition 4.13 (where, not which). Fix a program and an Oracle (A,E,D)(A,E,D) of the O-2-PDA-TS, with or without budgets. Let a run reach a configuration c that calls the Oracle on a history hādomā”(E)h (E): an O-mode configuration on a stack that holds h, or a P-mode configuration at an Oracle instruction whose operand holds h. Let u=Dā”(y)u=D(y) be non-empty, for some yāYAyā Y_A, and let Aā²=AāŖ(Eā”(h),y)A =AāŖ\(E(h),y)\. Then the Oracle (Aā²,E,D)(A ,E,D) has the same codec, every run with (A,E,D)(A,E,D) is a run with (Aā²,E,D)(A ,E,D), and c has a successor with (Aā²,E,D)(A ,E,D) that appends u to h. So a property of runs that holds for every Oracle with this codec holds of some run in which u is appended at c, and no such property excludes u there. Proof. The answer map grows: Oā”(w)āOā²ā(w)āOā”(w)āŖuO(w) O (w) O(w)āŖ\u\ for every wādomā”(E)w (E), so every query keeps an answer and every answer is non-empty, and domā”(E)dom(E) is unchanged. The rules of Definitions 2.5, 3.3 and 3.6 depend on the Oracle only through domā”(E)dom(E) and O, and every successor they give with O they also give with Oā²O . By induction, every run with (A,E,D)(A,E,D) is a run with (Aā²,E,D)(A ,E,D), the run that reaches c among them. At c, uāOā²ā(h)uā O (h), so the rule of the call gives a successor that appends u to h. A P-mode call continues at ā+1 +1, and an O-mode transition traps or stays in O-mode according to whether u ends with ā® and to the budget. ā Take u to be a malicious request: no guarantee that holds for every Oracle prevents it from crossing. Which request crosses is therefore a property of the Oracle on that history, a judgement over content that no rule of the machine makes. That it crosses at the boundary is a property of the machine (Theorem 4.12). A guarantee that holds for every Oracle can say where content crosses, but not which content crosses. This is all that the machine can promise to a defence outside the Oracle: the place where the defence belongs. The proposition fixes the codec, so a decoder that cannot write u does exclude it, as a property of the codec, not of the machine. A taskās boundary has two placements, as its program does. In the Agent form the Priestess is the taskās operating system, and the boundary lies in the kernel. Whatever a task reads beyond its own answers is either its initial content (the declaration included) or one of the kernelās writes (its replies among them). Whatever the task writes reaches the kernel first at the service entry, at a yield trap as a request. These are the return and the force of Corollary 3.5. That every system call is answered before the task resumes is the kernelās protocol, not the machineās, since the machine would equally resume an unanswered task. In the Workflow form no operating system mediates the task, and the boundary lies in the program: in the operands it builds and in the code that reads each answer, where validating an answer before a promotion is the programās obligation. A hybrid has a boundary for each part, and moving a task between the forms moves its boundary. When an Agent task is run through the interpreter of Proposition 3.11, its boundary lies in the interpreterās code, which then supplies what T and the locality lemma supply in the machine. Appendix E.4 examines how a harness can escalate privilege, and places the defences built for agents at the three positions that the boundary leaves them: on the way in, inside the Oracle, and on the way out, at the trap or at the gates. Treat the Oracle as a user-mode program and the Priestess as a kernel, and the Agentās boundary is the one between user mode and the kernel (Table 13, Appendix C). A task writes only its own stack, as a user process writes only its address space. Its requests enter only at ātrap _trap, as traps enter at a fixed vector. And nothing protects the task from the kernel, which is verified [55, 56] or trusted. The two restrictions on the Oracle, that it runs no instruction of its own and only appends, are not properties of user mode and do not transfer. The theorem is about runs of the machine. As security analyses do, we assume a system to start in an intended state and an attack to be a departure from it. For the Priestess, the intended state includes that its code does not execute memory the Oracle writes, except by a deliberate interpretation or promotion. In a von Neumann realization one further path leads from content to control, around the boundary: the Priestessās processor fetching instructions directly from memory the Oracle writes. No rule has such a transition, so an execution that contains one leaves the typing. Such an execution is a type bypass, an attack on the intended state. Ā§5 states the condition a realization keeps to exclude it. Appendix C discusses protections that also restrict the trusted side (such as SMEP and SMAP) and what a task can observe. It also discusses replay, which on the machine needs a rewrite by the kernel in the Agent form. The two computations are now linked where it matters for a cache. When the encoder factorizes at ā® , the encoding never backs up across a Frame. If, in addition, the Oracle is Frame-faithful and called through the Frame interface, and the kernelās writes end with ā® , the Oracle holds the encoding of the machineās history after every Frame. Under the same hypotheses, within an append-only epoch a private state cache that is never evicted computes each symbol once, under the same key as the encoding cache. Both sides are systems of one kind, and the side that holds the next keys is the Priestessās. The two meet at the boundary of Theorem 4.12, an invariant of the machine. The machine itself is still abstract, and Ā§5 builds it. 5 In Query We Compute, Agents: Building the Machine A physical O-2-PDA-TS raises three questions that the abstract machine could leave open. Who can be the Oracle: which Oracles the machine runs in O-mode, and which only in P-mode. Where the Priestess is: on what computer the Turing-complete computation runs, and how the stacks and the two modes are laid out in its memory and its processor. And how the two exchange messages: what a system call asks of the Oracle, and what the Priestess can do to make the call succeed more often. The answers to the first two make up one construction, V. It consists of the rule of who runs in O-mode (Ā§5.1), together with the segmented storage and the single Oracle instruction that make the machine compatible with a von Neumann computer (Ā§5.2 and 5.3). The O-2-PDA-TS with V is the O-2-PDA-TSV. 5.1 Who Is the Oracle? A physical machine is built for Oracles of several classes, such as language models, people and models that are not autoregressive. At each call it uses one entity of a class, a particular model with its codec. Being autoregressive inside is a property of the entity. Since the codec is ours to define, any Oracle can be given one that fits the autoregressive form the machineās transitions have when the program only appends to the stack (Proposition 2.7). But an excursion feeds the Oracle its own answers with no Priestess code between them: after an answer r on the history w, the next query is wā rwĀ· r (Definition 3.3). What O-mode runs is therefore an iteration of the Oracle on the taskās history, and that iteration is the Oracleās own computation when the Oracle is internally autoregressive, for then each O-mode transition is a Step or a Frame of the Oracleās own generation (Ā§4). At Step granularity the encoding may still back up between Steps, within the open Frame (Ā§4.1). Autoregressive Oracles. A language model is an AARA_AR Oracle: used through a conversation, it has the autoregressive form (Ā§2), and, under the assumption of Ā§4, its interior has that form too. Its output alphabet is included in its input alphabet, as Definition 4.1 requires. Without the inclusion, feeding the model its own output would produce an illegal input. Three of its properties matter to the machine. Its decoding is non-deterministic: a sampled answer is one of the possible answers, which form the set that the machine reasons about (Definition 2.4); sampling the same query again is what the replay of Appendix C.10 exploits. It is bounded. An Oracle may accept unbounded input, but under finite time and finite control the input it is given is finite. A real model, however, requires bounded input, and an input beyond the bound is rejected by the encoder (Definition 2.4). A model with bounded input is therefore at most a finite automaton [85, 86], as a real von Neumann computer is. And it can be total in the sense of Ā§2: a model returns a non-empty answer in finite time if it has a limit on its output tokens, a codec that converts the two alphabets fully and rejects over-long inputs, and no hardware or network faults. A personās speech, a monkey at a keyboard and an action-conditioned world model that generates frames autoregressively [87] may also be of this kind. An AARA_AR Oracle can run in both modes: in O-mode every continuation is a legal input under the conditions of Proposition 4.5, and in P-mode the Priestess builds each input. Non-autoregressive Oracles. An Oracle may also be non-autoregressive, and then its output alphabet usually is not included in its input alphabet. Jev, a recent commercial model from TypeSafe, returns typed probabilistic decisions [88]. Its output is JSON text that contains a well-formed probability result. Although that text can still be encoded as the next input, Jev is usually more meaningful as a non-autoregressive Oracle than as an autoregressive one. A diffusion model generates an image by iterated denoising [89]. One that also takes images as input does have ĪRāĪQ _R _Q, and its output can be fed back. But it has no internal autoregressive structure, so the analysis of Ā§4, which relies on a correspondence between internal states, has nothing to correspond to. Iterated in O-mode, the first kind leaves the encoderās domain whenever an answer does not yield and contains a symbol outside Ī£Q _Q, and the machine stops being good (Proposition 5.1(1)); the second iterates a function that is not its own transition. In P-mode neither problem arises, since the Priestess builds every input. Proposition 5.1 (goodness depends on the codec). Let (A,E,D)(A,E,D) be an Oracle with domā”(E)=Ī£Qādom(E)= _Q^*, run in O-mode from histories in Ī£Qā _Q^*. 1. If a reachable O-mode transition that does not trap appends an answer that contains a symbol outside Ī£Q _Q, the next query is rejected: the machine faults, and it is not good. 2. If ā®āĪ£Rā©Ī£Q ā _Rā© _Q and |Ī£R|ā¤|Ī£Q|| _R|ā¤| _Q|, let Ļ:Ī£RāĪ£QĻ: _Rā _Q be injective with Ļā”(ā®)=ā®Ļ( )= . The wrapped Oracle (A,E,ĻāD)(A,E,Ļ D) makes the machine good, whatever A. 3. The wrapped Oracle is internally autoregressive exactly when (A,E,D)(A,E,D) is. The proof is in Appendix B. So any Oracle that meets the conditions of item 2 can be wrapped to make the machine good. What the wrapping cannot change is the interior. For an AnARA_nAR Oracle the wrapped iteration runs, but for the two kinds above it achieves little: the first loses the meaning of its answers and the second iterates a function that is not its own. So V runs only AARA_AR Oracles in O-mode, and P-mode may call any Oracle. The constraint protects no part of the contract or of the safety boundary, which are invariants of the machine (Theorem 3.4, Theorem 4.12). What it keeps is that O-mode iterates the Oracleās own computation, so that the link through the codec and the cache model of Ā§4 apply to every task the kernel enters. Its price is that an AnARA_nAR Oracle is called only in P-mode, and so is a person, unless a mechanism of generation is declared for the person (Ā§5.4). Ā§5.3 makes this a rule of the processor. 5.2 Memory: Stacks as Segments We build the machine on a von Neumann computer: we split the Oracle stack and the Priestess stack into as many stacks as needed, and lay them all out on one random-access memory, each in a segment of its own and each with the colour of the stack it was derived from. On two stacks a random access costs moves of the head, whereas here it costs one access. Abstract machines have been built physically, as Forth chips were [90], yet most real computers are register machines with random-access memory. Other computing units, from an ALU to an accelerator, are attached to them as coprocessors. For an interpreter, which runs a stored program by a fetchādecodeāexecute loop, register designs need fewer dispatches than stack designs [91]. Random-access memory reaches any address directly, without passing over the cells between [51]. Definition 5.2 (segmented realization). Let MemMem be a random-access memory. ā¢ A layout assigns to each stack s a segment [bs,bs+s)[b_s,b_s+cap_s) of addresses, with capacity scap_s, and a length register slen_s. The segments are pairwise disjoint, and disjoint from the code segment, which contains the program, stored as in a von Neumann machine (Ā§2). ā¢ A memory state realizes a store Ļ if, for every s, s=|Ļā”(s)|ā¤slen_s=|Ļ(s)| _s and Memā”[bs+i]=Ļā(s)iMem[b_s+i]=Ļ(s)_i for every i<si<len_s. ā¢ The realized Oracle rules are those of Definitions 2.5 and 3.3 with bounded appends. The query on s is the word Memā”[bs],ā¦,Memā”[bs+sā1]Mem[b_s],ā¦,Mem[b_s+len_s-1]. An answer r is written at bs+sb_s+len_s, and slen_s grows by |r||r|, only if s+|r|ā¤slen_s+|r| _s. Otherwise the append is refused and writes nothing, and the realization raises an exception: in O-mode a trap to ātrap _trap, in P-mode a jump to lel_e, with a cause the kernel can read. A stack s thus has three pointers: its base bsb_s, its top bs+sb_s+len_s and its limit bs+sb_s+cap_s. The code is not a third colour, and no Oracle rule writes it. The hardware checks an operation against the window it is given, but the disjointness of the windows is a property of the layout, which the kernel chooses. Proposition 5.3 (segment locality). Every realized Oracle step writes no memory cell outside its operandās segment and changes no length register but its operandās, or writes nothing. If a memory state realizes Ļ and the append of an answer r on s fits, the memory state after it realizes Ļ[sā¦Ļ(s)ā r]Ļ[s Ļ(s)Ā· r]. Proof. A write happens only after the check s+|r|ā¤slen_s+|r| _s, and it then spans the addresses bs+s,ā¦,bs+s+|r|ā1b_s+len_s,ā¦,b_s+len_s+|r|-1, inside the operandās segment, and sets slen_s to s+|r|=|Ļā”(s)ā r|len_s+|r|=|Ļ(s)Ā· r|. The segments are disjoint, so no other stack changes, and the cells written are exactly the new cells of Ļā”(s)ā rĻ(s)Ā· r. ā This is the locality lemma (Lemma 2.6) in memory: on two stacks it needed the construction of Lemma 2.2, and with a layout it is a bounds check, which the hardware performs. With it, K1 carries over to a realization as the statement that an excursion writes only inside its taskās segment, provided that the kernel chooses a layout whose segments are disjoint. K2, K3 and K5 apply to the O-mode rule and the Oracle rules and carry over in the same way, as does the first part of K4, on the P-mode call. In a real instruction set, Priestess instructions address memory directly, so for the Priestess locality holds only as a property of its code, as it does for every kernel. The rest of K4, that every P-mode label is literal, does not carry over, and the fetch condition below says what replaces it. The machineās stacks have no fixed capacity. A particular Oracle bounds its input through its encoder, and a realization bounds its segments. In the same way a real computer (a finite automaton) bounds an ideal von Neumann machine, which is Turing complete. The machine uses a segmentās capacity only through Proposition 5.3: an append that does not fit writes nothing outside its segment. What the kernel does next is its policy: it may grow the segment and call again, end the task, or compress the context. On random-access memory the isolation of Ā§3 needs only a simple layout, which allocates O-mode its own space for Oracle stacks and uses the space of Priestess stacks in P-mode. On a current processor this layout is virtual memory. A page fault during an Oracle call can be handled in two ways. One is a second page table for Oracle segments with a delegated handler, which is little used and costly. The other uses Priestess addresses with enough memory committed before each call, so that no fault arises and an answer that does not fit raises an exception that the Priestess handles. The second is simple and reuses existing hardware and software. When the Oracleās computation needs little memory, lazily committed pages make a large segment cheap, and on overflow the segment grows like a vector and the call is retried. The fetch condition. Corollary 3.5 is a statement about the rules: content crosses between the modes only by a force or a return. On a von Neumann machine, code and data share one memory, and the program counter can be set from data, so a realization has to separate code and data. The realized Oracle rules set the program counter only to the next instruction, the rejection label or ātrap _trap, and write only inside the operandās segment, which is disjoint from the code segment (Proposition 5.3). Both are properties of the rules, which the hardware implements. A third condition is the kernelās obligation: no instruction may be fetched from a segment that an Oracle rule can write. We call it the fetch condition. Page permissions that prevent memory from being both writable and executable are the usual way to keep it, and an execution that breaks it is the type bypass of Ā§4.4. In the abstract machine, K4 holds without conditions, because jumps encode literal labels and no rule writes the program. A real instruction set, however, has indirect jumps, so Priestess code can compute a jump target from data, for instance from a jump table indexed by an answer. Priestess code decides for itself which code it reaches that way, on the same footing as promotion (K4). It also decides whether to write the code segment, as a JIT compiler does. The fetch condition restricts which segment an instruction is fetched from, not how its bytes got there: code that the Priestess has written into the code segment is fetched legitimately, and an Oracle-writable segment is never fetched from. What a realization preserves of the rest of K4 is therefore that no Oracle rule sets the program counter from an answer, and that no instruction is fetched from where an Oracle rule writes. 5.3 Control: One Instruction, No Code The program-style 2-PDA has, in structure, the fetchādecodeāexecute form. It reads a program from a tape, and that tape need not be a stack. With the program in the code segment and a program counter, it is a stored-program computer. With the privilege separation of Ā§3, the processor gains an O-mode beside its P-mode, stored in a privilege register or descriptor. P-mode contains the processorās existing privilege levels. Both modes can execute the Oracle operation, and they differ at a yield: in O-mode a yield traps to ātrap _trap, while in P-mode the instruction simply completes. The memory of O-mode is a stack that only grows, so it can be given stack space as a user process stack is, with a base, a top and a limit. The memory of P-mode follows the virtual-memory view of the processor and the operating system, and a P-mode Oracle operation is given a contiguous region on the stack or the heap, with the same three pointers. On the tape, the Oracle operation reads a contiguous region and writes new symbols next to it. On a real instruction set, a call returns its answer to a register, and continued autoregressive transitions could then be written as an Oracle call, a push and a few jeq, as the interpreter of Proposition 3.11 does. That has three costs. (a) The answer must first be written to storage other than the history. In O-mode, which runs no instruction of its own, that storage would be outside the task stack, and K1 would have to count it as part of the task stack. (b) An Oracle transition should be atomic. A trap in the middle would leave part of an answer in the history, a state that means nothing and that K1 and the append-only epoch of Ā§4.2 would have to admit. (c) If O-mode ran code of its own, that code would put a programmable state machine on top of the Oracleās autoregression, and what O-mode runs would no longer be the Oracleās own transition. Insight 1. For a physical O-2-PDA-TS the Oracle operation is one instruction. In O-mode there is no program form: the processorās fetchādecodeāexecute loop drives the transitions, deciding each with no code. In P-mode the same instruction is called like any other, and it can drive an asynchronous transfer. This is close to the intuition of operating-system design. O-mode is a privilege level whose transitions are computed by the Oracle, a computation that the Priestessās instructions need not be able to perform. Its rights are also the most restricted: it runs no instruction of its own, and it only writes new data, never changing existing data. Fine-grained control of O-mode therefore is implemented in the processorās microarchitecture or microcode. Concretely, in P-mode the instruction is called on an operand segment, given by its three pointers, and completes with the answer appended. In O-mode the fetchādecodeāexecute loop queries the whole task segment, appends the answer, tests for the yield symbol, and traps to ātrap _trap at a yield or when the budget runs out (Definition 3.6). Writing that loop as Priestess code instead is the interpreter, whose guarantees are those of its code. The machine is synchronous, and its answers are whole at the granularity of the interface. A realization chooses how it publishes a whole answer (including on an exception) and whether it departs from the machineās synchrony (Ā§6). The O constraint. The instruction applies the conclusion of Ā§5.1. The processor executes the Oracle operation in O-mode only for an AARA_AR Oracle, and refuses it for any other. In P-mode it executes the operation for every Oracle. Whether an Oracle entity is an AARA_AR Oracle is part of the interface it declares to the processor. Ā§6 shows how ArchNights declares it. Insight 2. The reading of Ā§4.4, which takes the Oracle as a user-mode program and the Priestess as a kernel, is also a design heuristic. It says what to copy from existing processors: ā¢ the Oracle segment, with its base, top and limit, is managed like a user stack; ā¢ the yield trap to ātrap _trap is a fixed trap vector, like a system call; ā¢ uret returns into O-mode as an xRET returns into a lower mode;11 1 By the RISC-V convention an xRET is named after the mode of the trap handler it returns from [41]. A realization that puts O-mode just below user mode, as ArchNights does (Ā§6), handles a yield trap one level up, in user mode, hence the name uret. The ratified manuals define no instruction of that name [40, 41]. ā¢ the Priestess does not execute memory that O-mode writes, as SMEP keeps a kernel from executing user pages [92] (the fetch condition). As Ā§4.4 noted, the two restrictions on the Oracle do not transfer. The Priestess computation (its arithmetic, logic, control transfer, data transfer and system instructions) can reuse a modern von Neumann processor entirely. For analysis, its instructions can be simulated by the 2-PDA in small steps, or treated as hardware black boxes in big steps. 5.4 Oracle-Priestessās Message O-mode acts on P-mode by a system call, a yield trap that forces the service entry k; P-mode acts on O-mode by a return, its reply (Corollary 3.5). The Priestessās reply is written by its code, but the request is what the Oracle writes, and the kernel serves it at ātrap _trap. A correct system call becomes possible when the kernel places the declaration Ī“Ī _ on every task stack. It does not make a correct call certain: whether the Oracleās answer lies in LĪL_ is a property of the Oracle on that history, and the kernel contract holds whatever the answer is. With current Oracles the outcome also depends on sampling and on attention, and longer histories have costs. In the settings tested, accuracy depends on where the relevant information sits in the context. It is highest at the beginning or the end and lowest in the middle, long-context models included [93]. For calls in particular, accuracy falls with the length of the conversation and of the toolsā responses [94]. The general form of these observations is that the longer an autoregressive Oracleās history, the less likely its next call is correct. We take it as a working hypothesis, the Lynchpin hypothesis. It is not a result of the machine, and nothing below depends on it except to motivate semantic delegation. Why it should hold, and under which conditions, is not understood; Appendix E.8 reviews the evidence and the theories that may bear on it. One remedy is to make fewer calls, packing several requests into one so that one system call suffices. In principle the packing happens in O-mode, but when the semantics of the packing is blockwise, it can be moved to P-mode. Insight 3. When a system call needs the result of a computation, that computation reaches the Priestess either as a value or as a name. Without delegation it is evaluated before the call, on the Oracle side. The Oracle can be asked to compute anything, and it computes from its history: an interface that asks the Oracle to compute inserts the computationās definition into the history as text and evaluates it in place. The call then passes a value to the Priestess (call by value), and the history grows by the definition and by every intermediate step. A semantic delegation call passes instead how the value is to be computed, a computation the Priestess evaluates when the call forces it (call by name). The machineās force expands nothing into the history: it enters the kernel, which evaluates the computation in P-mode and appends only its result, and the handlerās code never appears there. Semantic delegation is a design choice, motivated by the observations above. Each packed operator has the obligation to perform the same services as the sequence of calls it replaces. What returns to the task must be what the sequence would have produced, while the history may differ and is shorter. Ā§6 describes a system library that implements such operators. Language models are the autoregressive Oracles that produce requests today. Any autoregressive Oracle whose alphabet admits a semantics can in principle produce requests under that semantics; what they mean is fixed by the semantics, not by the alphabet. For example, a vision-language-action model is autoregressive inside, and its actions reach P-mode as requests that control a robot [95, 96]. This answers the question of the Introduction. As Oracles, a person and a language model are alike, provided a proper semantics can be defined for parsing the personās words. What separates their outputs is how each is called. Under the assumption of Ā§4, a language model is an AARA_AR Oracle, declares it, and may run in O-mode, where its answers continue the program that is the taskās history. A personās output is usually taken as data: a person is usually called in P-mode, and running one in O-mode would need a declared mechanism of generation in the sense of Definition 4.1. The O-2-PDA-TSV is then complete: its stacks are segments of a von Neumann memory, its Oracle operation is one instruction with no code in O-mode, O-mode runs only AARA_AR Oracles, and the two sides pass messages by force and return. It fixes what a realization must preserve, and leaves asynchrony, finite capacity and context compression to the realization. Ā§6 builds one. 6 ArchNights: Implementation on gem5 ArchNights (Agent Runtime arCH iN Gem5 arcHiTectural Simulator) is a prototype machine that follows the O-2-PDA-TSV on gem5 [38, 39] (Figure 2, right). In gem5ās syscall-emulation (SE) mode the host intercepts the system calls of the simulated program, and in its full-system (FS) mode the whole system is simulated. ArchNights-SE runs in the first. ArchNights-FS is a design for the second; it has not been built, and it has not been validated. Both share one instruction set and one distribution, and differ in the kernel, PRTS or ZOOT. Where the machine fixes a behaviour, ArchNights implements it (Ā§6.1). Where it leaves a choice, ArchNights mostly takes Linuxās, and what is new is the set of operators that the system library offers to the Oracle, together with the choices that ArchNights makes for the three questions Ā§5 left to a realization: asynchrony, storage of finite capacity, and context compression. 6.1 What ArchNights Keeps of the Machine What a realization keeps In ArchNights Lost if it fails Ia. Rules kept by the processor, whatever the kernel: K1āK4, Corollary 3.5, Theorem 4.12 I-1 An Oracle operation appends only inside the window it is given, and an answer that does not fit is refused and writes nothing (Definition 5.2, Proposition 5.3) the controller checks the window before evaluation; an answer that does not fit is refused at publication; the descriptor lies inside the window, past the top, so it changes no store realized K1 I-2 O-mode fetches no instruction and has no addressable code (Definition 3.3, Insight 5.3) the Oracle mode, run by microcode K1, K2 I-3 Each transition, a Step or a Frame, is published whole, and an exception publishes no part of one (Ā§5.3) the controller publishes after evaluation; an exception keeps only what was published before it K1, whose appends are whole answers I-4 Control leaves O-mode at a place that no answer can select (Definition 3.3) uret completes, and the processor continues at the next instruction, with the cause in the destination register K3 I-5 A P-mode operation continues at the next instruction whatever its answer, and no Oracle operation sets the program counter (Definition 3.3, Ā§5.2) STEP or RUN in P-mode, issued by ask, by the session reading a line from the person and by the summary of a swap; a rejection shows in the status, and a branch on it is the programās own, as a jeq is the first part of K4 Ib. Rules a realization moves to the kernel, kept by PRTS by design I-6 The layout realizes S: segments are pairwise disjoint and disjoint from the code, and the kernel enters with uret only the segment of a taskās history (Definitions 3.2 and 5.2) one segment per history in the memory descriptor, reserved when the task is created K1 (Proposition 5.3); S I-7 The fetch condition: no instruction is fetched from a segment an Oracle operation can write (Ā§5.2) history segments are mapped readable and writable, not executable, and the kernel never directs the program counter into one the rest of K4; a break is a type bypass I-8 No page fault during an Oracle operation (Ā§5.2) before each entry the kernel commits the pages the operation may write a fault inside a transition, a path the machine lacks I-9 One runner: a task is in O-mode on at most one processor, and no processor writes it meanwhile (Appendix D) trivial in ArchNights-SE, with one dispatch point on one processor; a scheduler invariant for a kernel on several processors, not yet built Corollary 3.5, P to O only by a return; K1 I-10 One trap label: the kernel issues uret at one place (Definition 3.3) PRTS issues it from one function, which its dispatch loop calls K3 holds at each place, not at one I. The return of control: K5 (Proposition 3.7) I-1 The budget is checked at the boundaries of transitions, Steps or Frames, and counted in the Oracleās steps (Definition 3.6) the controller; the budget is soft, and an Oracle that offers only RUN overruns it by at most the Frame it is in the bound of K5 I-2 A fault ends the operation and traps, in place of a good machine (Definition 3.3) and a total Oracle (Ā§2.3) every exception of a unit reaches the kernel at the entry of a yield, with its cause in the destination register (Appendix D.3) K5 on a machine that is not good Table 5: What a realization of the O-2-PDA-TSV must keep, and where ArchNights keeps it, by design: layers I and I, the behaviours the machine fixes. The rows are grouped by what is lost when one fails, and the last column names the result that then no longer carries over to the realization. What a realization keeps In ArchNights Lost if it fails I. Hypotheses of the conditional results of Ā§4, which the machine does not fix I-1 O-mode runs only AARA_AR Oracles, the O constraint (Ā§5.1 and 5.3) PROBE reports it, and O-mode operations on other Oracles are refused the cache model for that task, not the contract I-2 The encoder accepts every word over Ī£Q _Q, Ī£RāĪ£Q _R _Q, and the kernel writes only words over Ī£Q _Q (Proposition 4.5) not met by a language model: its input is bounded (Ā§5.1), and some histories, such as a request without its reply, fail to encode a good machine, which I-2 replaces for K5 I-3 Append-only epochs: within one, the kernel changes a history only by push (Ā§4.2) kernel code changes a history only through push, pop and its metadata, and a direct write, not prevented, is undefined behaviour; exec, a swap and a back-off start new epochs Proposition 4.10; the coherence of the encoding cache I-4 Every word the kernel pushes onto a history ends with ā® (Proposition 4.10) kept for an Oracle with STEP disabled, which is called through the Frame interface Proposition 4.10 I-5 The encoder factorizes at ā® , and the Oracle is Frame-faithful (Definition 4.3, Theorem 4.4) not claimed: properties of each Oracle and its codec, which ArchNights-SE does not yet analyse (Ā§8) the Frame-boundary case of Proposition 4.9; Proposition 4.10 IV. Choices the machine leaves to the kernel, made by PRTS IV-1 Every request is answered before its task runs again, the kernelās protocol (Ā§4.4) the scheduler preempts only before an Oracle operation, and serves every call of an answer first no result of the machine IV-2 The library: the declaration Ī“Ī _ on every task stack, and requests outside LĪL_ handled as errors (Definition 3.8) the first record of every history, generated with the check from one table of operators; an error reply that names what was wrong no result of the machine IV-3 Services that rebuild a history, through which a query can recur (Ā§4.2, Appendix C.10) fork builds the prefix tree; exec and a swap start new epochs, a swap only at a quiet point; a replay policy can limit them no result of the machine IV-4 One identifier for a task on both sides (Ā§4.3) uretās registers tag each Oracle operation with the process identifier no result of the machine Table 6: Layers I and IV: hypotheses of the conditional results of Ā§4, which the machine does not fix, and choices it leaves to the kernel. The columns are those of Table 5. We say that ArchNights implements the O-2-PDA-TSV in this sense: for every behaviour the machine fixes, Table 5 names the obligation it puts on a realization and where ArchNights keeps it; for every hypothesis of a result that holds only under it, Table 6 states whether ArchNights meets it; and where the machine leaves a choice, ArchNights makes one. The verb realizes is that of Definition 5.2, where a memory state realizes a store. By design, and informally, we extend it to the rest of a configuration and to transitions. A state of ArchNights realizes a configuration when its memory realizes the store, the processor is in the Oracle mode exactly when the configuration is in O-mode, and in O-mode the registers of uret describe the task stack u and its budget. Definition 5.2 lays a stack out growing up. A segment may as well grow down: which way it grows is an arbitrary choice, fixed in O-mode by the systemās configuration, as the direction of a process stack is fixed (Appendix D). An Oracle operation that publishes an answer realizes an Oracle transition, a Step or a Frame; uret realizes the entry, and its completion the trap. Priestess code between them is taken in big steps, as a black box (Ā§5.3). We claim no simulation between ArchNights and the machine. A refinement would be a separate undertaking, and on this machine a delimited one. Its abstraction is the relation realizes above, with Priestess code taken in big steps, and each row of layers I and I of Table 5 is a lemma it must prove. The results that it would carry over hold for every Oracle, so it would cover the processor and the kernel, and never the Oracle. The obligations are derived from the machine, not from ArchNights. Each transition rule says what a realization must not do: an O-mode transition only appends to its stack, so an Oracle operation writes nothing outside its window. Each result says what it takes from the rules, and that is what a realization has to supply: K4 requires jumps to literal labels and a program that no rule writes, and a von Neumann computer replaces them by the fetch condition. And each path that a realization has and that the machine lacks is eliminated, absorbed into a transition the machine has, or left outside the model. A page fault during an Oracle operation is eliminated, an indirect jump is the Priestessās own decision, as a promotion is (Ā§5.2), and a clock is outside the model. Tables 5 and 6 group the obligations into layers by what is lost when one fails. Layers I and I are the behaviours the machine fixes, and they carry the kernel contract, the crossing invariant and the safety boundary over to a realization. The first five rows fall to the processor, whatever kernel runs on it. The next five depend on what the kernel does with the processor: its layout (which realizes S, because the hardware knows no colours), its page mappings, where it dispatches tasks and where it issues uret. A realization moves them from the rules to the kernel (Ā§5.2), so on ArchNights they carry over only on a kernel that keeps them, and PRTS keeps them by design, not by proof; on the machine they hold for every kernel. Layer I lists the hypotheses of the results of Ā§4 that hold only under them. The machine does not fix them, and a refinement would extend only to the kernelās part of them; the rest are properties of an Oracle and its codec. Layer IV lists the choices the machine leaves to the kernel, which PRTS makes. One row departs from the machine. ArchNights is not a good machine in general: a language model accepts only bounded input, and its encoder rejects a history that outgrows the bound, or one it cannot accept, such as a request without its reply (Appendix D.3). ArchNights keeps the return of control by absorbing faults instead (row I-2). In O-mode every exception of an Oracle unit ends the operation, publishes no part of a transition (row I-3), and reaches the kernel at the same entry as a yield, with its cause in the destination register. On the machine, this adds an O-mode transition that, when the encoder rejects the history or the Oracle fails, goes to ātrap _trap and leaves the store as it was. Every trap still goes to ātrap _trap and no O-mode transition writes outside u, so the proofs of K1āK4 and of Corollary 3.5 apply unchanged. Every O-mode configuration then has a successor, which traps or lowers the budget, so K5 holds without the hypothesis of a good machine. The tables end where the machineās model ends. K5 bounds transitions, not time, and the machine has no clock, so the latency of a call, a channel that a realization adds, lies outside the model (Appendix C), as do the side channels of speculation. The machine has one processor, and concurrency enters it only as far as row I-9 brings it back to the synchronous semantics. Its statements are about sets of possible runs, not their probabilities, and it says nothing about the Oracleās interior (a retry inside a unit included), of the finite capacity of caches, or of users inside the Priestess. None of these yields an obligation (Ā§8). 6.2 The Instruction Set The instruction set of ArchNights extends the RV64 ISA [40, 41] with a privilege level, the Oracle mode, below user mode; the instruction uret that enters it, with the registers and descriptors that go with it; and the Oracle instruction, which performs the Oracle operation (Table 7). The Oracle mode realizes O-mode and has no addressable code: in O-mode the processor fetches no instruction, and its fetchādecodeāexecute loop drives the Oracleās transitions, as Insight 5.3 requires. ArchNightsā simulated processor runs the Oracle mode in its microcode. Instruction Encoding Operands What it does PROBE custom-0, R-type none reports the profiles the unit implements, whether answers carry a descriptor, and what the bound Oracle can do STEP custom-0, R-type a segment, its top and a bound on what one step may write in P-mode, one step of the Oracleās own autoregression, appended past the top RUN custom-0, R-type a segment, its top and a budget in P-mode, a Frame, appended past the top ecall none; O-mode fetches no instruction none absorbed into O-modeās transitions: an answer that ends with the yield symbol traps to the kernel as an ecall would uret custom-1 none enters O-mode on the task its registers describe; completes when the excursion ends Result the destination register how the operation ended, how many of the Oracleās steps it took, how many bytes it published Table 7: ArchNightsā Oracle instructions. The Oracle instruction. The Oracle instruction is a RISC-V custom instruction whose interface is compatible with RoCC, Rocket Chipās interface for custom coprocessors [42]. It is an R-type instruction in the custom-0 opcode space, and its fields select the operation, the direction in which the stack grows, and a profile that fixes the widths of the fields packed into the registers (Appendix D). Each operation is self-contained, fixed by the instruction and its two source registers, so a context switch has nothing of the unit to save. The operand is a segment with the three pointers of Ā§5. The instruction reads the content, writes the answer past the top, and never changes what is already there. A descriptor written past the answer, and not counted in its bytes, records the Oracleās own measures (for a language model, the numbers of input and output tokens). STEP and RUN are the two granularities of Ā§4: RUN generates one Frame, and STEP performs one step of the Oracleās own autoregression, aligned with its internal state, so that a debugger on the Priestess side can single-step the Oracle. PROBE reports what the bound Oracle can do, including whether it is internally autoregressive, which decides whether it may run in O-mode. This report is the declared interface of the O constraint. An O-mode operation on an Oracle that does not allow it is refused before evaluation, as is a STEP on an Oracle that has none. Entering and leaving O-mode. uret takes no operands, as an xRET takes none. The task it enters is described by the registers that go with it: the taskās segment with its top, the budget and the Oracle entity to run. The kernel writes them before entering a task, and they tag each of the unitās operations with the taskās identifier, so that one identifier serves both sides (Ā§4.3). uret is synchronous: it completes when the excursion ends (at a yield, when the budget is spent, or on an exception), and the destination register records which. The processor then continues at the instruction after that uret. That instruction plays the part of ātrap _trap: the kernelās code there is the service entry. Its address is fixed by the kernelās code, and no answer of the Oracle can select it (K3). Where Insight 5.3 has one trap vector, ArchNights resumes after the uret that entered the task. A kernel thus has one entry for each site where it issues uret. PRTS issues it from one function, which its dispatch loop calls, and so has one entry, as Definition 3.3 has one ātrap _trap. The budget and the Oracle unit. The budget is counted in the Oracleās own steps, which for a language model are output tokens. It is soft: the unit checks it at each boundary where it can hand control back, which is after a Step for an Oracle that offers STEP and after a Frame for one that offers only RUN. Under Definition 3.6, each such boundary is an O-mode transition, and the excursion traps at the first boundary after the budget is spent. An Oracle that offers only RUN is therefore preempted between its Frames, never inside one, and overruns its budget by at most the Frame it is in. In hardware an Oracle is a separate unit, and a processor may have several. A unit has the encoder, the compute part and the decoder of Definition 2.4, together with a controller. Before evaluation, the controller checks each operation against its window and against what the Oracle allows; after evaluation, it publishes the answer whole. An operationās result in the destination register reports what the operation has published, also when an exception ends it. An answer that does not fit is refused and writes nothing (Proposition 5.3). Each part may raise exceptions of its own, from an illegal argument to the loss of a modelās service (Appendix D.3). Apart from the budget trap, they are what a real Oracle adds to the machine, in which the Oracle is total and faults were set aside in Ā§3. In ArchNights they end the operation and reach the kernel at the same entry as a yield, with the cause in the destination register. ArchNights implements two classes of Oracle. The entities of the LLM class are language models, which are AARA_AR Oracles (Ā§5.1). The Human class is a person at the terminal. It is called in P-mode, and its answers are lines of text that arrive one character at a time. Synchrony. The Oracle operation in ArchNights is synchronous, as an Oracle transition is one step of the machine: while it runs, the unit is occupied, and so is the CPU that issued it. An asynchronous realization can preserve that semantics and implement the asynchrony in the microarchitecture, behind an abstraction of simultaneous multithreading [97], or in the operating system, provided no task is in O-mode on two processors at once. 6.3 PRTS: the Kernel of ArchNights-SE PRTS (Primitive Reference of agenTic System), booted by its firmware, provides the system calls of the simulated machine, and its design follows Linux [98]. Its core does not depend on the Oracle: code that does is a driver for the Oracleās class, instantiated for each entity, and the semantic delegation calls of Ā§5 are loaded into the kernel as modules. By design PRTS runs in P-mode, where it issues uret and serves each yield trap at the instruction after it. ArchNights-SE realizes P-mode by the user mode of the simulated processor, in which gem5ās SE mode runs every program. The services that touch the hostās resources are system calls that gem5 intercepts and the host serves in place of a supervisor. PRTS keeps the Unix philosophy that everything is a file [99], but wraps its descriptors in strings. A task names each file it opens and refers to it by that name. The name stands for a concrete file to the Oracle and for a single descriptor to the kernel, and it is usually harder to mistake for another argument of a call than a number is. Below, we discuss the parts of Linux that a machine with an O-mode changes. Process and execution. Four parts of Linuxās process management change on a machine with an O-mode: the process itself, fork, exec and the scheduler. A process is a history. A program in ArchNights is text, and the Oracle runs it by continuing a history. PRTSās task_struct has two halves. The Oracle half is the task stack, the history the Oracle runs. The Priestess half is what the kernel keeps for the task: its descriptors, working directory, credentials and scheduling state. The Oracle reaches the Priestess half only through the interface (its own arguments and environment, for instance) or not at all. One process identifier names both halves (Ā§4.3). The memory descriptor, m_struct, gains the historyās segment. The segment is reserved with its three pointers when the task is created, and committed lazily: before each entry the kernel commits the pages the operation may write. This is the second scheme of Ā§5, in which the segment occupies the Priestessās virtual addresses and no page fault arises during an Oracle call. The segment is mapped readable and writable but not executable, and the kernel never directs the program counter into it, which keeps the fetch condition. Kernel code changes a history only through push, pop and the operations on its metadata. Reading or writing a historyās memory directly is not prevented, but is declared undefined behaviour. Fork. PRTSās fork copies the Priestess half as Linuxās does, without the credentialsā administrative rights and with fresh scheduling state, and copies the history into a new segment. Both tasks then receive a reply to the same request: the parent receives the childās identifier, and the child receives zero. Forkās double return is here two returns to one force, and the childās history is the parentās up to that request, followed by its own reply, so fork is a kernel service that builds the prefix tree of Ā§4. If the answer that called fork contained other calls, they are cancelled in both tasks, since otherwise each would be served twice. In place of inherited pipe ends (Appendix D.2), fork creates a result channel. The child holds the write end, which never blocks, and the parent holds the read end. Nothing the child writes reaches the parentās history unless the parent reads it. Exec. Linuxās exec lays out an address space and an initial stack; PRTSās exec lays out a history. The loader reads one of three inputs: a text file, a directory with the programās text and a list of the libraries it uses, or a saved history. It frees the old history and builds a new one, whose first three records replace the initial stack. The declaration lists the operators the taskās credentials allow, as the auxiliary vector says what the system offers. The system record holds the systemās conventions, the programās text and the declarations of the libraries it names. The user record holds the programās path, arguments, working directory and standard streams. A saved history is loaded as it was, with a fresh declaration, so that every history declares exactly the operators its kernel serves. As in Linux, exec keeps the process identifier, the working directory and the descriptors not marked to close on exec, keeps only the administrative rights its caller hands on, and on failure leaves the old program in place. The new history begins a new prefix chain, and shares with other histories only its first records. The scheduler. PRTSās scheduler is the Priestess-side scheduler of Ā§4.3. From one ready queue at one dispatch point, it chooses the task to enter with uret and the slice to enter it with, which is the budget. A slice is counted in the Oracleās own steps, which the unitās descriptor reports, and the cost of a taskās P-mode calls (a read from the terminal, or a question to another Oracle) is charged to it as well. A task that blocks keeps what is left of its slice, which is refilled only when it is used up, and a task that wakes joins the end of the queue without preempting the one that runs. When no task is ready, the kernel idles until the next sleeper wakes, and when no task is left, it shuts the system down. Preemption happens only before an Oracle operation, and a task whose answer carries calls has all of them served before it can be preempted, so every request is answered before its task runs again, as the kernelās protocol of Ā§4.4 requires. Because the Oracle operation is synchronous, a read from the terminal blocks the whole machine until the person answers. A shell about to read the terminal therefore yields while other tasks are ready, and the personās input has the lowest priority. Exception handling. An exception is handled as close as possible to where it arises, by the side that can handle it, and the machine admits an exception into a task in only one way. O-mode has no program counter, so it has no handler to jump to and no signal can be delivered into it. By the crossing invariant, the Priestess reaches a task only by a return. If the Oracle is to know of an exception, the exception must therefore reach it as content appended to its history. The Oracle sees an exception exactly when the Priestess sends a notice, and the Priestess sends one when the Oracle can act on it, as on most errors in the arguments of a system call. Other exceptions are handled in the Priestess, and the task is not told (Appendix D.3). Communication between tasks keeps to the same rule: content from other tasks enters a history only through an explicit, bounded read by the task that owns it (Appendix D.4). Virtual file system. In SE mode the guestās file-system calls reach the hostās file system directly, so PRTS gives O-mode a virtual one. At boot a folder of the host is mounted as the root, and other directories, a workspace and a temporary directory among them, are mounted beside it. Like Unix with its ordinary user and root, PRTS has two O-mode users: an ordinary user (identifier 1000) and a privileged user (identifier 0). Access is checked by Unixās discretionary access control, so that with the ordinary userās rights every program operates only on the virtual file system. Only the privileged user may escape it, through the hostās shell Bash. The way to the privileged user is sodo, a core tool of the distribution (Appendix D.5). The hostās shell is outside the machine, and to the machine it is an Oracle: it is called in P-mode, and its answers are data (K4). Checkpointing system. The checkpointing system saves a taskās history, with a metadata file that describes the task, as a folder that the loader can load. It supports recovery from faults, debugging and swap, and for debugging the metadata may also record a limited part of the taskās P-mode state. For recovery, a process ended by an unrecoverable error is saved as a checkpoint, and swap compresses a history that its Oracle can no longer accept. Loading a checkpoint gives a new task a history equal to an old one, so it is one of the kernel services through which replay can be constructed, and a replay policy can limit it. A history does not swap as a page does: a page is swapped out whole and faults back in when it is touched, but the Oracle reads its whole history at every step, so no part goes untouched. What can be swapped is a part the Oracle no longer needs to read every time. The kernel swaps at a quiet point, when every request has its reply, so that no request is cut off from its reply. It keeps the head and the tail. The head consists of the declaration and the first records and says what the task is, and the tail runs from the last answer on and says where it is. The middle moves to a checkpoint, and in its place the kernel leaves a short note. The note is a thunk of the memory moved out: it records what was there and where it went, and each entry of the note records the location of its checkpoint, so bringing one back takes the Oracle a single read, a force prepared in advance. The compressor either keeps everything but the chain of thought, a removal by the kernel in the sense of Appendix C.9, or summarizes the middle with one Oracle call in P-mode, which states what the task is, what has been done (with its exact facts) and what is left. That call is the kernelās own, and its answer is data (K4) that enters the history only because the kernel writes it. This is the context compression the machine left out, and Ā§4 names its price: a swap rewrites the task, the append-only epoch ends, the prefix chain breaks after the head, and the caches keyed by the old history serve nothing past it. So the policy, a module of the distribution, swaps rarely, at a threshold, and not again until the history has grown well beyond it. 6.4 The Distribution ArchNights has a usable distribution: the PRTS kernel, a system library, an init system, a shell and core tools. It is designed to be reused across kernels: PRTS is meant to be replaceable by ZOOT with only the system libraryās kernel module reinserted. Its library and programs each have two parts: programs that run in O-mode and do not depend on the kernel, and delegation calls that run in P-mode. The kernel and the system library together are the operating system of Definition 3.8. System library. The system library serves O-mode, in the place glibc [100] has in Linux, with one difference: its system-call wrappers and semantic wrappers are semantic delegation calls (Ā§5), implemented by a module the library inserts into the kernel. To O-mode an operator is a signature, as a tool call is; to P-mode it is code that merges several of PRTSās internal system calls into one operator. Table 8 lists the operators, and Appendix D.5 says why the Oracle sees them and not those calls. The system library is the library Ī of Definition 3.8 and has exactly its parts. Its declaration Ī“Ī _ , the first record of every history, lists the operators with their signatures. Its request language LĪL_ consists of two kinds of word: the well-formed sequences of operator calls, which together are the request of one trap; and an answer that calls nothing, which asks the kernel to deliver its text as the taskās result. Its Priestess-side part is the module in the kernel. The declaration, the calls and the check of each callās arguments are generated from one table of operators, so the declaration aligns with the check. A semantic delegation call can also be registered in a kernel module and called as an operator, as fb_play in Figure 7 is. The libraries that the system library loads are text, linked lazily as a dynamic linker binds a function at its first call. A libraryās short declaration is in the system record from the start, and its full text enters the history only when the program loads it, with one call. Agent harnesses call such libraries skills. Family Operators What one call does Standard streams input, print read standard input, a named file or a result channel, as far as there is data, with end of file reported together with the last data; write a whole text to standard output or to the parent Programs run, fork, execve, waitpid, exit, yield run a command line as a pipeline; the process calls of Unix Names open, close give a file or a directory a name, or drop it Editing file_read, file_write, file_patch read, write or patch a file in one call, guarded by a stamp of the version read Paths stat, list, mkdir, remove, rename, chdir one file-system operation each Information context, time, sleep the taskās own arguments and environment; the simulated clock Oracles and libraries ask, load_skill call a person or a language model in P-mode, for an answer that is data; load a libraryās definition Host bash run a command on the host, with the semantics of sodo: every call goes through sodoās check Table 8: The operators of the system library. fb_play in Figure 7 is a further semantic delegation call, registered in a kernel module. Init system. The init system, the first program to run in O-mode, initializes the system, starts the shell and starts it again whenever it ends while there is a terminal to read, and adopts every orphan process. The right to shut the system down belongs to the shell the init system starts, not to the shellās program, since a program is text that any task may run. In ArchNights-SE the init systemās loop is a semantic delegation call, but an init system that runs entirely in O-mode is equally legitimate. Shell. The shell is the second program to run in O-mode, the systemās interface to its user, and it follows the logic of mainstream shells. It is a text that the Oracle runs as a task and that says how to be a shell. What makes it a shell is a P-mode part, its session, which the kernel runs when the shell waits for a line or a job. The shell is therefore a hybrid in the sense of Definition 3.10. Its Oracle part is the Oracle with the operators, and its Priestess part reads the person, runs builtin commands, and starts and collects jobs, with no Oracle in its loop. The session reads a line by calling the Human class in P-mode, so a line is an answer, and by K4 it is data. It becomes a request to the Oracle part only because the session writes it into the history, as the next user record. The shellās state is its conversation: a line in natural language runs in the same task and history, where the context accumulates until the person clears it; a program runs as a child, isolated from the shell. A line that begins with / is a builtin, run without the Oracle. A line that begins with ! runs on the host, through sodo, and only if the person typed it at the prompt: lines from scripts, profiles or a programās input never do. Any other non-empty line is a request in natural language. What the person does at the prompt reaches the Oracle only as one-line events, with no output: the Oracle learns that the person ran a program and how it ended, not what it printed. Appendix D.5 gives the builtins, the sessionās loop, one history record by record, and the core tools with sodoās check. <host path><host path><host path><host path><host path><host path><host command> Figure 7: A session of ArchNights-SE making the music video of world.execute(me);. Above: the simulated display showing the video; its text and diagrams, such as the two stacks, belong to the video, not to this paper. Below: gem5ās messages and a session of the shell on PRTS, with a request at the prompt, in natural language, that names the calls it wants (fb_play among them), and the operator calls the task makes, each with its result. The sessionās user oracle is the ordinary O-mode user (Ā§6.3). Every call of bash goes through sodo, whose audit is turned off in this run, as in all our tests, and fb_play is a semantic delegation call registered in a kernel module (Ā§6.4). Host paths and host commands are replaced by placeholders. 6.5 ZOOT: the Kernel of ArchNights-FS This paper (same model, same setting)ArchNights-SEminimal, extra83.1minimal77.5full77.5Terminus 278.7mini-SWE80.9Vendor-reported, in the vendorās settingsmini-SWE90.3DSH Minimal90.6Claude Code88.0Pi86.1DSH Standard85.8DSH PTC85.8OpenCode85.0Codex84.1same harness, +9.4+9.4767880828486889092Pass@1 (%) Figure 8: Terminal-Bench 2.1, Pass@1 by harness, with deepseek-v4.1-flash as the Oracle. This paper (filled dots, ArchNights-SE in blue, in the configurations of Table 9): one trial of each of the 89 tasks, with the same model in the same setting. Minimal, extra: the minimal system with the extra prompt; otherwise the minimal and the full system use the default prompt. Vendor (hollow dots): as reported in [101], Table 4, in the settings given there. In each group the dashed line marks the score of mini-swe-agent, the harness both evaluations run, and it joins the two scores. mini-SWE is mini-swe-agent, and DSH is DeepSeek Harness. ZOOT (Zeroed Ordered Oracle sysTem), booted by its firmware, is a design. Its functions are nearly those of PRTS, but where PRTS cannot reach a real kernel, ZOOT is to run together with one. The design follows the principle that several privilege levels of a machine multiplex one task and several tasks multiplex one kernel. So ZOOT runs in U-mode, one instance per user, as the kernel of the O-mode below it, with Linux in S-mode and the firmware in M-mode. O-mode may then have several users, which brings back, one level down, the old question of how the users of one privilege level relate to those of another. ZOOT answers it as kernel-isolating virtualization [102] does for the users of U and S: each user has a U-mode kernel of its own, the kernels share part of their state, and operations on the shared state need a higher privilege level. In the terms of Definition 3.8 this is one operating system (K,Ī)(K, ) for each user, with Linux in S-mode as the arbiter above them. What the kernels must share is Priestess-side state, which K1 and K2 already keep out of every task. Appendix D gives the alternatives and ZOOTās design of tasks and memory, its file system, its boot and its bridge to Linux. 6.6 Evaluation of ArchNights-SE We evaluate ArchNights-SE to show that the O-2-PDA-TSV can serve as the basis of an agent harness, and we compare the results with those reported by DeepSeek, the vendor of the model we use as the Oracle. DeepSeek evaluates Terminal-Bench 2.1 without network access [101], and to narrow the gap between the two evaluations we come as close to that as the tasks allow. Some of the settings still cannot be matched, so their effect can be shown only through the one harness that both evaluations run, mini-swe-agent. The results show that a prototype built on the machine solves tasks as an agent harness does. Common assessment. On Terminal-Bench 2.1 [43], with deepseek-v4.1-flash as the Oracle, ArchNights-SE scores between 77.5 and 83.1 in Pass@1, depending on its configuration. With the same model and the same setting, mini-swe-agent [44], a harness with a single bash tool, scores 80.9, and Terminus 2, the benchmarkās own neutral agent [43], scores 78.7 (Figure 8). Each score is the Pass@1 of one trial of each of the 89 tasks, so one task is 1.1 points. In that setting the model reasons at maximum effort (a parameter passed by default) and samples at the default temperature of 1.0. The timeouts are those of Terminal-Bench 2.1, and, as in the benchmarkās standard evaluation, ArchNights-SE runs inside the taskās container together with its simulator. Most tasks run fully offline: the data and sources that they need are staged in their images, and their packages are served from local mirrors. A few run semi-online, through a strictly controlled proxy. As in all our tests, the audit of sodo is turned off, so every call of bash passes it, and the taskās container keeps the network isolated. A harness that runs tasks with no person watching behaves the same way: an authorization prompt would stop a task at its first privileged call, so the setting is the usual one for an unattended benchmark, and the run exercises the kernelās checks instead of being refused by them. ArchNights-SE is evaluated in the three configurations of Table 9. The minimal system is the distribution reduced to one process, with the operators file_read, file_write, file_patch, list, stat, bash and exit. The others of Table 8, those for processes among them, are removed. It keeps the systemās default prompt, which asks a task to stop only when its work is complete. When Terminal-Bench evaluates Terminus 2, the agentās own prompts begin every turn with an analysis of what has been accomplished and what still needs to be done. That prompt template is supplied by the benchmarkās harness and not stated in its paper [43]. An external harness such as ArchNights-SE has no such prompt, so we carry it over as far as the system allows. The extra prompt appends two rules to the task. The first rule is to write what the task asks for as soon as there is a first version and then improve it, since only what is written counts if the work is cut short. The second is to ask after each step whether the result already meets what the task asks, and to finish when it does. The minimal system with the extra prompt resembles the Minimal mode of DeepSeek Harness, which has a single bash tool and in which DeepSeek evaluates its model as a code agent [101]. With its default prompt the minimal system scores 77.5, as the full system does, and with the extra prompt it scores 83.1. All Solvable Other Configuration 89 79 10 ArchNights-SE, minimal, extra prompt 74 (83.1) 66 8 mini-swe-agent 72 (80.9) 65 7 Terminus 2 70 (78.7) 62 8 ArchNights-SE, minimal, default prompt 69 (77.5) 61 8 ArchNights-SE, full, default prompt 69 (77.5) 61 8 Table 9: Terminal-Bench 2.1 with deepseek-v4.1-flash, one trial of each task: tasks passed (Pass@1, %). Solvable: the 79 tasks whose reference solution passes in our setting; Other: the remaining 10. The proxy lets only specific network accesses through, so a harness may pass a task whose reference solution does not. The shared harness, mini-swe-agent, aligns the two evaluations in kind, not strictly in score: with the same model it scores 80.9 in ours and 90.3 in DeepSeekās (the dashed line in Figure 8). For reference only, DeepSeek reports between 84.1 and 90.6 in its own settings for eight harness configurations. The highest is with its own harness, DeepSeek Harness in its Minimal mode [101]. The vendor scores its model highest in the configurations that check the least, its own Minimal mode and mini-swe-agent among them, and the harnesses whose prompts ask for a task to be inspected and carried through to the end score below them, Claude Code among them [12]. A harness of the second kind loses tasks that a harness stopping at the modelās own word keeps, and the harness compared here is of the first kind. We cannot say how much of the 9.4 points this is, since the vendor does not report the prompts its harnesses use. General compute. With a virtual display and audio output added to the simulated computer, ArchNights-SE produced a music video of world.execute(me); (Figure 7). The run shows that the O-2-PDA-TSV is two kinds of system at once. It is an agentic system, an agent harness that carries a task through, and it is a computer system, a general-purpose computer that runs programs on its devices. The task runs as the ordinary user oracle and reaches the host through bash, each call through sodo, whose audit is turned off here as in the benchmark. It plays the score through fb_play, a semantic delegation call registered in a kernel module. 7 Related Work Quine is the closest work in structure [29]: it realizes agents as POSIX processes, with a deterministic host driving a stateless model and the hostās kernel keeping isolation. This paper constructs the abstract machine first, derives the operating system on it, and then places the designs of the field on that machine. Ā§7.1 takes the work that has modelled agentic systems before us; Ā§7.2ā7.6 take the work that our derivation rests on or draws from, in five fields: agents and harnesses, the theory of computation, programming languages, operating systems and computer architecture, and inference systems and agent safety. Appendix E takes up what the body leaves open: case studies that apply the models of Ā§4 to the encoders, caches, schedulers and defences; the Oracles other than language models; and the Lynchpin hypothesis. 7.1 Other Foundations for Agentic Systems Agentic systems have acquired foundations as language models have grown. Some, as the Introduction notes, model an agentic system by analogy, most often with an operating system. Others go deep in one direction: processes, trust, languages, the oracle, the instruction set. Each has produced working systems or useful theory. This paper takes a different route: it constructs an abstract machine and derives an operating system on it. The derivation optimizes nothing by itself; what it offers is a model on which the optimizations of other work can rest. Each paragraph below describes one line of work and then locates it on the machine. Agent operating systems. Agent operating systems extend the abstractions of an operating system to agents by analogy, and the analogies disagree on where the model stands. For AIOS the model is a resource. AIOS moves the model and the tools out of agent applications into a kernel, with managers for scheduling, context, memory, storage and access control [24]. For a vision paper and for one of the papers named AgentOS the model is the kernel itself, a reasoning kernel over its context [103, 25]. A second AgentOS proposes a personal agent kernel with skills as modules [26]. Others read the model with its context as a computer. MemGPT pages tiers of memory into the context window as an operating system pages memory [104], and two frameworks carry the von Neumann architecture [105], or computer architecture as a whole [106], over to agents. Lin et al. reconcile the positions with two planes, a probabilistic one that executes and a deterministic one that controls [106], and illustrate the separation with published parameter data. A fourth group does not place the model but asks what an operating system guarantees. The first AOS paper defines an agentic control plane and maps it onto Linux and Windows [27], and the reference architecture that follows it leaves the host system outside its boundary [28]. A blueprint asks for operating-system guarantees for agents [107], and an essay proposes primitives extended from those of operating systems and clouds, as POSIX and Kubernetes gave their waves a small set of stable abstractions with defined semantics [108]. An analogy places the model where the borrowed concept places it. On the machine the placement follows from S and T, which order the two sides: an operating system mediates a task exactly when the side that holds the taskās program is not the side that T privileges (Definition 3.9). In the Agent form the Oracle is then the processor of the taskās program and the Priestess its operating system, which are Lin et al.ās two planes. The model with its context as a computer is the O-mode reading, in which the history is at once the Oracleās program and its memory (Ā§7.2), and MemGPTās paging is a rewrite of the task, which starts a new epoch (Appendix E.2). The model as the kernel puts privilege on the Oracleās side. That is the reversed ordering, the bottom row of Table 3. This paper orders the sides for an untrusted Oracle such as a language model. On the machine with the ordering reversed (Appendix E.5), a model as the kernel still confines the programs it runs, but every request it serves becomes part of what it runs next, and its decisions come from an answer relation that no proof inspects. The model as a resource puts the calls in the other direction. AIOSās kernel manages the model for the applications whose code calls it; the kernel of Definition 3.8 manages what the model runs, a history whose system calls are the modelās own answers, served at a yield trap. The fourth groupās operating system, like Quineās below, stands between processes on the Priestessās side. Among the abstractions with defined semantics that the essay asks for, those at the boundary between the model and the program that it runs are the task, the system call and the library of Definition 3.8. The contract gives them their semantics, derived from the rules and not extended. One name needs care: UFO2 uses AgentOS for a desktop agent that operates the applications of a host, which Table 3 calls an Agent operating a computer [109]. Processes, virtualization and unification. A second line takes one abstraction of an operating system and asks how far it carries, and part of it poses the unification problem of the Introduction. Quine takes the process abstraction furthest of these, and gives the model tools to run a shell, to fork, to exec and to exit. FMOS states the unification problem most clearly [30]. It treats workflows and agentic loops as two execution forms over shared primitives. Its guarantees are conservative and rest on a virtualization condition after Popek and Goldberg [110], which FMOS assumes at its interface, while the partition is learned at run time. Two harness designs take the two poles in a language. Harness as a Language has a single primitive, an invocation whose body the model writes as code that may invoke the model again. With it, the design expresses both the agent loop, as a tail-recursive invocation, and more elaborate workflows [31]. LLM-as-Code lets deterministic code own the control flow and calls the model only to reason or generate [111]. Self-programmed execution states the first pole formally, on an agentic machine that makes one model call per transition, after Turingās oracle machines. An evaluator that runs each completion as a program reaches every state of such a machine, so what distinguishes the architecture is which entity expresses the orchestration policy [112]. On the machine Quineās operating system is the hostās and stands between processes, inside the Priestess; PRTS defines the same calls one level down, between the Oracle and the Priestess (Ā§6.3). FMOSās virtualization condition holds by the rules of the O-2-PDA-TS, while FMOS assumes it at an interface (Ā§7.5). The loop of the first design is an Agent task whose harness runs the code that each answer carries, a program that the Priestess interprets (Table 10). The second design calls the model in P-mode, in the Workflow form. Self-programmed execution also evaluates each completion in the Priestess, and its question, which entity expresses the orchestration, is one of paradigm. The two poles thus differ in form, the placement of a taskās program, as well as in paradigm, the question of whose output decides the next step (Ā§3.5). Kernels that put trust first. A third line builds the operating system for agents around trust, and makes its checks complete by design. AgentKernel argues that governance that shares the agentās process trust boundary is not enough, and makes identity, input mediation, memory governance and execution control mandatory services that cannot be bypassed [113]. AgenticOS turns the operating system into a filter of declared intents that builds a least-privilege environment [114]. KAIJU separates the modelās reasoning from execution in an executive kernel with an intent gate [80]. Sovereign Agentic Loops validate the modelās outputs as intents in a control plane and keep an evidence chain for audit and replay [115], and a runtime sets budgets for irreversible effects across agents and workflows [116]. Agent libOS lets a self-evolving agent change what it can ask for, but not what it is authorized to affect [117]. Each design derives completeness from a mediator that cannot be bypassed. AgentKernel requires every interaction to traverse its kernel, through adapters assumed not to be bypassable. The sovereign loops assume that the control plane mediates every change of state, and AgenticOS makes its gateway the only controlled boundary, given isolation in hardware. On the machine their separation of reasoning from execution is the crossing invariant, and their checks and budgets sit on the safety boundary: a check of a request at ātrap _trap, and a mediation of inputs at the kernelās writes on the way in, AgentKernelās among them (Appendix E.4). Agent libOSās principle is K4ās: an answer selects only among the successors that the kernelās code allows, and grants itself no right. That every request passes the service entry is an invariant of the machine (K3, Corollary 3.5), not an assumption about a mediator. What remains to assume is that a realization keeps to runs of the machine. For the construction of Ā§5, it is segment locality, the locality of the Priestessās own code and the fetch condition; for a harness on an ordinary computer, it is that the harness implements the machine faithfully. Either is one assumption about the machine, not one about each check. The machine guarantees that every request reaches the code where the policy sits. Whether that code consults the policy, and what the policy decides, is the kernelās. Languages for agents. Calculi and languages for agents fix a language and prove what its programs cannot do. Ī»A _A extends the simply typed lambda calculus with an oracle term and a bounded fixpoint for the ReAct loop, and mechanizes type safety and termination [19]. LLMbda proves a probabilistic noninterference theorem for every program of a calculus whose state is a conversation that the programs extend, fork and clear. LLMbdaās verified interpreter is itself the harness that calls the model [21]. ZipperGen projects global workflows into local programs that cannot deadlock whatever the model answers [20]. The machine fixes no language, and what an operating system on it guarantees is an invariant of the machine, one that programs in any of these languages preserve. In Ī»A _A the oracle term returns a value that the program binds, as a P-mode call returns data (K4), and the loop around it is the programās; the Oracle instruction also has an O-mode, in which the Oracle runs its history as a program and a kernel arbitrates at ātrap _trap (K3). LLMbdaās labels track flows that the contract does not see, while the contract arbitrates space and control, so the two constrain different things. Since these works define no operating system and we define no language, the two combine. A program in one of these languages can be the task code of a Workflow or the kernelās service policy, and its guarantees then sit beside the contract. AgentSpecās rules are such a service policy [23]: they fire before each action and when the agent finishes, at the trap, and on each change of state, on the way in. Other formal works fit in the same way: a choreography [118] or a Lean model of a workflow [119] describes task code, the Calculus of Intelligence, in which a task is a space of valid plans whose local parts compose when their declared overlaps agree, describes task code one level up [22], a process calculus for tool protocols describes the declaration and the requests it admits [120], and runtime monitors [121, 122] and an automaton that supervises the generation of a plan [123] are Priestess code. Models as oracles and as automata. Another line models the language model, as we do, as the oracle of an oracle machine, and asks what such a computation achieves, at what quality and cost. AI-oracle machines form each query by an algorithm that may decompose the task, and check each answer against reference material that the user supplies [124]. The stochastic-oracle Turing machine (SOTM) makes this precise. A probabilistic Turing machine writes a query on a query tape, and the oracle, a family of response distributions indexed by the query, writes a response on a response tape [125, 126]. The series proves what such a machine reaches and at what token cost. The least expected cost of reaching a given expected score is monotone and convex in the score [125], and certifying with error at most Īµ that an oracleās reliability is at least p1p_1 rather than at most p0p_0 takes, to leading order, ln(1/Īµ)/D(p1ā„p0) (1/ )/D(p_1\,\|\,p_0) turns [126]. When the distributions also depend on the transcript so far, an oracle that caches its answers bounds what any adaptive machine can identify, and fresh answers to a repeated query lower the error at the Chernoff rate [127]. An agentic oracle maintains a hidden state and may act on an environment. Part of its cost is spent inside it, where the caller does not see it, and retained state can make the cost of a task linear in its steps whereas an oracle sent the whole prefix at each step pays a quadratic cost [128]. Chains of thought have been formalized as Turing reductions [129]. Agents have been classified as automata by their memory, with hierarchical agents as pushdown automata when calls return in order and memory is scoped to the stack, so that some of their verification questions are decidable [130]. In programs with choice points that an oracle resolves, a strategy is separated from the policy that searches it [131], and agents have been studied as universal task solvers within algorithmic information [132]. These works ask what the oracleās answers achieve. We ask who decides at the switches, and what a system guarantees when it is built on the answer. The questions meet in places. A stochastic oracle with non-empty answers defines an answer relation by the supports of its distributions, so the contract and the safety boundary hold on every run with it, while none of the quantitative results of the series can be stated for a relation alone. Our query is the whole stack, the case of the SOTM in which every query includes the whole transcript [128]. Within an append-only epoch of an Agent task no query repeats, since answers are non-empty, so the difference between cached and fresh answers does not arise there. It arises when a kernel restores a history and enters it again. An agentic oracle encapsulates its agent loop, its tools and its access to the environment inside the black box. On the machine that loop is an Agent task and the harness that serves it is the kernel, so its tool calls are requests that reach the kernel at ātrap _trap (K3). What stays hidden is the Oracleās computation inside one call, and through a Frame interface even the number of its Steps can be (Proposition 4.6). The linear cost of retained state has a counterpart in the state cache. Under the conditions of Proposition 4.10, a private cache that keeps every state computes each token of a history once while the kernel only appends to it, although every query is the whole history. The two stacks of the O-2-PDA have the power that Koohestani et al. assign to read/write memory, so the questions that they make decidable by restricting an agent to one stack are undecidable on the machine in general. Such a restriction would be a property of a kernel or a program, not of the machine. The contrast is the line that places universality inside the model, or in a loop around it. Transformers are Turing complete under idealized assumptions [133, 134]. Chains of thought raise their expressive power [135, 136], with a power that grows with the number of steps [137, 138]. A looped transformer runs programs given as its input [139], and a fixed transformer computes every computable function under a suitable prompt [140]. Around the model, neural controllers were coupled to external memories [141], a model has been used as the processor of a stored-program computer [142], and a prompted model simulates a universal machine with an associative read/write memory [85] or under extended autoregressive decoding [143]. A transformer that manages its transcripts as channels realizes only finite-state transductions as long as the channels are append-only and it sees a bounded suffix of them, and becomes universal with two channels that admit pop [144]. A result that holds for every Oracle cannot rest on an Oracleās power, so the O-2-PDA places universality in the Priestess, and the Oracle instruction adds no power beyond the Oracleās (Ā§2). On the machine a loop around a fixed model is a Priestess program in the Workflow form, and universality inside the model would make O-mode universal by itself. The machine neither needs nor excludes either. Instruction sets for Oracle calls. Instruction sets for Oracle calls predate ArchNights, and they fix the meaning of a call in the instruction set. Arbiter-K encapsulates the model as an untrusted probabilistic processing unit, reifies its outputs into a semantic instruction set, and enforces security in a neuro-symbolic kernel with taint propagation and rollback, in a Python prototype [145]. Poon proposes cognitive instructions (THINK, RECALL and ADAPT) whose permissions the operating system controls [146]. A learned function behind instructions of a general-purpose ISA is older: the neural processing unit replaces code that the programmer marks approximable, is invoked through extensions to the ISA, and may introduce small errors [147]. It computes a fixed function, with no history and no mode of its own. ArchNights has one Oracle instruction and an O-mode with no addressable code, entered by uret (Ā§6); the instruction lies in the RISC-V custom space and is compatible with RoCC. The meaning of a request is fixed by the history and by LĪL_ , not by the instruction set, so one instruction serves every Oracle and every library, and the contract does not depend on what a request means. 7.2 Agents and Harnesses The two forms of Ā§3 name a distinction drawn in practice by agent programming and by the harnesses built since language models arrived. Agents before language models. Agent-oriented programming characterized agents by their beliefs, commitments and capabilities [1], and the BDI model described them in terms of beliefs, desires and intentions [2]. Agent programming gave agent programs languages with operational semantics [148, 149] and verified them, by a framework for programs with declarative goals [150] and by model checkers for agent programs and multi-agent systems [151, 152, 153]. Surveys cover its theories and architectures [154, 155]. Its guarantees are those of a program in a language. The recent bridges leave such a program in control while a model answers its calls [156, 157, 158], and a survey catalogues how machine learning has entered BDI agents [159]. On the machine these bridges are in the Workflow form: the program is Priestess code, and the model answers in P-mode, with answers that are data (K4). The machine says nothing of an agentās mental state. The Oracle is a black box, and the Priestessās record of it is its history. Harnesses and their terms. Advances from neural language models [160] through the Transformer [161] to large models capable of performing tasks from context [3] provided a practical executor for open-ended tasks. With models as executors came ReAct, which interleaves reasoning with tool actions in one loop [162], and architectures that organize a language agent by its memories, its actions and a decision loop [163]. Whatever memories an architecture names, what the Oracle reads in O-mode is its history (K2), and an external action is a request served at the trap. Programming systems put model calls on code paths fixed in advance: query programs with constraints [164], declarative modules compiled into pipelines [165], compositions of calls read as probabilistic programs [166], flows of calls in which each call samples a message and appends it to the context [167], and algorithms that call the model at fixed points [168]. On the machine they have the Workflow form, and ReActās loop the Agent form. Multi-agent frameworks compose conversable agents [169], and planners emit graphs of calls for an executor [79]. A conversable agent is one more task, which a kernel service spawns or forks. Building Effective Agents separates Workflows from Agents by whether code or the model directs the process [8]. We keep its terms and split them in two. On the machine the forms are placements of a taskās program, and the distinction drawn in Building Effective Agents is the paradigm, so a planned graph that Priestess code executes is a Workflow in form and an Agent in paradigm (Ā§3.5). Taxonomies elsewhere draw a different line, between AI agents and agentic AI, marked by multi-agent collaboration among other traits [170]. An early essay describes a model with its scaffolding as a computer, with the model as its processor and the context as its memory [7]. This is the O-mode reading, with two differences: the Oracleās program is its memory, with no code beside it, and within an append-only epoch, that memory only grows. Ā§3.5 places a harness and a scaffold in these terms. Existing designs in this structure. For most designs, the structure gives a placement, which says where a designās guarantees come from and what the design costs elsewhere (Table 10). Some rows are more than a placement. Compaction and paging have a price that the structure names: the break of the prefix chain at the rewrite. Leylineās directives [69] lower exactly that price (Appendix E.2). Constrained decoding is the Oracleās side of the declaration: the declaration supplies the thunks, and the constraint restricts every request to LĪL_ . Design In this structure What the paper says of it A tool-calling loop [162] an excursion that yields with a request; the toolās result is the reply, appended before the next uret the Agent form (Ā§3) Several calls in one answer; a planned graph of calls [79] several calls in one answer, one request, all served before the task runs again; a plan that Priestess code executes is an answer the Priestess interprets several calls in one answer are one request of an Agent task; a planned graph that Priestess code executes runs in Workflow form, with the Agent paradigm, since the model wrote the plan (Ā§3.5); its parallelism is the Priestessās Code as the action [171, 31] the answer is a program that Priestess code runs: an interpretation by the Priestess the answer gains no execution right by itself (K4); checking it first is the Priestessās obligation Sub-agents and delegation [169, 29] spawn or fork; fork answers one request twice, and the two histories share their prefix fork is one kernel service that builds the prefix tree (Ā§4); the childās result reaches the parent only through the parentās read (Ā§6) Compaction of the context the kernel rewrites the task, and the summary, the answer of a P-mode call, is data the kernel writes a new epoch: the prefix chain breaks after the part of the history the rewrite keeps (Ā§4); in PRTS, a swap that keeps the head (Ā§6.3) Memory tiers paged into the context [104] moving content out is a rewrite by the Priestess; bringing it back is a read the Oracle requests as with compaction; an interrupt becomes content appended at a switch Skills [172] dynamic libraries linked lazily: a short declaration in the history from the start, the definition loaded by one call the system library of ArchNights (Ā§6) Tool protocols such as the Model Context Protocol [173, 120] a toolās description is part of the declaration Ī“Ī _ , and a call is a request in LĪL_ that a kernel service serves the declaration makes a call possible, not certain (Ā§5) Constrained decoding [164, 174, 17] the Oracleās answers are restricted so that every request lies in LĪL_ , or every P-mode answer has a given form membership becomes certain; that the request is the right one does not Prefix and prompt caching [16, 17, 18] a cache of the Oracleās computation keyed by the history; histories of the same program share their first records, the declaration among them the state cache, the prefix chain and its shared key (Proposition 4.10); the shared first records are the root of a prefix tree; reuse of modules at reserved positions [18] falls outside the state cache (Appendix E.2); their scheduling is in Table 4 Checkpoint, rewind and restore [175] a restore gives a new task a history equal to an old one, by a write of the kernel a channel for replay, which a policy at the service can limit (Appendix C.10); the checkpoints of PRTS (Ā§6) Workflow programs and engines [165, 164] the Workflow form: a model node is a P-mode call, and a node that the model writes runs only by the Priestessās interpretation no operating system mediates the task (Definition 3.10) Approval of a privilege expansion by a person [176, 23] the person is an Oracle called in P-mode, and the approval is data the kernel acts on in the shell of ArchNights, a line acts with privilege only if the person typed it (Ā§6) Table 10: Existing designs in this structure. 7.3 Theory of Computation The machine is a construction of computability theory. Its two parts, the oracle and the two stacks, are standard, and so is a computation that exchanges data with a party outside it. Each paragraph says what the machine shares with one line of this work and where it departs from it. Oracle machines and relativization. Oracle machines go back to Turingās o-machines [45] and Postās reducibilities [177]. Relativization has a known limit: some questions, P against NP among them, cannot be settled by proofs that hold relative to every oracle [178]. Our results are relativized in the same sense. They hold for every Oracle that meets their hypotheses (in Ā§3, every Oracle, except for K5, which needs an Oracle that makes the machine good), and so say nothing about what a particular Oracle does. Statements about language models, the Lynchpin hypothesis among them, are therefore discussion, not theorems of the machine. The oracle elsewhere. Many fields use an oracle, and we claim nothing new in choosing one. In cryptography all parties share a public random oracle, which a hash function replaces in practice [179]. In query learning a teacher answers membership and equivalence queries [180], and oracle-guided inductive synthesis defines its oracle as a nondeterministic map from the dialogue so far and a query to a response, which it assumes to be sound [181]. Optimization counts a methodās calls to a black-box oracle [182], and software testing calls the difficulty of judging an output the oracle problem [183]. Other lines do not trust the oracle. An interactive proof must reject a false claim whatever an all-powerful prover answers [184, 185], a program checker uses the program it checks as its oracle [186], and a robust oracle machine accepts the same language with every oracle and runs fast with a helping one [187], much as K1āK4 hold for every Oracle and K5 needs a good one. Language models now take several of these roles: fallible membership oracles [188], test oracles [189] and provers checked by a verifier [190]. Our Oracle is untrusted. It may answer a query in more than one way, and the contract holds whatever it answers. Complexity theory separates an oracle, whose answer depends on the query alone, from a prover, whose answer may depend on all earlier queries [191]. Our Oracle is an oracle in this sense, but its query is the whole stack, so within an append-only epoch it sees what a prover sees. Interactive computation. Interactive computation studies machines that exchange data with an environment while they compute [192], as reactive systems interact continuously with theirs [193]. Persistent Turing machines keep a work tape across interactions, and their class is isomorphic to a general class of effective transition systems [194]. Interactive Turing machines translate infinite streams [195], and with advice they are equivalent to computers whose hardware and software are upgraded over time [196]. Ordinary interactive algorithms query their environment within a step and finish the step only when every query has been answered [197]. An online process can also be read as an oracle machine whose oracle is its environment [198]. The O-2-PDA is a machine of this kind. A call waits for its answer, the stacks persist across calls, the Oracle may return more than one answer to a query, and nothing else is assumed of it. In its choice of Oracle the paper therefore adds nothing to interactive computation. Whether interaction adds power beyond Turing machines has been disputed [199, 200], and lineages of language models have been argued to be equivalent to interactive Turing machines with advice [86]. Our results do not depend on that question, since with a deterministic Oracle the O-2-PDA computes what an oracle Turing machine with the same Oracle computes (Ā§2.4). The machine departs from these models in two places. The first is a form. A persistent Turing machine keeps its memory in the device and reads one input token per interaction. The O-2-PDA keeps the record of the interaction on its own stack, sends the whole stack as the query and appends the answer to it (Ā§2.5), so an Oracle with no memory of its own still answers the whole history, and the program decides which history that is. The second is the breaking. In these models the machine runs its program and the environment only supplies inputs or replies [194, 195, 197]. In O-mode the Oracle runs a program of its own on one stack, and control returns to the Priestess only at the trap label. That is the symmetry breaking from which Ā§3 derives an operating system. Two stacks, programs and random access. The machine of Ā§2 is a two-stack pushdown automaton written as a program in the style of register machines [48], and it computes what a Turing machine computes [47, 46]. Pushdown automata with oracles have been used to study reducibilities among context-free languages [49]. Those are one-stack devices, and the second stack is what makes ours Turing complete; the two stacks also carry the two colours that Ā§3 orders. In systems of communicating pushdown automata a query symbol transfers the whole stack of the component it names onto the stack of the component that asks, but the parties are pushdown automata, not an oracle [201]. Stack computers, Forth chips among them, are a line of their own [90]. Ā§5.2 keeps the stacks as the machineās semantics and, for the reasons given there, lays them out as segments of one von Neumann memory [50, 51, 91]. What is new is the combination: an oracle instruction whose query is the whole content of one stack and whose answer is appended to it, an operating system and its contract derived by breaking the symmetry of the stacksā colours, and that machine laid out on a von Neumann computer with one instruction for the Oracle and a mode for it below user mode. Each ingredient has a precedent in this section or in Ā§7.1: oracles that see the whole history, oracles that are not trusted, an untrusted model under a kernel, a learned function behind an instruction. The combination has no precedent we know of. 7.4 Programming Languages From programming languages the paper takes one vocabulary, call-by-push-value, and one reading of effects, and it declines one reading, duality. Call-by-push-value. We use a fragment of call-by-push-value [36] to type the cells of the machine and to name its crossings. The stack machine of call-by-push-value pushes and pops continuation frames and values, thunks among them [202]. The calculus has adjunction models with stacks [203], and it decomposes Moggiās monads [204]. We use none of this metatheory (Ā§3.1), only a vocabulary for when stored content is data and when it runs. The fragment is a simplification of Levyās calculus, chosen so that the definition of an operating system, and the concepts derived from it, remain clear without the rest of the calculus. It keeps the two shifts U and F, and its one ground type D is, in Levyās syntax, a countable sum Ī£wā1 _w1 over the words. It leaves out products, sums other than D, and the function type AāBAā B, whose application pushes an argument and gives the calculus its name. No step of the machine passes an argument, since the Oracle reads its operand from storage and k, the code at the trap label, takes none. A formal analysis of the machine in call-by-push-value would instead introduce the full calculus and derive them rigorously in it. Not a duality. Call-by-push-value sits in a rich theory of computational duality. Values and continuations are dual [205]. Call-by-value and call-by-name are exchanged by a syntactic involution [206, 207], their models form dual categories [208], and polarized calculi unify them [209, 210, 211], building on focusing in linear logic [212]. The pairing of Agents and Workflows in this paper is not one of these dualities. A duality relates evaluation orders, or a term and its context, within one calculus or between its models. The two forms are two placements of a taskās program on one machine, related by an interpreter and a compiler (Ā§3.5). The two readings of an interaction, a force from one side and a return from the other, are readings of one transition, not an exchange of programs. Effects and handlers. One reading of effects does carry over. Model calls have been treated as algebraic effects that handlers discharge [81], and the Workflow form treats an Oracle call as such an effect. The Agent form inverts the roles: the Oracleās history issues the requests, and the kernel at ātrap _trap is their handler. A handler that changes how a programās calls are executed is, in the Workflow form, a Priestess-side scheduler of the Oracleās work (Appendix E.3). 7.5 Operating Systems and Computer Architecture Definition 3.8 and the contract are stated against the operating systems and processors they borrow from. Each paragraph shows what the machine retains and what it changes. What an operating system is. Textbooks define an operating system as a virtualizer, a standard library and a resource manager [213], as an extended machine and a resource manager [214], or as a resource allocator and control program [215]. One tradition asks a neighbouring question from the other side and answers it by minimality: a concept belongs in a kernel only if moving it out would prevent the functionality the kernel must provide [216]. Definition 3.8 is narrower: it says what makes one program the operating system of another on one machine, and leaves to its code what that program manages. It is closest to the exokernel and the library operating system, in which a kernel multiplexes and libraries carry the abstractions [217, 218], with descendants in the library operating systems and unikernels of later work [219, 220]. A library operating system moves abstractions out of the kernel into the application, where they can be specialized and need fewer crossings into the kernel. ArchNights reverses the move: on the O-2-PDA-TS the crossing that costs is the Oracleās round trip, so semantic delegation moves abstractions out of the Oracleās history into the kernel. The interpreter of Proposition 3.11, which does the work of an operating system without privilege, is in the position of a unikernelās library: whatever isolation its tasks have is a property of its code. Protection and privilege. Protection has its principles, least privilege and complete mediation among them [84], its hardware rings [221] and its access matrix [222]. That matrix is kept by column, as an access-control list for each object, or by row, as the capabilities each subject holds, and capability machines carry the second into hardware [223]. What S restricts is a stored contentās right to run, and S attaches that right to the colour of the stack the content is on, as a page table attaches the right to execute to a page. On the machine a privilege level is a mode of T, the transition breaking of Ā§3. Complete mediation has its place at the safety boundary of Theorem 4.12: by K3 every return of control to the Priestess is a trap to one label, so every request reaches the kernel there first. Singularityās isolation by language, and not by hardware [52, 224], is the static, type-based form of the isolation by check in Ā§3. Appendix C discusses side channels of speculative execution [225, 226] and protections that also restrict the trusted side, as SMEP and SMAP do [92]. Information-flow control, for agents as elsewhere, labels values with a lattice of security levels [227]. Once both breakings are chosen, they order the two sides, P above O. That order is one of privilege between the sides, not of information flow, which is why LLMbdaās labels and the contract impose different constraints (Ā§7.1). Virtualization and several kernels. A virtual machine monitor can be built when every sensitive instruction is privileged, so that it traps [110]. The machine has this property by its rules: O-mode executes no instruction of its own and so has no sensitive instruction to run unprivileged; the Oracle can only append to its own task; and every way out of O-mode is a trap to one entry (Theorem 3.4). With ZOOT, a question returns one level down (Ā§6.5): how the users of one privilege level interact with those of another. Operating systems have answered it in three ways. Kernel-isolating virtualization runs several kernels on a monitor below them, each kernel the single supervisor of its guest [102], and RISC-Vās hypervisor extension gives that monitor a level of the privileged architecture [41]. Kernel-sharing virtualization keeps one kernel and divides it among its users, by security contexts in Linux-VServer [228] and by namespaces and control groups in the containers that followed. A third way keeps several principals at the supervisor level and moves the checks between them to machine mode: Keystoneās security monitor runs in M-mode and isolates enclaves by physical memory protection, each enclave with its own runtime [229]. In the terms of Definition 3.8, kernel isolation and a security monitor place several operating systems (K,Ī)(K, ) under an arbiter above them, and containers divide one operating system among its users. The contract of Theorem 3.4 holds for each of them whatever the placement. What the kernels share is Priestess-side state, which K1 and K2 already keep out of every task. Isolation among the users inside the Priestess is the arbiterās work, not the machineās. Verified kernels. seL4 is proved to refine its abstract specification down to its C code [55], CertiKOS stacks certified abstraction layers into a concurrent kernel [56], and Hyperkernel designs its interface for push-button verification [230]. They verify a kernel against a specification. Some of this work also builds the specification in layers: CertiKOS specifies each certified abstraction layer by hand, upward from the machineās assembly layer [231], and one recent line starts from a machine semantics already decomposed by privilege level [232]. In both, a person writes the specification and the kernelās code is proved against it; what is derived here is the contract, from the rules of the machine, and the code that keeps it is a separate question. This paperās contract is what every kernel on the machine can rely on; the correctness of a particular kernel, its service policy included, remains a property of that program. A kernel for the O-2-PDA-TS could be verified in their manner, and the contract is the part of its specification that the machine already provides. CertiKOSās layered abstract machines are closest in spirit to an operating system defined on an abstract machine. The instruction set. ArchNights builds on the von Neumann architecture [50], on RISC-Vās privileged architecture, whose xRET it follows to enter O-mode [41], and on RoCC, Rocket Chipās interface for custom coprocessors [42]. Everything else that the Priestess computes is left to an ordinary processor (Ā§5), and a characterization of agentic workloads measures that work around the model [233]. 7.6 Inference Systems and Agent Safety Three fields that Ā§4 touches have grown large: the encoders of language models, the caches and schedulers of the systems that serve them, and the safety of agents. We summarize what the paper takes from each and what it adds. Appendix E places their work on the machine. Encoders. Tokenizers have a formal theory, from encoders of bounded variation [58] to the finite lookahead of byte-pair encoding [59], and the boundary between a prompt and its continuation is a known source of bias [63, 234]. Ā§4 adds a use; it does not add a theory. A separator at the end of every Frame makes the encoderās loss zero there. The separator synchronizes the two processes at every Frame boundary when, in addition, the Oracle is Frame-faithful and called through the Frame interface, and the kernelās writes end with ā® . This synchronization grounds the cache results (Appendix E.1). Caches and schedulers. Serving systems share and page the KV cache [16, 17], and program-aware servers schedule each call by the program it belongs to [65, 66, 67]. Ā§4 states these mechanisms against the machine. Appendix E.2 explains where reuse beyond prefixes steps outside the model of Ā§4 and why compaction and paging start a new epoch, and Appendix E.3 sorts the schedulers by the side they belong to and the side they schedule. Prompt injection and its defences. The questions this raises are older than the models that raise them: confining a process whose interior is not assumed [235], a monitor that mediates every crossing [236], non-interference between what one party does and what another observes [237], and the separation of a policy from the mechanism that enforces it [238]. The untrusted party is now a language model, which reads data and instructions in one history; the machine fixes where a monitorās mediation takes place, at the safety boundary of Ā§4.4, and leaves the policy to the kernel. Prompt injection, in which data that an agent reads is obeyed as an instruction [83], made the safety of agents a field of its own, with benchmarks for attacks and defences [239]. A systematization separates crossings mediated over provenance, which admit a deterministic check, from crossings mediated over the meaning of content [240]. The contract is of the first kind. Whether a request is the right one is of the second, which the contract leaves to the kernelās policy. Appendix E.4 places the defences built for agents at the three positions the safety boundary leaves them: on the way in, at the Priestessās writes; inside the Oracle, where no rule of the machine can certify a defence; and on the way out, at the trap or, in the Workflow form, at the gates. It also examines, on the machine, how a harness can escalate privilege. The boundary gives each defence its position and says what the defence sees there. It is not itself a defence against prompt injection: which request crosses is the Oracleās answer, and no rule of the machine inspects it. 8 Conclusion This paper set out to give agentic systems what the two clouds of Ā§1.1 deny them: a common ground and a unified view. The answer is one construction, in three parts. The O-2-PDA adds a single Oracle instruction to a two-stack machine; the symmetry breakings S and T derive an operating system on it, with the kernel contract as an invariant of the machine and Agents and Workflows as two placements of a taskās program; and the construction V fits the machine to a von Neumann computer, which ArchNights demonstrates can be built and can serve as the basis of an agent harness. The statements this machine yields are collected in Ā§1.4. What the machine leaves open. A construction that holds together also shows where it ends, and each question below is askable because the machine exists. Within the theory: a refinement from the O-2-PDA-TSV to ArchNightsā instruction set and kernel, which would carry the contract and the safety boundary over to the prototype and whose lemmas are the obligations that Ā§6.1 lists; the full call-by-push-value metatheory of the machine; and its complexity, in transitions or in tokens. Beyond these: safety under asynchrony and concurrency, several Oracles and both orderings of privilege combined, replay through rebuilt histories, isolation among users inside the Priestess, reuse of cache beyond prefixes, finite capacity, and Oracles that are not autoregressive inside. On the prototype: an asynchronous realization, in the microarchitecture or in the operating system; a kernel on several processors; and ArchNights-FS with ZOOT, built and validated, which needs a way to run the instruction set in the full system. One candidate is KVM [241] modified to support Oracle hardware run by the host. About language models: factorization at the yield symbol and Frame-faithfulness, checked per tokenizer and per model; the Lynchpin hypothesis, approached through the operators of the system library or in the stochastic-oracle setting (Appendix E.8); and when semantic delegation helps. These questions are empirical, and the companion experimental study, AgentNights, takes them up together with a broader evaluation of harness quality. The next step is AgentNights: the machine, the kernel and the system library implemented in host software, without a simulator, drawing on language modelsā own understanding of operating systems for a more flexible and efficient agent harness. Agentic systems have been built faster than they have been understood. The machine is offered as the place where understanding accumulatesāwhere a design choice is argued from invariants and bounds, once for both forms. Good night, Kristen. References [1] Yoav Shoham. Agent-Oriented Programming. Artif. Intell., 60(1):51ā92, 1993. [2] Anand S. Rao and Michael P. Georgeff. BDI Agents: From Theory to Practice. In Proceedings of the First International Conference on Multiagent Systems, June 12-14, 1995, San Francisco, California, USA, pages 312ā319, 1995. [3] Tom B. Brown et al. Language Models are Few-Shot Learners. In Advances in Neural Information Processing Systems 33: Annual Conference on Neural Information Processing Systems 2020, NeurIPS 2020, December 6-12, 2020, virtual, pages 1877ā1901, 2020. [4] Thomas Kwa et al. Measuring AI Ability to Complete Long Software Tasks. In Advances in Neural Information Processing Systems 38: Annual Conference on Neural Information Processing Systems 2025, NeurIPS 2025, San Diego, CA, USA, December 2-7, 2025 / Mexico City, Mexico, November 30 - December 5, 2025, pages 102382ā102435, 2025. [5] Romain Robbes et al. Agentic Much? Adoption of Coding Agents on GitHub. ACM Trans. Softw. Eng. Methodol., 2026. [6] John Yang et al. SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering. In Advances in Neural Information Processing Systems 37: Annual Conference on Neural Information Processing Systems 2024, NeurIPS 2024, Vancouver, BC, Canada, December 10 - 15, 2024, pages 50528ā50652, 2024. [7] Beren Millidge. Scaffolded LLMs as Natural Language Computers. Blog post, https://w.beren.io/2023-04-11-Scaffolded-LLMs-natural-language-computers/, 2023. Accessed 2026-10-02. [8] Erik Schluntz and Barry Zhang. Building Effective Agents. Anthropic Engineering, https://w.anthropic.com/engineering/building-effective-agents, 2024. December 19, 2024. Accessed 2026-10-02. [9] n8n. n8n: Fair-code Workflow Automation Platform. Software, https://github.com/n8n-io/n8n, 2019. Accessed 2026-10-02. [10] LangGenius. Dify: Build Agentic Workflows and RAG Pipelines. Software, https://github.com/langgenius/dify, 2023. Accessed 2026-10-02. [11] ByteDance. Coze Studio: An AI Agent Development Platform. Software, https://github.com/coze-dev/coze-studio, 2025. Accessed 2026-10-02. [12] Anthropic. Claude Code: Overview. Documentation, https://code.claude.com/docs/en/overview, 2025. Accessed 2026-10-02. [13] OpenAI. Codex: A Lightweight Coding Agent That Runs in Your Terminal. Software, https://github.com/openai/codex, 2025. Accessed 2026-10-02. [14] Mario Zechner. Pi: An AI Agent Toolkit. Software, https://github.com/earendil-works/pi, 2025. Accessed 2026-10-02. [15] DeepSeek-AI. DeepSeek Harness: Everything is a Plugin. Software, https://github.com/deepseek-ai/deepseek-harness, 2026. Accessed 2026-10-02. [16] Woosuk Kwon et al. Efficient Memory Management for Large Language Model Serving with PagedAttention. In Proceedings of the 29th Symposium on Operating Systems Principles, SOSP 2023, Koblenz, Germany, October 23-26, 2023, pages 611ā626, 2023. [17] Lianmin Zheng et al. SGLang: Efficient Execution of Structured Language Model Programs. In Advances in Neural Information Processing Systems 37: Annual Conference on Neural Information Processing Systems 2024, NeurIPS 2024, Vancouver, BC, Canada, December 10 - 15, 2024, pages 62557ā62583, 2024. [18] In Gim et al. Prompt Cache: Modular Attention Reuse for Low-Latency Inference. In Proceedings of the Seventh Annual Conference on Machine Learning and Systems, MLSys 2024, Santa Clara, CA, USA, May 13-16, 2024, volume 6 of Proceedings of Machine Learning and Systems, pages 325ā338, 2024. [19] Qin Liu. Ī»A _A: A Typed Lambda Calculus for LLM Agent Composition. CoRR, abs/2604.11767, 2026. [20] Benedikt Bollig, Matthias FĆ¼gger, and Thomas Nowak. Provable Coordination for LLM Agents via Message Sequence Charts. CoRR, abs/2604.17612, 2026. Accepted at ISoLA 2026. [21] Zac Garby, Andrew D. Gordon, and David Sands. The LLMbda Calculus: AI Agents, Conversations, and Information Flow. CoRR, abs/2602.20064, 2026. [22] Yang Yuan and Andrew Chi-Chih Yao. Calculus of Intelligence: A Topos-Monadic Framework for Agentic Workflows. iFuture, 1:9710001, 2026. [23] Haoyu Wang, Christopher M. Poskitt, and Jun Sun. AgentSpec: Customizable Runtime Enforcement for Safe and Reliable LLM Agents. In Proceedings of the 2026 IEEE/ACM 48th International Conference on Software Engineering, ICSE 2026, pages 2938ā2950, 2026. [24] Kai Mei et al. AIOS: LLM Agent Operating System. In Second Conference on Language Modeling, COLM 2025, 2025. [25] ChengYou Li et al. Architecting AgentOS: From Token-Level Context to Emergent System-Level Intelligence. CoRR, abs/2602.20934, 2026. [26] Rui Liu et al. AgentOS: From Application Silos to a Natural Language-Driven Data Ecosystem. CoRR, abs/2603.08938, 2026. [27] Ankur Sharma and Deep Shah. Agent Operating Systems (AOS): Integrating Agentic Control Planes into, and Beyond, Traditional Operating Systems. CoRR, abs/2606.01508, 2026. [28] Ankur Sharma and Deep Shah. The Agent Operating System (AOS): A Reference Operating Architecture for Distributed Agentic Systems. CoRR, abs/2608.03214, 2026. [29] Hao Ke. Quine: Realizing LLM Agents as Native POSIX Processes. CoRR, abs/2603.18030, 2026. [30] Suparna Bhattacharya et al. Position: It is Time to Virtualize Foundation Models with a Self-evolving Operating System Layer. In Proceedings of the 43rd International Conference on Machine Learning, volume 306 of Proceedings of Machine Learning Research, pages 169503ā169525, 2026. [31] Zhening Li et al. Harness as a Language: A Minimalist Agent Framework With Maximal Expressivity. CoRR, abs/2609.26891, 2026. [32] Reyna Abhyankar et al. InferCept: Efficient Intercept Support for Augmented Large Language Model Inference. In Forty-first International Conference on Machine Learning, ICML 2024, Vienna, Austria, July 21-27, 2024, volume 235 of Proceedings of Machine Learning Research, pages 81ā95, 2024. [33] Hanchen Li et al. Continuum: Efficient and Robust Multi-Turn LLM Agent Scheduling with KV Cache Time-to-Live. CoRR, abs/2511.02230, 2026. Version 7. [34] Zaifeng Pan et al. KVFlow: Efficient Prefix Caching for Accelerating LLM-Based Multi-Agent Workflows. In Advances in Neural Information Processing Systems 38: Annual Conference on Neural Information Processing Systems 2025, NeurIPS 2025, San Diego, CA, USA, December 2-7, 2025 / Mexico City, Mexico, November 30 - December 5, 2025, pages 139912ā139931, 2025. [35] Paul Blain Levy. Call-by-push-value. PhD thesis, Queen Mary and Westfield College, University of London, 2001. [36] Paul Blain Levy. Call-By-Push-Value: A Functional/Imperative Synthesis. Springer, Dordrecht, 2003. [37] Yuhan Liu et al. LMCache: An Efficient KV Cache Layer for Enterprise-Scale LLM Inference. CoRR, abs/2510.09665, 2025. Version 2. [38] Nathan L. Binkert et al. The gem5 simulator. SIGARCH Comput. Archit. News, 39(2):1ā7, 2011. [39] Jason Lowe-Power et al. The gem5 Simulator: Version 20.0+. CoRR, abs/2007.03152, 2020. Version 2. [40] Andrew Waterman and Krste AsanoviÄ. The RISC-V Instruction Set Manual, Volume I: User-Level ISA, Document Version 20191213. https://github.com/riscv/riscv-isa-manual/releases/download/Ratified-IMAFDQC/riscv-spec-20191213.pdf, dec 2019. Accessed 2026-10-02. [41] Andrew Waterman, Krste AsanoviÄ, and John Hauser. The RISC-V Instruction Set Manual, Volume I: Privileged Architecture, Document Version 20211203. https://github.com/riscv/riscv-isa-manual/releases/download/Priv-v1.12/riscv-privileged-20211203.pdf, dec 2021. Accessed 2026-10-02. [42] Krste AsanoviÄ et al. The Rocket Chip Generator. Technical Report UCB/EECS-2016-17, EECS Department, University of California, Berkeley, apr 2016. [43] Mike A. Merrill et al. Terminal-Bench: Benchmarking Agents on Hard, Realistic Tasks in Command Line Interfaces. In The Fourteenth International Conference on Learning Representations, ICLR 2026, Rio de Janeiro, Brazil, April 23-27, 2026, 2026. [44] SWE-agent team. mini-swe-agent: The Minimal AI Software Engineering Agent. Software, https://github.com/SWE-agent/mini-swe-agent, 2025. Commit 04d809ceab9d. Accessed 2026-10-02. [45] A. M. Turing. Systems of Logic Based on Ordinals. Proceedings of the London Mathematical Society, s2-45(1):161ā228, 1939. [46] John E. Hopcroft and Jeffrey D. Ullman. Introduction to Automata Theory, Languages and Computation. Addison-Wesley, 1979. [47] Marvin L. Minsky. Computation: Finite and Infinite Machines. Prentice-Hall, 1967. [48] John C. Shepherdson and Howard E. Sturgis. Computability of Recursive Functions. J. ACM, 10(2):217ā255, 1963. [49] Tomoyuki Yamakami. Oracle Pushdown Automata, Nondeterministic Reducibilities, and the Hierarchy over the Family of Context-Free Languages. In SOFSEM 2014: Theory and Practice of Computer Science, volume 8327 of Lecture Notes in Computer Science, pages 514ā525, 2014. [50] John von Neumann. First Draft of a Report on the EDVAC. Technical report, Moore School, University of Pennsylvania, 1945. Reprinted in IEEE Annals of the History of Computing 15(4):27ā75, 1993, doi:10.1109/85.238389. [51] Stephen A. Cook and Robert A. Reckhow. Time Bounded Random Access Machines. J. Comput. Syst. Sci., 7(4):354ā375, 1973. [52] Galen C. Hunt and James R. Larus. Singularity: rethinking the software stack. ACM SIGOPS Oper. Syst. Rev., 41(2):37ā49, 2007. [53] Leslie Lamport. Proving the Correctness of Multiprocess Programs. IEEE Trans. Software Eng., SE-3(2):125ā143, 1977. [54] Bowen Alpern and Fred B. Schneider. Defining Liveness. Inf. Process. Lett., 21(4):181ā185, 1985. [55] Gerwin Klein et al. seL4: formal verification of an OS kernel. In Proceedings of the 22nd ACM Symposium on Operating Systems Principles 2009, SOSP 2009, Big Sky, Montana, USA, October 11-14, 2009, pages 207ā220, 2009. [56] Ronghui Gu et al. CertiKOS: An Extensible Architecture for Building Certified Concurrent OS Kernels. In 12th USENIX Symposium on Operating Systems Design and Implementation, OSDI 2016, Savannah, GA, USA, November 2-4, 2016, pages 653ā669, 2016. [57] L. A. Almeida et al. Discovery of the Massive Overcontact Binary VFTS 352: Evidence for Enhanced Internal Mixing. The Astrophysical Journal, 812(2):102, 2015. [58] Juan Luis Gastaldi et al. The Foundations of Tokenization: Statistical and Computational Concerns. In The Thirteenth International Conference on Learning Representations, ICLR 2025, Singapore, April 24-28, 2025, 2025. [59] Martin Berglund and Brink van der Merwe. Formalizing BPE Tokenization. In Proceedings of the 13th International Workshop on Non-Classical Models of Automata and Applications, NCMA 2023, Famagusta, North Cyprus, 18th-19th September, 2023, pages 16ā27, 2023. [60] Fabian Gloeckle et al. Better & Faster Large Language Models via Multi-Token Prediction. In Forty-first International Conference on Machine Learning, ICML 2024, Vienna, Austria, July 21-27, 2024, volume 235 of Proceedings of Machine Learning Research, pages 15706ā15734, 2024. [61] Bin Gao et al. Cost-Efficient Large Language Model Serving for Multi-turn Conversations with CachedAttention. In Proceedings of the 2024 USENIX Annual Technical Conference, USENIX ATC 2024, Santa Clara, CA, USA, July 10-12, 2024, pages 111ā126, 2024. [62] Ruoyu Qin et al. Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving. ACM Trans. Storage, 22(4):37:1ā37:38, 2026. [63] Scott Lundberg and Marco Tulio Ribeiro. The Art of Prompt Design: Prompt Boundaries and Token Healing. Notebook in the guidance repository, tag 0.0.64, https://github.com/guidance-ai/guidance/blob/0.0.64/notebooks/art_of_prompt_design/prompt_boundaries_and_token_healing.ipynb, 2023. Accessed 2026-10-02. [64] Hao Xu et al. Are you going to finish that? A Practical Study of the Partial Token Problem. CoRR, abs/2601.23223, 2026. [65] Chaofan Lin et al. Parrot: Efficient Serving of LLM-based Applications with Semantic Variable. In 18th USENIX Symposium on Operating Systems Design and Implementation, OSDI 2024, Santa Clara, CA, USA, July 10-12, 2024, pages 929ā945, 2024. [66] Michael Luo et al. Agentix: An Efficient Serving Engine for LLM Agents as General Programs. In 23rd USENIX Symposium on Networked Systems Design and Implementation, NSDI 2026, Renton, WA, USA, May 4-6, 2026, pages 2443ā2459, 2026. [67] Hao Kang et al. ThunderAgent: A Simple, Fast and Program-Aware Agentic Inference System. In Proceedings of the 43rd International Conference on Machine Learning, volume 306 of Proceedings of Machine Learning Research, pages 55630ā55657, 2026. [68] Jiayi Yao et al. CacheBlend: Fast Large Language Model Serving for RAG with Cached Knowledge Fusion. In Proceedings of the Twentieth European Conference on Computer Systems, EuroSys 2025, Rotterdam, The Netherlands, 30 March 2025 - 3 April 2025, pages 94ā109, 2025. [69] Bole Ma, Jan Eitzinger, and Harald Kƶstler. Leyline: KV Cache Directives for Agentic Inference. CoRR, abs/2606.01065, 2026. [70] Mark Manasse, Lyle McGeoch, and Daniel Sleator. Competitive Algorithms for On-Line Problems. In Proceedings of the Twentieth Annual ACM Symposium on Theory of Computing, STOC 1988, Chicago, IL, USA, May 2-4, 1988, pages 322ā333, 1988. [71] Anna R. Karlin et al. Competitive Snoopy Caching. Algorithmica, 3(1ā4):79ā119, 1988. [72] Anna R. Karlin et al. Competitive Randomized Algorithms for Nonuniform Problems. Algorithmica, 11(6):542ā571, 1994. [73] Yipeng Liu et al. Ask the Tool, Donāt Guess: Agent Tool Calls Hold Their Progress, and the Serving System Should Read It. CoRR, abs/2609.18849, 2026. [74] Manish Purohit, Zoya Svitkina, and Ravi Kumar. Improving Online Algorithms via ML Predictions. In Advances in Neural Information Processing Systems 31, NeurIPS 2018, 2018. [75] Lu Ye et al. ChunkAttention: Efficient Self-Attention with Prefix-Aware KV Cache and Two-Phase Partition. In Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), ACL 2024, Bangkok, Thailand, August 11-16, 2024, pages 11608ā11620, 2024. [76] Jordan Juravsky et al. Hydragen: High-Throughput LLM Inference with Shared Prefixes. CoRR, abs/2402.05099, 2024. [77] Lingfan Yu, Jinkun Lin, and Jinyang Li. Stateful Large Language Model Serving with Pensieve. In Proceedings of the Twentieth European Conference on Computer Systems, EuroSys 2025, Rotterdam, The Netherlands, 30 March 2025 - 3 April 2025, pages 144ā158, 2025. [78] Vikranth Srivatsa et al. Preble: Efficient Distributed Prompt Scheduling for LLM Serving. In The Thirteenth International Conference on Learning Representations, ICLR 2025, Singapore, April 24-28, 2025, 2025. [79] Sehoon Kim et al. An LLM Compiler for Parallel Function Calling. In Forty-first International Conference on Machine Learning, ICML 2024, Vienna, Austria, July 21-27, 2024, pages 24370ā24391, 2024. [80] Cormac Guerin and Frank Guerin. KAIJU: An Executive Kernel for Intent-Gated Execution of LLM Agents. CoRR, abs/2604.02375, 2026. [81] Di Wang. Composable Effect Handling for Programming LLM-Integrated Scripts. In Proceedings of the 1st ACM SIGPLAN International Workshop on Language Models and Programming Languages, pages 124ā129, 2025. [82] In Gim et al. Pie: A Programmable Serving System for Emerging LLM Applications. In Proceedings of the ACM SIGOPS 31st Symposium on Operating Systems Principles, SOSP 2025, Lotte Hotel World, Seoul, Republic of Korea, October 13-16, 2025, pages 415ā430, 2025. [83] Kai Greshake et al. Not What Youāve Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection. In Proceedings of the 16th ACM Workshop on Artificial Intelligence and Security, pages 79ā90. ACM, 2023. [84] Jerome H. Saltzer and Michael D. Schroeder. The protection of information in computer systems. Proc. IEEE, 63(9):1278ā1308, 1975. [85] Dale Schuurmans. Memory Augmented Large Language Models are Computationally Universal. CoRR, abs/2301.04589, 2023. [86] JiÅĆ Wiedermann and Jan van Leeuwen. Large Language Models and the Extended ChurchāTuring Thesis. Electronic Proceedings in Theoretical Computer Science, 407:198ā213, 2024. Proceedings NCMA 2024. [87] Jake Bruce et al. Genie: Generative Interactive Environments. In Forty-first International Conference on Machine Learning, ICML 2024, Vienna, Austria, July 21-27, 2024, volume 235 of Proceedings of Machine Learning Research, pages 4603ā4623, 2024. [88] Diogo Almeida. Introducing System One Models & Jev. TypeSafe AI Blog, https://typesafe.ai/blog/introducing-system-one-models-and-jev, September 2026. Accessed 2026-10-04. [89] Jonathan Ho, Ajay Jain, and Pieter Abbeel. Denoising Diffusion Probabilistic Models. In Advances in Neural Information Processing Systems 33: Annual Conference on Neural Information Processing Systems 2020, NeurIPS 2020, December 6-12, 2020, virtual, pages 6840ā6851, 2020. [90] Philip J. Koopman, Jr. Stack Computers: The New Wave. Ellis Horwood, 1989. [91] Yunhe Shi et al. Virtual machine showdown: Stack versus registers. ACM Trans. Archit. Code Optim., 4(4):21:1ā21:36, 2008. [92] Intel Corporation. Intel 64 and IA-32 Architectures Software Developerās Manual, June 2024. Combined Volumes 1, 2Aā2D, 3Aā3D and 4, Order Number 325462-084US. Accessed 2026-10-02. [93] Nelson F. Liu et al. Lost in the Middle: How Language Models Use Long Contexts. Trans. Assoc. Comput. Linguistics, 12:157ā173, 2024. [94] Kiran Kate et al. LongFuncEval: Measuring the effectiveness of long context models for function calling. CoRR, abs/2505.10570, 2025. [95] Anthony Brohan et al. RT-2: Vision-Language-Action Models Transfer Web Knowledge to Robotic Control. In Proceedings of The 7th Conference on Robot Learning, volume 229 of Proceedings of Machine Learning Research, pages 2165ā2183, 2023. [96] Moo Jin Kim et al. OpenVLA: An Open-Source Vision-Language-Action Model. In Conference on Robot Learning, 6-9 November 2024, Munich, Germany, volume 270 of Proceedings of Machine Learning Research, pages 2679ā2713, 2025. [97] Dean M. Tullsen, Susan J. Eggers, and Henry M. Levy. Simultaneous Multithreading: Maximizing On-Chip Parallelism. In Proceedings of the 22nd Annual International Symposium on Computer Architecture, ISCA ā95, Santa Margherita Ligure, Italy, June 22-24, 1995, pages 392ā403, 1995. [98] The Linux kernel developers. The Linux Kernel. https://w.kernel.org/, 2026. Accessed 2026-10-02. [99] Dennis M. Ritchie and Ken Thompson. The UNIX Time-Sharing System. Commun. ACM, 17(7):365ā375, 1974. [100] GNU Project. The GNU C Library (glibc). https://w.gnu.org/software/libc/, 2026. Accessed 2026-10-02. [101] DeepSeek-AI et al. DeepSeek-V4.1-Flash: Pushing the Limits of KV Cache Compression. CoRR, abs/2609.19969, 2026. [102] Paul Barham et al. Xen and the art of virtualization. In Proceedings of the 19th ACM Symposium on Operating Systems Principles 2003, SOSP 2003, Bolton Landing, NY, USA, October 19-22, 2003, pages 164ā177, 2003. [103] Yingqiang Ge et al. LLM as OS, Agents as Apps: Envisioning AIOS, Agents and the AIOS-Agent Ecosystem. CoRR, abs/2312.03815, 2023. [104] Charles Packer et al. MemGPT: Towards LLMs as Operating Systems. CoRR, abs/2310.08560, 2023. Version 1. [105] Yapeng Mi et al. Building LLM Agents by Incorporating Insights from Computer Systems. CoRR, abs/2504.04485, 2025. [106] Hai Lin et al. Model-Native Computing Architecture: Envisioning Future System Architecture Through the Lens of Computer Architecture. CoRR, abs/2606.00288, 2026. [107] Anis Koubaa. Agent Operating Systems (Agent-OS): A Blueprint Architecture for Real-Time, Secure, and Scalable AI Agents. Preprints.org, 2025. [108] Gosia Steinder and Hubertus Franke. Towards an Agent Operating System - Lessons from Classical and Cloud OS. In IEEE International Conference on Web Services, ICWS 2026, Sydney, Australia, July 13-18, 2026, pages 1243ā1254, 2026. [109] Chaoyun Zhang et al. UFO2: The Desktop AgentOS. Trans. Mach. Learn. Res., 2026, 2026. [110] Gerald J. Popek and Robert P. Goldberg. Formal Requirements for Virtualizable Third Generation Architectures. Commun. ACM, 17(7):412ā421, 1974. [111] Junjia Qi et al. LLM-as-Code: Agentic Programming for Agent Harness. CoRR, abs/2606.15874, 2026. KDD 2026 Workshop on Agentic Software Engineering (AgenticSE). [112] Luke J. OāConnor. Self-Programmed Execution for Language-Model Agents. CoRR, abs/2605.06898, 2026. [113] Zhenhua Zou et al. AgentKernel: The Trust-Native Agentic Operating System. CoRR, abs/2609.29647, 2026. [114] Zhen Zhao et al. AgenticOS: An Intent-Oriented Secure Operating System Architecture for Autonomous AI Agents. CoRR, abs/2606.21129, 2026. [115] Jun He and Deying Yu. Sovereign Agentic Loops: Decoupling AI Reasoning from Execution in Real-World Systems. CoRR, abs/2604.22136, 2026. [116] Bardia Mohammadi and Laurent Bindschaedler. The Irreversibility Budget: Fleet-Level Risk Accounting and Admission Control for Agent Operating Systems. CoRR, abs/2609.00275, 2026. [117] Yingqi Zhang. Agent libOS: A Runtime Substrate for Capability-Controlled Self-Evolving LLM Agents. CoRR, abs/2606.03895, 2026. [118] Kiran Gopinathan et al. Pact: A Choreographic Language for Agentic Ecosystems. CoRR, abs/2605.03143, 2026. [119] Ruida Wang et al. Lean4Agent: Formal Modeling and Verification for Agent Workflow and Trajectory. CoRR, abs/2606.06523, 2026. [120] Andreas Schlapbach. Formal Semantics for Agentic Tool Protocols: A Process Calculus Approach. CoRR, abs/2603.24747, 2026. [121] Benedikt Bollig. Causal Past Logic for Runtime Verification of Distributed LLM Agent Workflows. CoRR, abs/2605.20923, 2026. [122] Haoyu Wang et al. ProbGuard: Proactive Runtime Monitoring for LLM Agent Safety via Probabilistic Prediction. CoRR, abs/2508.00500v4, 2026. [123] Zelong Li et al. Formal-LLM: Integrating Formal Language and Natural Language for Controllable LLM-based Agents. CoRR, abs/2402.00798, 2024. [124] Jie Wang. AI-Oracle Machines for Intelligent Computing. AI Matters, 10(3):8ā11, 2024. [125] Jie Wang. Token Complexity Theory for AI-Augmented Computing. CoRR, abs/2606.12647, 2026. [126] Jie Wang. Token Complexity of Certifying Stochastic-Oracle Reliability. CoRR, abs/2606.24074, 2026. [127] Jie Wang. Computing with Stochastic Oracles in AI-Augmented Computation. CoRR, abs/2607.06893, 2026. [128] Jie Wang. Computing with Agentic Oracles. CoRR, abs/2608.01464, 2026. [129] S. M. Rafiuddin and Muntaha Nujat Khan. A Formal Analysis of Chain-of-Thought Prompting via Turing Reductions. In Proceedings of the 14th International Joint Conference on Natural Language Processing and the 4th Conference of the Asia-Pacific Chapter of the Association for Computational Linguistics, IJCNLP-AACL 2025, Mumbai, India, December 20-24, 2025, pages 87ā98, 2025. [130] Roham Koohestani et al. Are Agents Probabilistic Automata? A Trace-Based, Memory-Constrained Theory of Agentic AI. CoRR, abs/2510.23487v2, 2026. [131] Jonathan Laurent and AndrĆ© Platzer. Oracular Programming: A Modular Foundation for Building LLM-Enabled Software. CoRR, abs/2502.05310, 2025. [132] Alessandro Achille and Stefano Soatto. AI Agents as Universal Task Solvers. Entropy, 28(3):332, 2026. [133] Jorge PĆ©rez, Javier MarinkoviÄ, and Pablo BarcelĆ³. On the Turing Completeness of Modern Neural Network Architectures. In 7th International Conference on Learning Representations, ICLR 2019, New Orleans, LA, USA, May 6-9, 2019, 2019. [134] Jorge PĆ©rez, Pablo BarcelĆ³, and Javier Marinkovic. Attention is Turing-Complete. J. Mach. Learn. Res., 22:75:1ā75:35, 2021. [135] Guhao Feng et al. Towards Revealing the Mystery behind Chain of Thought: A Theoretical Perspective. In Advances in Neural Information Processing Systems 36: Annual Conference on Neural Information Processing Systems 2023, NeurIPS 2023, New Orleans, LA, USA, December 10 - 16, 2023, 2023. [136] Franz Nowak et al. On the Representational Capacity of Neural Language Models with Chain-of-Thought Reasoning. In Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), ACL 2024, Bangkok, Thailand, August 11-16, 2024, pages 12510ā12548, 2024. [137] William Merrill and Ashish Sabharwal. The Expressive Power of Transformers with Chain of Thought. In The Twelfth International Conference on Learning Representations, ICLR 2024, Vienna, Austria, May 7-11, 2024, 2024. [138] Zhiyuan Li et al. Chain of Thought Empowers Transformers to Solve Inherently Serial Problems. In The Twelfth International Conference on Learning Representations, ICLR 2024, Vienna, Austria, May 7-11, 2024, 2024. [139] Angeliki Giannou et al. Looped Transformers as Programmable Computers. In International Conference on Machine Learning, ICML 2023, 23-29 July 2023, Honolulu, Hawaii, USA, pages 11398ā11442, 2023. [140] Ruizhong Qiu et al. Ask, and it shall be given: On the Turing completeness of prompting. In The Thirteenth International Conference on Learning Representations, ICLR 2025, Singapore, April 24-28, 2025, 2025. [141] Alex Graves, Greg Wayne, and Ivo Danihelka. Neural Turing Machines. CoRR, abs/1410.5401, 2014. [142] Samuel Holt, Max Ruiz Luyten, and Mihaela van der Schaar. L2MAC: Large Language Model Automatic Computer for Extensive Code Generation. In The Twelfth International Conference on Learning Representations, ICLR 2024, Vienna, Austria, May 7-11, 2024, 2024. [143] Dale Schuurmans, Hanjun Dai, and Francesco Zanini. Autoregressive Large Language Models are Computationally Universal. CoRR, abs/2410.03170, 2024. [144] Sergey Salishev. Transcript-Managed Transformers: Monotone Multi-Agent Collapse and Universality with Two Pop-Enabled Transcripts. CoRR, abs/2607.29496, 2026. [145] Xiangyu Wen et al. From Craft to Kernel: A Governance-First Execution Architecture and Semantic ISA for Agentic Computers. CoRR, abs/2604.18652, 2026. [146] Simon Poon. Toward Embedded Intelligence: Architecting CPUs with PC AI Agents. Research Square preprint, 2025. [147] Hadi Esmaeilzadeh et al. Neural Acceleration for General-Purpose Approximate Programs. In 45th Annual IEEE/ACM International Symposium on Microarchitecture, MICRO 2012, pages 449ā460. IEEE, 2012. [148] Anand S. Rao. AgentSpeak(L): BDI Agents Speak Out in a Logical Computable Language. In Agents Breaking Away, 7th European Workshop on Modelling Autonomous Agents in a Multi-Agent World, Eindhoven, The Netherlands, January 22-25, 1996, Proceedings, pages 42ā55, 1996. [149] Koen V. Hindriks et al. Agent Programming in 3APL. Auton. Agents Multi Agent Syst., 2(4):357ā401, 1999. [150] Frank S. de Boer et al. A verification framework for agent programming with declarative goals. J. Appl. Log., 5(2):277ā302, 2007. [151] Louise A. Dennis et al. Model checking agent programming languages. Autom. Softw. Eng., 19(1):5ā63, 2012. [152] Alessio Lomuscio, Hongyang Qu, and Franco Raimondi. MCMAS: an open-source model checker for the verification of multi-agent systems. Int. J. Softw. Tools Technol. Transf., 19(1):9ā30, 2017. [153] Louise A. Dennis. The MCAPL Framework including the Agent Infrastructure Layer and Agent Java Pathfinder. J. Open Source Softw., 3(24):617, 2018. [154] Michael J. Wooldridge and Nicholas R. Jennings. Intelligent agents: theory and practice. Knowl. Eng. Rev., 10(2):115ā152, 1995. [155] Lavindra de Silva, Felipe Meneguzzi, and Brian Logan. BDI Agent Architectures: A Survey. In Proceedings of the Twenty-Ninth International Joint Conference on Artificial Intelligence, IJCAI 2020, pages 4914ā4921, 2020. [156] Andrea Gatti, Viviana Mascardi, and Angelo Ferrando. ChatBDI: Think BDI, Talk LLM. In Proceedings of the 24th International Conference on Autonomous Agents and Multiagent Systems, AAMAS 2025, Detroit, MI, USA, May 19-23, 2025, pages 2541ā2543, 2025. [157] Mohammed Al Owayyed, Adarsh Denga, and Willem-Paul Brinkman. Controlled Yet Natural: A Hybrid BDI-LLM Conversational Agent for Child Helpline Training. In Proceedings of the 25th ACM International Conference on Intelligent Virtual Agents, IVA 2025, Berlin, Germany, September 16-19, 2025, pages 17:1ā17:10, 2025. [158] Rem Collier, Katharine Beaumont, and Andrei Ciortea. astra-langchain4j: Experiences Combining LLMs and Agent Programming. In Multi-Agent Systems - 22nd European Conference, EUMAS 2025, Bucharest, Romania, September 3-5, 2025, Proceedings, Part I, volume 16258 of Lecture Notes in Computer Science, pages 52ā68, 2026. [159] Andrea Agiollo and Andrea Omicini. Integrating Machine Learning into Belief-Desire-Intention Agents: Current Advances and Open Challenges. CoRR, abs/2510.20641, 2025. [160] Yoshua Bengio et al. A Neural Probabilistic Language Model. J. Mach. Learn. Res., 3:1137ā1155, 2003. [161] Ashish Vaswani et al. Attention is All you Need. In Advances in Neural Information Processing Systems 30: Annual Conference on Neural Information Processing Systems 2017, December 4-9, 2017, Long Beach, CA, USA, pages 5998ā6008, 2017. [162] Shunyu Yao et al. ReAct: Synergizing Reasoning and Acting in Language Models. In The Eleventh International Conference on Learning Representations, ICLR 2023, Kigali, Rwanda, May 1-5, 2023, 2023. [163] Theodore R. Sumers et al. Cognitive Architectures for Language Agents. Trans. Mach. Learn. Res., 2024, 2024. [164] Luca Beurer-Kellner, Marc Fischer, and Martin T. Vechev. Prompting Is Programming: A Query Language for Large Language Models. Proc. ACM Program. Lang., 7(PLDI):1946ā1969, 2023. [165] Omar Khattab et al. DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines. In The Twelfth International Conference on Learning Representations, ICLR 2024, 2024. [166] David Dohan et al. Language Model Cascades. CoRR, abs/2207.10342, 2022. [167] Louis Mandel et al. PPDL: LLM-Based Flows as Probabilistic Programs. In International Conference on Machine Learning, ICML 2026, 2026. [168] Imanol Schlag et al. Large Language Model Programs. CoRR, abs/2305.05364, 2023. [169] Qingyun Wu et al. AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversations. In First Conference on Language Modeling, COLM 2024, 2024. [170] Ranjan Sapkota, Konstantinos I. Roumeliotis, and Manoj Karkee. AI Agents vs. Agentic AI: A Conceptual taxonomy, applications and challenges. Inf. Fusion, 126:103599, 2026. [171] Xingyao Wang et al. Executable Code Actions Elicit Better LLM Agents. In Forty-first International Conference on Machine Learning, ICML 2024, Vienna, Austria, July 21-27, 2024, pages 50208ā50232, 2024. [172] Barry Zhang, Keith Lazuka, and Mahesh Murag. Equipping Agents for the Real World with Agent Skills. Anthropic Engineering, https://w.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills, 2025. October 16, 2025. Accessed 2026-10-02. [173] Anthropic. Introducing the Model Context Protocol. Anthropic News, https://w.anthropic.com/news/model-context-protocol, 2024. November 25, 2024. Accessed 2026-10-02. [174] Luca Beurer-Kellner, Marc Fischer, and Martin T. Vechev. Guiding LLMs The Right Way: Fast, Non-Invasive Constrained Generation. In Forty-first International Conference on Machine Learning, ICML 2024, Vienna, Austria, July 21-27, 2024, pages 3658ā3673, 2024. [175] Yusheng Zheng et al. When Can Agents Safely Checkpoint, Fork, Restore, and Merge? Exact Checking for Execution Edits. CoRR, abs/2608.22928, 2026. [176] Tianneng Shi et al. Progent: Securing AI Agents with Privilege Control. CoRR, abs/2504.11703v3, 2026. [177] Emil L. Post. Recursively enumerable sets of positive integers and their decision problems. Bulletin of the American Mathematical Society, 50(5):284ā316, 1944. [178] Theodore P. Baker, John Gill, and Robert Solovay. Relativizations of the P =? NP Question. SIAM J. Comput., 4(4):431ā442, 1975. [179] Mihir Bellare and Phillip Rogaway. Random Oracles are Practical: A Paradigm for Designing Efficient Protocols. In Proceedings of the 1st ACM Conference on Computer and Communications Security, CCS ā93, pages 62ā73. ACM, 1993. [180] Dana Angluin. Learning Regular Sets from Queries and Counterexamples. Information and Computation, 75(2):87ā106, 1987. [181] Susmit Jha and Sanjit A. Seshia. A Theory of Formal Synthesis via Inductive Learning. Acta Informatica, 54(7):693ā726, 2017. [182] Yurii Nesterov. Introductory Lectures on Convex Optimization. Applied Optimization. Springer, 2004. [183] Earl T. Barr et al. The Oracle Problem in Software Testing: A Survey. IEEE Transactions on Software Engineering, 41(5):507ā525, 2015. [184] Shafi Goldwasser, Silvio Micali, and Charles Rackoff. The Knowledge Complexity of Interactive Proof Systems. SIAM Journal on Computing, 18(1):186ā208, 1989. [185] LĆ”szlĆ³ Babai. Trading Group Theory for Randomness. In Proceedings of the 17th Annual ACM Symposium on Theory of Computing, STOC ā85, pages 421ā429. ACM, 1985. [186] Manuel Blum and Sampath Kannan. Designing Programs that Check Their Work. Journal of the ACM, 42(1):269ā291, 1995. [187] Uwe Schƶning. Robust Algorithms: A Different Approach to Oracles. Theoretical Computer Science, 40:57ā66, 1985. [188] Lekai Chen, Ashutosh Trivedi, and Alvaro Velasquez. LLMs as Probabilistic Minimally Adequate Teachers for DFA Learning. CoRR, abs/2408.02999, 2024. [189] Facundo Molina, Alessandra Gorla, and Marcelo dāAmorim. Test Oracle Automation in the Era of LLMs. ACM Transactions on Software Engineering and Methodology, 34(5):1ā24, 2025. [190] Noga Amit et al. Models That Prove Their Own Correctness. In Advances in Neural Information Processing Systems, NeurIPS 2025, 2025. [191] Vipul Goyal et al. Interactive Locking, Zero-Knowledge PCPs, and Unconditional Cryptography. In Advances in Cryptology, CRYPTO 2010, Lecture Notes in Computer Science, pages 173ā190. Springer, 2010. [192] Dina Goldin, Scott A. Smolka, and Peter Wegner, editors. Interactive Computation: The New Paradigm. Springer, Berlin, Heidelberg, 2006. [193] David Harel and Amir Pnueli. On the Development of Reactive Systems. In Krzysztof R. Apt, editor, Logics and Models of Concurrent Systems, volume 13 of NATO ASI Series F, pages 477ā498. Springer, Berlin, Heidelberg, 1985. [194] Dina Q. Goldin et al. Turing Machines, Transition Systems, and Interaction. Information and Computation, 194(2):101ā128, 2004. [195] Jan van Leeuwen and JiÅĆ Wiedermann. A Theory of Interactive Computation. In Dina Goldin, Scott A. Smolka, and Peter Wegner, editors, Interactive Computation: The New Paradigm, pages 119ā142. Springer, Berlin, Heidelberg, 2006. [196] Jan van Leeuwen and JiÅĆ Wiedermann. The Turing Machine Paradigm in Contemporary Computing. In Bjƶrn Engquist and Wilfried Schmid, editors, Mathematics Unlimited ā 2001 and Beyond, pages 1139ā1155. Springer, Berlin, Heidelberg, 2001. [197] Andreas Blass and Yuri Gurevich. Ordinary Interactive Small-Step Algorithms, I. ACM Transactions on Computational Logic, 7(2):363ā419, 2006. [198] Robert I. Soare. Turing Oracle Machines, Online Computing, and Three Displacements in Computability Theory. Annals of Pure and Applied Logic, 160(3):368ā399, 2009. [199] Dina Goldin and Peter Wegner. The Interactive Nature of Computing: Refuting the Strong ChurchāTuring Thesis. Minds and Machines, 18(1):17ā38, 2008. [200] Paul Cockshott and Greg Michaelson. Are There New Models of Computation? Reply to Wegner and Eberbach. The Computer Journal, 50(2):232ā247, 2007. [201] ErzsĆ©bet Csuhaj-VarjĆŗ et al. Parallel Communicating Pushdown Automata Systems. International Journal of Foundations of Computer Science, 11(4):631ā650, 2000. [202] Paul Blain Levy. Call-by-push-value: Decomposing call-by-value and call-by-name. High. Order Symb. Comput., 19(4):377ā414, 2006. [203] Paul Blain Levy. Adjunction Models For Call-By-Push-Value With Stacks. Theory and Applications of Categories, 14:75ā110, 2005. [204] Eugenio Moggi. Notions of Computation and Monads. Inf. Comput., 93(1):55ā92, 1991. [205] Andrzej Filinski. Declarative Continuations: an Investigation of Duality in Programming Language Semantics. In Category Theory and Computer Science, Manchester, UK, September 5-8, 1989, Proceedings, pages 224ā249, 1989. [206] Pierre-Louis Curien and Hugo Herbelin. The duality of computation. In Proceedings of the Fifth ACM SIGPLAN International Conference on Functional Programming (ICFP ā00), Montreal, Canada, September 18-21, 2000, pages 233ā243, 2000. [207] Philip Wadler. Call-by-value is dual to call-by-name. In Proceedings of the Eighth ACM SIGPLAN International Conference on Functional Programming, ICFP 2003, Uppsala, Sweden, August 25-29, 2003, pages 189ā201, 2003. [208] Peter Selinger. Control categories and duality: on the categorical semantics of the lambda-mu calculus. Math. Struct. Comput. Sci., 11(2):207ā260, 2001. [209] Noam Zeilberger. On the unity of duality. Ann. Pure Appl. Log., 153(1-3):66ā96, 2008. [210] Pierre-Louis Curien and Guillaume Munch-Maccagnoni. The Duality of Computation under Focus. In Theoretical Computer Science - 6th IFIP TC 1/WG 2.2 International Conference, TCS 2010, Held as Part of WCC 2010, Brisbane, Australia, September 20-23, 2010. Proceedings, pages 165ā181, 2010. [211] Paul Downen and Zena M. Ariola. A tutorial on computational classical logic and the sequent calculus. J. Funct. Program., 28:e3, 2018. [212] Jean-Marc Andreoli. Logic Programming with Focusing Proofs in Linear Logic. J. Log. Comput., 2(3):297ā347, 1992. [213] Remzi H. Arpaci-Dusseau and Andrea C. Arpaci-Dusseau. Operating Systems: Three Easy Pieces. Arpaci-Dusseau Books, version 1.10 edition, November 2023. [214] Andrew S. Tanenbaum and Herbert Bos. Modern Operating Systems. Pearson, 4th edition, 2014. [215] Avi Silberschatz and Peter Galvin. Operating System Concepts. Addison-Wesley, 4th edition, 1994. [216] Jochen Liedtke. On Micro-Kernel Construction. In Proceedings of the Fifteenth ACM Symposium on Operating Systems Principles, SOSP 1995, Copper Mountain Resort, Colorado, USA, December 3-6, 1995, pages 237ā250, 1995. [217] Dawson R. Engler, M. Frans Kaashoek, and James W. OāToole, Jr. Exokernel: An Operating System Architecture for Application-Level Resource Management. In Proceedings of the Fifteenth ACM Symposium on Operating Systems Principles, SOSP 1995, Copper Mountain Resort, Colorado, USA, December 3-6, 1995, pages 251ā266, 1995. [218] M. Frans Kaashoek et al. Application Performance and Flexibility on Exokernel Systems. In Proceedings of the Sixteenth ACM Symposium on Operating Systems Principles, SOSP 1997, St. Malo, France, October 5-8, 1997, pages 52ā65, 1997. [219] Donald E. Porter et al. Rethinking the library OS from the top down. In Proceedings of the 16th International Conference on Architectural Support for Programming Languages and Operating Systems, ASPLOS 2011, Newport Beach, CA, USA, March 5-11, 2011, pages 291ā304, 2011. [220] Anil Madhavapeddy et al. Unikernels: library operating systems for the cloud. In Architectural Support for Programming Languages and Operating Systems, ASPLOS 2013, Houston, TX, USA, March 16-20, 2013, pages 461ā472, 2013. [221] Michael D. Schroeder and Jerome H. Saltzer. A Hardware Architecture for Implementing Protection Rings. Commun. ACM, 15(3):157ā170, 1972. [222] Butler W. Lampson. Protection. ACM SIGOPS Oper. Syst. Rev., 8(1):18ā24, 1974. [223] Robert N. M. Watson et al. CHERI: A Hybrid Capability-System Architecture for Scalable Software Compartmentalization. In 2015 IEEE Symposium on Security and Privacy, SP 2015, San Jose, CA, USA, May 17-21, 2015, pages 20ā37, 2015. [224] Galen C. Hunt et al. Sealing OS processes to improve dependability and safety. In Proceedings of the 2007 EuroSys Conference, Lisbon, Portugal, March 21-23, 2007, pages 341ā354, 2007. [225] Moritz Lipp et al. Meltdown: Reading Kernel Memory from User Space. In 27th USENIX Security Symposium, USENIX Security 2018, Baltimore, MD, USA, August 15-17, 2018, pages 973ā990, 2018. [226] Paul Kocher et al. Spectre Attacks: Exploiting Speculative Execution. In 2019 IEEE Symposium on Security and Privacy, SP 2019, San Francisco, CA, USA, May 19-23, 2019, pages 1ā19, 2019. [227] Dorothy E. Denning. A Lattice Model of Secure Information Flow. Commun. ACM, 19(5):236ā243, 1976. [228] Stephen Soltesz et al. Container-based operating system virtualization: a scalable, high-performance alternative to hypervisors. In Proceedings of the 2007 EuroSys Conference, Lisbon, Portugal, March 21-23, 2007, pages 275ā287, 2007. [229] Dayeol Lee et al. Keystone: an open framework for architecting trusted execution environments. In EuroSys ā20: Fifteenth EuroSys Conference 2020, Heraklion, Greece, April 27-30, 2020, pages 38:1ā38:16, 2020. [230] Luke Nelson et al. Hyperkernel: Push-Button Verification of an OS Kernel. In Proceedings of the 26th Symposium on Operating Systems Principles, Shanghai, China, October 28-31, 2017, pages 252ā269, 2017. [231] Ronghui Gu et al. Deep Specifications and Certified Abstraction Layers. In Proceedings of the 42nd Annual ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, POPL 2015, Mumbai, India, January 12-14, 2015, pages 595ā608, 2015. [232] Gregory Malecha et al. Modular, Full-System Verification. In Proceedings of the Workshop on Hot Topics in Operating Systems, HotOS 2025, Banff, Alberta, Canada, May 19-21, 2025, pages 42ā49, 2025. [233] Ritik Raj, Hong Wang, and Tushar Krishna. A CPU-Centric Perspective on Agentic AI. CoRR, abs/2511.00739, 2025. Version 2. [234] Buu Phan et al. Understanding and Mitigating Tokenization Bias in Language Models. CoRR, abs/2406.16829, 2024. [235] Butler W. Lampson. A Note on the Confinement Problem. Commun. ACM, 16(10):613ā615, 1973. [236] James P. Anderson. Computer Security Technology Planning Study. Technical Report ESD-TR-73-51, Vol. I, Electronic Systems Division, Air Force Systems Command, Hanscom Field, October 1972. NTIS AD-758 206. [237] J. A. Goguen and J. Meseguer. Security Policies and Security Models. In 1982 IEEE Symposium on Security and Privacy, Oakland, California, USA, April 26-28, 1982, pages 11ā20, 1982. [238] Roy Levin et al. Policy/Mechanism Separation in Hydra. In Proceedings of the Fifth ACM Symposium on Operating Systems Principles, SOSP 1975, Austin, Texas, USA, November 19-21, 1975, pages 132ā140, 1975. [239] Edoardo Debenedetti et al. AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents. In Advances in Neural Information Processing Systems 37: Annual Conference on Neural Information Processing Systems 2024, NeurIPS 2024, Vancouver, BC, Canada, December 10 - 15, 2024, 2024. [240] Li Zhang, Yang Sun, and Jie Shi. When the Agent Becomes the Kernel: A Systematization of Security on the Path to AI-Native Operating Systems. CoRR, abs/2609.23700, 2026. [241] Avi Kivity et al. KVM: The Linux Virtual Machine Monitor. In Proceedings of the Linux Symposium, Volume One, Ottawa, Ontario, Canada, June 27-30, 2007, pages 225ā230, 2007. [242] Jean Berstel. Transductions and context-free languages. Teubner, 1979. [243] Tim Vieira et al. Language Models over Canonical Byte-Pair Encodings. In Forty-second International Conference on Machine Learning, ICML 2025, Vancouver, BC, Canada, July 13-19, 2025, volume 267 of Proceedings of Machine Learning Research, pages 61413ā61443, 2025. [244] Edoardo Debenedetti et al. Defeating Prompt Injections by Design. In IEEE Conference on Secure and Trustworthy Machine Learning, SaTML 2026, Munich, Germany, March 23-25, 2026, pages 587ā618, 2026. [245] Christian Choffrut. A Generalization of Ginsburg and Roseās Characterization of G-S-M Mappings. In Automata, Languages and Programming, 6th Colloquium, Graz, Austria, July 16-20, 1979, Proceedings, pages 88ā103, 1979. [246] Martin Berglund, Willeke Martens, and Brink van der Merwe. Constructing a BPE Tokenization DFA. In Implementation and Application of Automata - 28th International Conference, CIAA 2024, Akita, Japan, September 3-6, 2024, Proceedings, pages 66ā78, 2024. [247] Shenghu Jiang and Ruihao Gong. Incremental BPE Tokenization. In Proceedings of the 43rd International Conference on Machine Learning, volume 306 of Proceedings of Machine Learning Research, pages 52312ā52342, 2026. [248] Ben Athiwaratkun et al. Token Alignment via Character Matching for Subword Completion. In Findings of the Association for Computational Linguistics, ACL 2024, Bangkok, Thailand and virtual meeting, August 11-16, 2024, pages 15725ā15738, 2024. [249] Buu Phan et al. Exact Byte-Level Probabilities from Tokenized Language Models for FIM-Tasks and Model Ensembles. In The Thirteenth International Conference on Learning Representations, ICLR 2025, Singapore, April 24-28, 2025, 2025. [250] Tim Vieira et al. From Language Models over Tokens to Language Models over Characters. In Forty-second International Conference on Machine Learning, ICML 2025, Vancouver, BC, Canada, July 13-19, 2025, 2025. [251] Jonathan Hayase et al. Sampling from Your Language Model One Byte at a Time. In Proceedings of the 43rd International Conference on Machine Learning, volume 306 of Proceedings of Machine Learning Research, pages 40999ā41026, 2026. [252] Karl Pertsch et al. FAST: Efficient Action Tokenization for Vision-Language-Action Models. In Robotics: Science and Systems XXI, 2025. [253] Fangzhou Wu, Ethan Cecchetti, and Chaowei Xiao. System-Level Defense against Indirect Prompt Injection Attacks: An Information Flow Control Perspective. CoRR, abs/2409.19091, 2024. [254] Manuel Costa et al. Securing AI Agents with Information-Flow Control. CoRR, abs/2505.23643, 2025. [255] Simon Willison. The Dual LLM Pattern for Building AI Assistants That Can Resist Prompt Injection. Blog post, https://simonwillison.net/2023/Apr/25/dual-llm-pattern/, 2023. April 25, 2023. Accessed 2026-10-02. [256] Dennis Jacob et al. Preventing Prompt Injection with Type-Directed Privilege Separation. CoRR, abs/2509.25926v2, 2026. [257] Yuhao Wu et al. IsolateGPT: An Execution Isolation Architecture for LLM-Based Agentic Systems. In 32nd Annual Network and Distributed System Security Symposium, NDSS 2025, San Diego, California, USA, February 24-28, 2025, 2025. [258] Keegan Hines et al. Defending Against Indirect Prompt Injection Attacks With Spotlighting. In Proceedings of the Conference on Applied Machine Learning in Information Security, CAMLIS 2024, Arlington, VA, USA, October 24-25, 2024, volume 3920 of CEUR Workshop Proceedings, pages 48ā62, 2025. [259] Sizhe Chen et al. StruQ: Defending Against Prompt Injection with Structured Queries. In 34th USENIX Security Symposium, USENIX Security 2025, Seattle, WA, USA, August 13-15, 2025, pages 2383ā2400, 2025. [260] Eric Wallace et al. The Instruction Hierarchy: Training LLMs to Prioritize Privileged Instructions. CoRR, abs/2404.13208, 2024. [261] Yuxuan Zhang, Jeff Huang, and Guofei Gu. Origin Is All You Need: Provenance-Aware Transformers for Structural Trust-Boundary Separation. CoRR, abs/2609.21088, 2026. [262] Kaijie Zhu et al. MELON: Provable Defense Against Indirect Prompt Injection Attacks in AI Agents. In Forty-second International Conference on Machine Learning, ICML 2025, Vancouver, BC, Canada, July 13-19, 2025, volume 267 of Proceedings of Machine Learning Research, pages 80310ā80329, 2025. [263] Lukas Pirch et al. Toward Securing AI Agents Like Operating Systems. CoRR, abs/2605.14932, 2026. [264] Mohammadali Khodabandehlou and Mahdi Alizadeh. AKTS: Sub-Microsecond Kernel Policy Switching for Language-Model Agents. CoRR, abs/2609.12276, 2026. [265] Luca Beurer-Kellner et al. Design Patterns for Securing LLM Agents against Prompt Injections. CoRR, abs/2506.08837, 2025. [266] Xingbang He et al. When Context Gets Root: Privilege Escalation in LLM Harnesses. CoRR, abs/2608.27299, 2026. [267] Asaf Degani and Michael Heymann. Formal Verification of Human-Automation Interaction. Human Factors, 44(1):28ā43, 2002. [268] SĆ©bastien CombĆ©fis and Charles Pecheur. A bisimulation-based approach to the analysis of human-computer interaction. In Proceedings of the 1st ACM SIGCHI Symposium on Engineering Interactive Computing Systems, EICS 2009, pages 101ā110, 2009. [269] Matthew L. Bolton, Ellen J. Bass, and Radu I. Siminiceanu. Using Formal Verification to Evaluate Human-Automation Interaction: A Review. IEEE Transactions on Systems, Man, and Cybernetics: Systems, 43(3):488ā503, 2013. [270] Dafna Shahaf and Eyal Amir. Towards a Theory of AI Completeness. In Logical Formalizations of Commonsense Reasoning, Papers from the 2007 AAAI Spring Symposium, number S-07-05 in AAAI Technical Report, pages 150ā155. AAAI Press, 2007. [271] Greg Little et al. TurKit: Human Computation Algorithms on Mechanical Turk. In Proceedings of the 23rd Annual ACM Symposium on User Interface Software and Technology, UIST 2010, pages 57ā66, 2010. [272] Bettina Kƶnighofer et al. Shield synthesis. Formal Methods in System Design, 51(2):332ā361, 2017. [273] A. M. Turing. On Computable Numbers, with an Application to the Entscheidungsproblem. Proceedings of the London Mathematical Society, s2-42(1):230ā265, 1937. [274] Charles E. Billings. Human-Centered Aviation Automation: Principles and Guidelines. Technical Memorandum 110381, NASA, 1996. https://ntrs.nasa.gov/citations/19960016374. [275] Toshiyuki Inagaki. Situation-Adaptive Autonomy: Dynamic Trading of Authority between Human and Automation. Proceedings of the Human Factors and Ergonomics Society Annual Meeting, 44(13):13ā16, 2000. [276] J. C. R. Licklider. Man-Computer Symbiosis. IRE Transactions on Human Factors in Electronics, HFE-1(1):4ā11, 1960. [277] Thomas B. Sheridan and William L. Verplank. Human and Computer Control of Undersea Teleoperators. Technical report, Man-Machine Systems Laboratory, Massachusetts Institute of Technology, 1978. DTIC ADA057655. [278] R. Parasuraman, T.B. Sheridan, and C.D. Wickens. A model for types and levels of human interaction with automation. IEEE Transactions on Systems, Man, and Cybernetics, Part A, 30(3):286ā297, 2000. [279] John Rushby. Using model checking to help discover mode confusions and other automation surprises. Reliability Engineering & System Safety, 75(2):167ā177, 2002. [280] Franziska Roesner et al. User-Driven Access Control: Rethinking Permission Granting in Modern Operating Systems. In 2012 IEEE Symposium on Security and Privacy, SP 2012, pages 224ā238, 2012. [281] U.S. Department of Defense. Trusted Computer System Evaluation Criteria. Technical Report DoD 5200.28-STD, Department of Defense, December 1985. [282] Adrienne Porter Felt et al. Android Permissions: User Attention, Comprehension, and Behavior. In Symposium On Usable Privacy and Security, SOUPS 2012, pages 1ā14, 2012. [283] Yuhang Cao. Continuous Interaction Diffusion: A Diffusion-Native Runtime for Asynchronous Tool-Augmented Reasoning. CoRR, abs/2608.10438, 2026. [284] Yueen Ma et al. A Survey on Vision-Language-Action Models for Embodied AI. IEEE Trans. Neural Networks Learn. Syst., 37(7):3031ā3051, 2026. [285] Lucen Zhong et al. ComplexFuncBench: Exploring Multi-Step and Constrained Function Calling under Long-Context Scenario. CoRR, abs/2501.10132, 2025. [286] Shishir G. Patil et al. The Berkeley Function Calling Leaderboard (BFCL): From Tool Use to Agentic Evaluation of Large Language Models. In Forty-second International Conference on Machine Learning, ICML 2025, Vancouver, BC, Canada, July 13-19, 2025, volume 267 of Proceedings of Machine Learning Research, pages 48371ā48392, 2025. [287] Cheng-Ping Hsieh et al. RULER: Whatās the Real Context Size of Your Long-Context Language Models? In First Conference on Language Modeling, COLM 2024, 2024. [288] Ali Modarressi et al. NoLiMa: Long-Context Evaluation Beyond Literal Matching. In Forty-second International Conference on Machine Learning, ICML 2025, Vancouver, BC, Canada, July 13-19, 2025, volume 267 of Proceedings of Machine Learning Research, pages 44554ā44570, 2025. [289] Kelly Hong, Anton Troynikov, and Jeff Huber. Context Rot: How Increasing Input Tokens Impacts LLM Performance. Technical report, Chroma, jul 2025. [290] Yufeng Du et al. Context Length Alone Hurts LLM Performance Despite Perfect Retrieval. In Findings of the Association for Computational Linguistics: EMNLP 2025, Suzhou, China, November 4-9, 2025, pages 23281ā23298, 2025. [291] Ryan Liu et al. Mind Your Step (by Step): Chain-of-Thought can Reduce Performance on Tasks where Thinking Makes Humans Worse. In Forty-second International Conference on Machine Learning, ICML 2025, Vancouver, BC, Canada, July 13-19, 2025, volume 267 of Proceedings of Machine Learning Research, pages 38489ā38517, 2025. [292] Nouha Dziri et al. Faith and Fate: Limits of Transformers on Compositionality. In Advances in Neural Information Processing Systems 36: Annual Conference on Neural Information Processing Systems 2023, NeurIPS 2023, New Orleans, LA, USA, December 10 - 16, 2023, pages 70293ā70332, 2023. [293] Muru Zhang et al. How Language Model Hallucinations Can Snowball. In Forty-first International Conference on Machine Learning, ICML 2024, Vienna, Austria, July 21-27, 2024, volume 235 of Proceedings of Machine Learning Research, pages 59670ā59684, 2024. [294] Gregor Bachmann and Vaishnavh Nagarajan. The Pitfalls of Next-Token Prediction. In Forty-first International Conference on Machine Learning, ICML 2024, Vienna, Austria, July 21-27, 2024, pages 2296ā2318, 2024. [295] Lijie Chen, Binghui Peng, and Hongxun Wu. Theoretical limitations of multi-layer Transformer. In 66th IEEE Annual Symposium on Foundations of Computer Science, FOCS 2025, Sydney, Australia, December 14-17, 2025, pages 2631ā2653, 2025. [296] Alireza Amiri Bavandpour et al. Lower Bounds for Chain-of-Thought Reasoning in Hard-Attention Transformers. In Proceedings of the 42nd International Conference on Machine Learning, volume 267 of Proceedings of Machine Learning Research, pages 3274ā3306, 2025. [297] Tughanbulut Kurtulush. When Chain-of-Thought Helps and When It Hurts: An Empirical Investigation of the Serial-Depth Bottleneck in LLM Reasoning. CoRR, abs/2608.09942, 2026. [298] T. E. Harris. On chains of infinite order. Pacific Journal of Mathematics, 5(5):707ā724, 1955. [299] Henry Berbee. Chains with infinite connections: Uniqueness and Markov representation. Probability Theory and Related Fields, 76(2):243ā253, 1987. [300] Roberto FernĆ”ndez and Antonio Galves. Markov approximations of chains of infinite order. Bulletin of the Brazilian Mathematical Society, 33(3):295ā306, 2002. [301] Roberto FernĆ”ndez and GrĆ©gory Maillard. Chains with Complete Connections: General Theory, Uniqueness, Loss of Memory and Mixing Properties. Journal of Statistical Physics, 118(3-4):555ā588, 2005. [302] Swaraj Dash et al. Affine Monads and Lazy Structures for Bayesian Programming. Proc. ACM Program. Lang., 7(POPL):1338ā1368, 2023. [303] NVIDIA et al. GR00T N1: An Open Foundation Model for Generalist Humanoid Robots. CoRR, abs/2503.14734, 2025. [304] Figure AI. Helix: A Vision-Language-Action Model for Generalist Humanoid Control. https://w.figure.ai/news/helix, 2025. February 20, 2025. [305] Lucy Xiaoyang Shi et al. Hi Robot: Open-Ended Instruction Following with Hierarchical Vision-Language-Action Models. In Forty-second International Conference on Machine Learning, ICML 2025, volume 267 of Proceedings of Machine Learning Research, 2025. [306] Jacky Liang et al. Code as Policies: Language Model Programs for Embodied Control. In IEEE International Conference on Robotics and Automation, ICRA 2023, pages 9493ā9500, 2023. [307] Wenlong Huang et al. VoxPoser: Composable 3D Value Maps for Robotic Manipulation with Language Models. In Conference on Robot Learning, CoRL 2023, 2023. [308] Yang Liu et al. PhyAgentOS: A Self-Evolving Operating System for Embodied Agents with Decoupled Cognitive Planning and Physical Execution. CoRR, abs/2607.16636, 2026. [309] Mido Assran et al. V-JEPA 2: Self-Supervised Video Models Enable Understanding, Prediction and Planning. CoRR, abs/2506.09985, 2025. [310] Alexander Robey et al. Jailbreaking LLM-Controlled Robots. In IEEE International Conference on Robotics and Automation, ICRA 2025, 2025. [311] Zachary Ravichandran et al. Safety Guardrails for LLM-Enabled Robots. IEEE Robotics Autom. Lett., 11(4):4649ā4656, 2026. [312] Songqiao Hu et al. VLSA: Vision-Language-Action Models with Plug-and-Play Safety Constraint Layer. CoRR, abs/2512.11891, 2025. Accepted at IROS 2026. [313] Lui Sha. Using simplicity to control complexity. IEEE Software, 18(4):20ā28, 2001. [314] Steven Macenski et al. Robot Operating System 2: Design, architecture, and uses in the wild. Science Robotics, 7(66), 2022. [315] Victor Mayoral Vilches et al. SROS2: Usable Cyber Security Tools for ROS 2. In IEEE/RSJ International Conference on Intelligent Robots and Systems, IROS 2022, 2022. [316] Luyu Gao et al. PAL: Program-aided Language Models. In International Conference on Machine Learning, ICML 2023, volume 202 of Proceedings of Machine Learning Research, 2023. [317] Wenhu Chen et al. Program of Thoughts Prompting: Disentangling Computation from Reasoning for Numerical Reasoning Tasks. Transactions on Machine Learning Research, 2023. [318] Chengshu Li et al. Chain of Code: Reasoning with a Language Model-Augmented Code Emulator. In Forty-first International Conference on Machine Learning, ICML 2024, volume 235 of Proceedings of Machine Learning Research, 2024. [319] Zhibin Gou et al. ToRA: A Tool-Integrated Reasoning Agent for Mathematical Problem Solving. In The Twelfth International Conference on Learning Representations, ICLR 2024, 2024. [320] Jiazhan Feng et al. ReTool: Reinforcement Learning for Strategic Tool Use in LLMs. CoRR, abs/2504.11536, 2025. [321] OpenAI. OpenAI o3 and o4-mini System Card. https://openai.com/index/o3-o4-mini-system-card/, 2025. April 16, 2025. [322] Nathaniel Weir et al. Learning to Reason via Program Generation, Emulation, and Search. In Advances in Neural Information Processing Systems 37, NeurIPS 2024, 2024. [323] Hyungjoo Chae et al. Language Models as Compilers: Simulating Pseudocode Execution Improves Algorithmic Reasoning in Language Models. In Proceedings of the 2024 Conference on Empirical Methods in Natural Language Processing, EMNLP 2024, 2024. [324] Shibo Hao et al. Training Large Language Models to Reason in a Continuous Latent Space. In Second Conference on Language Modeling, COLM 2025, 2025. [325] Alex Gu et al. CRUXEval: A Benchmark for Code Reasoning, Understanding and Execution. In Forty-first International Conference on Machine Learning, ICML 2024, volume 235 of Proceedings of Machine Learning Research, 2024. [326] Yiheng Xu et al. Lemur: Harmonizing Natural Language and Code for Language Agents. In The Twelfth International Conference on Learning Representations, ICLR 2024, 2024. [327] Viraat Aryabumi et al. To Code, or Not To Code? Exploring Impact of Code in Pre-training. In The Thirteenth International Conference on Learning Representations, ICLR 2025, 2025. [328] Sainbayar Sukhbaatar et al. Branch-Train-MiX: Mixing Expert LLMs into a Mixture-of-Experts LLM. In First Conference on Language Modeling, COLM 2024, 2024. [329] Dan Biderman et al. LoRA Learns Less and Forgets Less. Transactions on Machine Learning Research, 2024. [330] Guanting Dong et al. How Abilities in Large Language Models are Affected by Supervised Fine-tuning Data Composition. In Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), ACL 2024, 2024. [331] Yuxiang Wei et al. SWE-RL: Advancing LLM Reasoning via Reinforcement Learning on Open Software Evolution. In Advances in Neural Information Processing Systems 38, NeurIPS 2025, 2025. [332] Aider. Separating Code Reasoning and Editing. Aider blog, https://aider.chat/2024/09/26/architect.html, 2024. September 26, 2024. [333] Adam Fourney et al. Magentic-One: A Generalist Multi-Agent System for Solving Complex Tasks. CoRR, abs/2411.04468, 2024. [334] An Yang et al. Qwen3 Technical Report. CoRR, abs/2505.09388, 2025. [335] Qwen Team. Qwen3-235B-A22B-Instruct-2507. Model card, https://huggingface.co/Qwen/Qwen3-235B-A22B-Instruct-2507, 2025. Announced July 21, 2025. [336] Hongru Wang et al. Acting Less is Reasoning More! Teaching Model to Act Efficiently. CoRR, abs/2504.14870, 2025. [337] In Gim, Seung seob Lee, and Lin Zhong. Asynchronous LLM Function Calling. CoRR, abs/2412.07017, 2024. [338] Jiabao Ji et al. Speculate While You Reason: Teaching Agents to Predict Their Next Tool Call via Joint Agent-Speculator RL. CoRR, abs/2607.25816, 2026. [339] Fay Chang and Garth A. Gibson. Automatic I/O Hint Generation through Speculative Execution. In Proceedings of the Third Symposium on Operating Systems Design and Implementation, OSDI 1999. USENIX Association, 1999. [340] Naimeng Ye et al. Speculative Actions: A Lossless Framework for Faster Agentic Systems. CoRR, abs/2510.04371, 2025. [341] Daniel Nichols et al. Optimizing Agentic Language Model Inference via Speculative Tool Calls. CoRR, abs/2512.15834, 2025. [342] Jiangnan Yu et al. TomasuLLM: Out-of-Order Speculative Execution for LLM Agents. CoRR, abs/2609.38201, 2026. [343] Bardia Mohammadi et al. Atomix: Timely, Transactional Tool Use for Reliable Agentic Workflows. CoRR, abs/2602.14849, 2026. [344] Bardia Mohammadi et al. Ghost Tool Calls: Issue-Time Privacy for Speculative Agent Tools. CoRR, abs/2606.02483, 2026. [345] Milad Hashemi et al. Learning Memory Access Patterns. In Proceedings of the 35th International Conference on Machine Learning, ICML 2018, volume 80 of Proceedings of Machine Learning Research, pages 1919ā1928, 2018. [346] Avanika Narayan et al. Cost-efficient Collaboration between On-device and Cloud Language Models. In Forty-second International Conference on Machine Learning, ICML 2025, volume 267 of Proceedings of Machine Learning Research, 2025. Appendix A Glossary and Notation Agentic system. A system that uses language models to carry out concrete tasks. It has two forms, Workflows and Agents [8]. On the O-2-PDA-TS they are the Workflow form and the Agent form of Definition 3.10. Agent harness. A system that runs Agents. In this paper: the machine, the operating-system kernel and the system library. A harness on an ordinary computer implements the machine, the kernel and part of the library in one program (Ā§3). Agent runtime. The infrastructure of an Agent harness: the machine and the kernel. Agent scaffold. The system library together with the programs a task may run: the kernel-and-library side of the machine, Ī“Ī _ , LĪL_ and the handlers. It exposes its operations to the task as thunks (Ā§3.5). Workflow engine. A system that runs Workflows. In this paper: the machine and programs that run on the bare machine, with no operating system between them and the Oracle. Operating system. A kernel and a system library (Definition 3.8). The kernel runs in P-mode. The libraryās declaration sits in the taskās history, and the code that serves its requests is in the kernel. Where no confusion arises we call the kernel the operating system. Stack, colour, type, mode, computation. Five different notions (Ā§3). A stack is storage, and its colour, O or P, is fixed (Definition 2.3). A type, D or UāBU\,B, says whether a stored element is data or a suspended program. A mode, O-mode or P-mode, says whether the Oracleās answers or the Priestessās code choose the next transition. A computation, the Priestess computation or the one inside the Oracle, is one of the two computations of a run. Table 11 collects the terms and symbols of Ā§3. Term or symbol Meaning Defined in Oracle stack, Priestess stack a stack coloured O, P Def 2.3 P-mode āØ,ā,Ļā© P, ,Ļ , O-mode āØ,u,Ļā© O,u,Ļ the two modes of T, each with the form of its configurations Def 3.3 ā® , yield the yield symbol; an answer that ends with it Def 3.3 ātrap _trap the trap label, where every trap continues Def 3.3 āu uret\ u enters O-mode on the stack u, which under S is an Oracle stack Def 3.3 trap, yield trap, excursion a transition from O- to P-mode; one caused by a yield; a maximal O-mode segment with its uret and trap Def 3.3 āuāĪ² uret\ u\ Ī², budget trap entry with a budget of Ī² O-mode transitions; the trap when it is spent Def 3.6 K1āK5 the kernel contract Thm 3.4, Prop 3.7 k, service entry the kernelās code at ātrap _trap, as the thunk ā”(ātrap) thunk( _trap) Defs 3.3, 3.8 task, task stack, history a unit of work; the Oracle stack the kernel enters for it; that stackās content Def 3.8 request, reply, system call what a yield appended since the last write; what the kernel writes back; a request in LĪL_ Def 3.8 Ī=(LĪ,Ī“Ī) =(L_ , _ ) the library: request language and declaration Def 3.8 K, C, Ī kernel code, task code, task data Def 3.9 a taskās program its executable part: history content the Oracle runs, or task code Def 3.9 Table 11: Terms and symbols of Section 3. Appendix B Proofs This appendix contains the proofs omitted from the body, in the order of the results. The other proofs are short enough to sit beside their statements. Proof of Lemma 2.2. Let s be a segment of a. The case of b is symmetric. The block moves the segments above s from a onto b, one symbol at a time, keeping their markers, until s is the top segment of a. The instruction is then performed on the top of a. A marker at the top means that s is empty: a jeq for ā„ succeeds there, and a pop leads to a stuck configuration, as it would on a stack of its own. The symbols moved aside are then transferred back in the reverse order, which restores their order. The segments below s and those already on b were never touched. Each block moves and restores a finite prefix, so it takes finitely many steps. ā The split lemma and the Oracle instruction. Lemma 2.2 extends to the Oracle instruction on a logical stack s. The block rearranges the tape held by a and b so that s lies alone on a, in order, and every other logical stack, with its markers, lies on b. This is a computable rearrangement of a finite tape, which the 2-PDA performs by simulating a Turing machine on its two stacks, ending with the head between s and the rest. The block then executes the Oracle instruction on a, and rearranges the tape back, with s now longer by the answer. After a rejection it rearranges the tape back and continues at lel_e. This extension is what the proof of Lemma 2.6 uses. Construction for Proposition 3.11. Rename each task stack u to a fresh Priestess stack dud_u, and relocate the programās jump targets to account for the code inserted below. Replace each āu uret\ u by code that records u as one fresh symbol on a fresh Priestess stack and then loops: call the Oracle on dud_u, with a rejection label at which the run is stuck (a pop on a fresh empty stack); if the top of dud_u is ā® , jump to ātrap _trap; otherwise loop. Since every answer is non-empty (Ā§2), the top of dud_u after an accepted call is the last symbol of the new answer, so the test is exactly whether the answer is a yield, and the loop runs exactly the excursion that āu uret\ u would have run. A rejected query leaves both runs stuck: the run of K because Definition 3.3 gives no successor, and the run of KāK at its rejection label. The rest of the program is unchanged. With budgets (Definition 3.6), the code also empties a fresh Priestess stack, pushes Ī² symbols onto it, pops one after each call that does not yield, and jumps to ātrap _trap when it is empty. ā The convention of non-empty answers (Ā§2) ensures that the interpreter tests a stack top that belongs to the new answer. With an empty answer, a history already ending in ā® would retain that symbol, and the interpreter would incorrectly terminate the current excursion. Proof of Proposition 3.12. A task in Agent form is entered with uret on its task stack, and a task in Workflow form calls the Oracle in P-mode (Definition 3.10), which gives the first claim. Let Uā©C=ā Uā© C= , and let a P-mode call read its operand d. The colour of d lies in C and so not in U, so no uret enters d. The O-mode rules are those of Definition 3.3, so K1 holds as proved, and no excursion writes d. By the locality lemma, d then holds only what the Priestess wrote there and the answers of earlier P-mode calls on it. Conversely, let cāUā©Ccā Uā© C, and let s be a stack of colour c, empty at the start. Take the program ās uret\ s, āsā 3 oracle\ s\ 3 with ātrap=2 _trap=2, and the Oracle whose encoder and decoder are identities and whose only answer is ā® , so that Oā”(w)=ā®O(w)=\ \ for every wāĪ£Qāwā _Q^*. The run enters O-mode on s, appends ā® and traps to ātrap _trap, where the P-mode call reads the ā® that O-mode appended. Finally, with two colours the only non-empty disjoint sets U and C are O\O\ and P\P\, in either order, and the exchange Īµ of the colours (Ā§2) maps one machine to the other. ā Proof of Proposition 5.1. (1) Definition 3.3 gives O-mode rules only for accepted queries. The transition does not trap, so the next query is made in O-mode, and it is the history followed by the answer, which is not in Ī£Qā=domā”(E) _Q^*=dom(E). (2) ĻāDĻ D writes only symbols of Ī£Q _Q, so the wrapped Oracle satisfies the hypotheses of Proposition 4.5. (3) The wrapping changes neither A nor E, and Definition 4.1 requires of the decoder only that it work symbol by symbol, that Ļ decode to ā® , and that ā® occur in no other decoding. The map Ļ is applied symbol by symbol, fixes ā® and, being injective, maps no other symbol to it. Conversely, since Ļ is injective and fixes ā® , D has these properties when ĻāDĻ D does. ā Appendix C More on Eclipse This appendix collects the parts of Ā§4 that the body summarizes: encoders in more detail, the algebra of hierarchies, the stores of the two sides, the coherence of the encoding cache, the prefix chain in the two forms, the schedulers, a budget trap inside a Frame, where non-empty answers and Frame-faithfulness hold, what keeping, dropping or hiding a modelās reasoning changes, and the rest of the safety analysis. C.1 Encoders Bounded variation. The loss of Definition 4.2 is a Step-level form of bounded variation [58], after [242]: if words at left distance k have encodings at left distance at most CkC_k, then lossEā(w,v)ā¤C|v|loss_E(w,v)ā¤ C_|v|, where the left distance of x and xā²x is |x|+|xā²|ā2ā|lcpā”(x,xā²)||x|+|x |-2\,|lcp(x,x )|. Separators in practice. Splitting at whitespace gives factorization at whitespace, but whitespace is not the separator. With a proper dictionary, BPE as implemented has a finite lookahead constant, which depends on the dictionary alone and beyond which a prefix of the tokenization is stable [59]. Its Step backtrack is therefore finite and depends on the dictionary. An encoder need not be so well behaved. With Oracle symbols a and aāa and longest match from the right end, the encodings Eā”(a2ām)=[aāa]mE(a^2m)=[a]^m and Eā”(a2ām+1)=[a]ā[aāa]mE(a^2m+1)=[a][a]^m share no prefix, so one appended a loses m symbols, and the Step backtrack is unbounded with a vocabulary of two symbols. The decoder. The decoder works symbol by symbol (Definition 4.1): the decoding of a prefix of an answer is a prefix of its decoding. In practice, when the machine-side symbols are characters, byte-level vocabularies are the exception: a token may end inside a multi-byte character. Such a decoder buffers an unfinished character until its last byte arrives, and the decoding of a prefix of an answer is again a prefix of its decoding. Observing Steps. With multi-token prediction [60] a step yields up to k tokens, and k may vary. The alphabet ĪR _R is then the set of such sequences, and a Step is one of them. An inference engineās generate interface can expose Steps, so the Priestess side can observe the internal transitions even though the alphabets of the two sides differ. C.2 Composing Hierarchies From the processor down to the memory, the levels of Definition 4.7 form a chain. Below the memory, the keys may be divided among several backing stores (a swap area and files, for instance). The bottom is then the function that takes each key to the backing store that holds it, and from the memory down, the levels form a tree. A level may also be shared: the chains of several processors meet at a shared cache, a memory or a backing store. A write to a key k updates the value the store keeps for k, at every level whose working set holds k. A working set is usually finite, and a key may be inserted into it or deleted from it at any time, as long as the key is still held at a level below or can be rematerialized. Whether the caches are inclusive or exclusive is a policy on the working sets of adjacent levels. A system may also rematerialize at a level above its bottom, in place of the levels below. When both are possible, a policy chooses between them, for instance when a miss is too expensive. Since Cā³fC f is again a function on keys, hierarchies compose as functions do. Below, ā binds more tightly than ā³ , and tit_i is the lookup cost of the i-th level. Construction C.1 (composing hierarchies). 1. Splitting. Let ai=Ciā³āÆā³Cnā³fa_i=C_i Ā·s C_n f for iā¤niā¤ n, and an+1=fa_n+1=f. Then ai=āØai+1,Ciā©(iā¤n):a_i= a_i+1,C_i (iā¤ n): below each level is a function (the access from the next level down), and the level is its memo. 2. Connection. Let the bottom of a hierarchy call a second system, f=hābāĪŗf=h b Īŗ, where b=C1ā²ā³āÆā³Cmā²ā³gb=C _1 Ā·s C _m g is the access of the second system, Īŗ maps the keys of the first to those of the second, and h computes on the value returned. Then C1ā³āÆā³Cnā³hā(C1ā²ā³āÆā³Cmā²ā³g)āĪŗC_1 Ā·s C_n h (C _1 Ā·s C _m g) Īŗ is one hierarchy, in which Īŗ is a translation level that holds nothing (W=ā W= ), costs nothing and only translates the key, as Definition 4.7 admits, and h post-processes the bottom. A key that misses in every CiC_i costs āiā¤nti+cā”(h)+cā”(b,Īŗā”(k)). _iā¤ nt_i+c(h)+c(b,Īŗ(k)). 3. Recursion. Let f1,ā¦,fmf_1,ā¦,f_m have memos C1,ā¦,CmC_1,ā¦,C_m, with working sets W1,ā¦,WmW_1,ā¦,W_m, and let each of them call the next once, fj=hjāfj+1āĪŗjf_j=h_j f_j+1 _j for j<mj<m. Coherence lets each fj+1f_j+1 be replaced by its memo, and applying item 2 at each call gives āØf1,C1ā©=g1 f_1,C_1 =g_1, where gm=Cmā³fm,gj=Cjā³hjāgj+1āĪŗj(j<m).g_m=C_m f_m, g_j=C_j h_j g_j+1 _j (j<m). With k1=k_1=k and kj+1=Īŗjā(kj)k_j+1= _j(k_j), and cjc_j the cost of hjh_j, c(k)=t1+[k1ādom(W1)](c1+t2+[k2ādom(W2)](c2+āÆ)). array[]@l@c(k)=t_1+[\,k_1 (W_1)\,] (c_1+t_2\\ +[\,k_2 (W_2)\,] (c_2+Ā·s ) ). array In words: a hierarchy is a function seen through its memos, and it can be cut at any level (1). A miss at the bottom of one system is a call into another, so two systems connect into one hierarchy, with a translation level that holds nothing where their keys differ (2). When each function of a chain calls the next, the chain with the memos of its functions is a hierarchy with one level per function, and its cost is paid down to the first memo that hits (3). The cost of a state presentation. The cost of Definition 4.8 is item 3 applied to s s itself, since the recurrence s^ā(xāĪ³)=Ļā”(s^ā(x),Ī³) s(xĪ³)= ( s(x),Ī³) calls s s on the prefix x. Take Īŗ to drop the last symbol, take h=Ļā”(ā ,Ī³)h= (Ā·,Ī³), and use the one memo Cs^C_ s at every call. With only applications of Ļ counted, a miss then applies Ļ from the longest cached prefix of x on. A truncatable entry for z holds every prefix of z, which gives costā”(z,x)cost(z,x). C.3 The Stores of the Two Sides The Oracleās store. An insertion into the state cache adds the states of the symbols computed by prefill and decode; a rewrite of the task starts a new epoch, whose keys are new; and a truncation to a prefix deletes entries, at no cost for a truncatable presentation. When the store is organized as a prefix tree, each key is one node of the tree: naming it takes constant space, and it holds only the states of the symbols its parent lacks. If the store is keyed by Step instead and each transition is a Step, then two adjacent queries need not share a prefix, since the encoding of the longer history may segment its end differently (Ā§4.1). The node of the earlier query is then not an ancestor of the later one. The Priestessās store. For a CPU, one computation is one transition, an instruction of the program Ī of Definition 2.1, and Ī computes y=Ī ā”(x)y= (x) as a sequence of them, just as a Frame is a sequence of Steps. The keys of the CPUās store are the addresses an instruction reads and writes, its levels are the processorās caches and its memory, and its backing store is a disk. It has in general no rematerialization, whereas the Oracleās state cache rematerializes a miss by a prefill. Apart from that, its keys are addresses whereas the Oracleās are histories, and that is the only difference between the two, since both are systems of Definition 4.7. C.4 Coherence of the Encoding Cache For each stack s on which the Oracle is called, the encoding cache keeps an entry (|x|,Eā”(x))(|x|,E(x)), where, at the last call, x is the longest prefix of Ļā”(s)Ļ(s) that is empty or ends with ā® . If E factorizes at ā® and Ļā”(s)=xāzĻ(s)=x\,z at the next call, then Eā”(Ļā”(s))=Eā”(x)āEā(z)E(Ļ(s))=E(x)\,E(z) (Theorem 4.4(1)), and the codec reads and encodes only z: the unfinished Frame at the last call, followed by everything appended since. The condition Ļā”(s)=xāzĻ(s)=x\,z, under which the encoding cache reads and encodes only z, is coherence between memory and the codec, and it holds while the stack only grows. A write other than a push can change x without changing its length, and the codec cannot determine from the stackās length alone, so the writer invalidates the entry: the kernel does so when it rewrites a task stack, and the program does so when it rebuilds an operand. Alternatively the codec compares x with the stack, or keeps a version counter, never reused, that is incremented by every write other than an append. A hash gives only a probabilistic guarantee. Since one key indexes both caches (Proposition 4.10(3)), the start of a new epoch invalidates both at once. The two caches lag differently: at each call the encoding cache reads and encodes Dā”(y)āvD(y)\,v, while the state cache already holds y from generation and processes only Eā”(v)E(v). C.5 The Prefix Chain in the Two Forms Table 12 sets side by side what Ā§4.2 says of the chain in each form: a machine invariant within an append-only epoch in the Agent form, a property of the program text in the Workflow form. Agent form (generation in O-mode) Workflow form (generation in P-mode) Key of the next Oracle access Ļā”(u)Ļ(u), known to the kernel when it dispatches Ļā”(d)Ļ(d), known when the call is issued Prefix chain a machine invariant within an append-only epoch a property of the program; sufficient: no ād pop\ d Encoding cache valid within an epoch; the kernel invalidates it when it rewrites the task valid while the program only pushes onto d; the program invalidates it when it rebuilds d Prefix tree a kernel service that copies a history calls whose operands share a pushed prefix, as in parallelization What breaks the chain the kernel rewrites the task; a Frame that does not re-encode to itself; a budget trap inside a Frame the program rebuilds its operand; a Frame that does not re-encode to itself, when answers are fed back Table 12: The prefix chain and the caches in the two forms. C.6 The Two Schedulers in More Detail The Oracle side estimates the deadlines and priorities of the requests it serves. The Priestess side estimates which entries are resident and hence what each access costs (Definition 4.8), and it uses the estimate for cache affinity. Each side knows the other exactly when the other is transparent to it. Scheduling the Oracleās computations. An Oracle-side scheduler handles sequences of computations, not independent ones. For a language model the computations of such a sequence are closely linked: a task alternates turns (assistant, tool, assistant, user), and each assistant turn is an Oracle computation on the history the earlier turns left. The amount of the cache that the call rt+1r_t+1 can reuse from the call rtr_t depends on the granularity at which the history grows between them: a Step, a Frame or something in between. ā¢ At Frame granularity, with the hypotheses of Proposition 4.10(2), the state cache already holds the whole earlier history when the next query arrives: the query costs only what the kernel pushed since the last Frame, and the key of each query is an ancestor of the next oneās in the prefix tree. ā¢ At Step granularity, each Step re-encodes the history, and beyond the growth of the encoding the state cache recomputes up to the Step backtrack (Proposition 4.9); for the pair (w,v)(w,v) the bound is the one of that proposition, (|Eā”(wāv)|ā|Eā”(w)|)+LEG(|E(wv)|-|E(w)|)+L_E^G, and it is LEG+1L_E^G+1 only when the encoding grows by at most one symbol. For BPE with a proper dictionary, that backtrack is finite (Ā§4.1). A budget trap inside a Frame leaves a history that Proposition 4.10 does not cover (below). This is for one task on one Oracle with a private cache. With several Oracles for one task, a state belongs to one Oracle, its codec and its presentation, so a task that is moved to another Oracle finds no state of its history there unless that Oracle holds one, and may pay a prefill of the whole encoding. With several tasks on one Oracle, the tasks share its stores. Under finite capacity, which the machine does not model, the states of one task may evict those of another, and the reuse of Proposition 4.10(2) is then an upper bound. The tiers of the KV cache turn the trade-off between affinity and load balance into a comparison of hit and miss costs level by level. The usual metrics (utilization, throughput, turnaround, waiting and response time, SLO attainment, fairness and energy) can be defined over the events of the model (excursions, traps and Oracle transitions), weighted by a cost per transition. We do not develop them, beyond the cost of Proposition 4.11. C.7 A Budget Trap inside a Frame A budget trap can occur inside a Frame, and the history there need not end with ā® . Consequence (i) of Theorem 4.4 still confines the encoderās loss to the open Frame. Frame-faithfulness, however, applies only to completed Frames, and the state that the Oracle holds need not be the encoding of the history. For example, if the Oracle generates a symbol t with Dā”(t)=aābD(t)=ab and the encoder writes aābab as [a]ā[b][a][b], a budget trap right after t leaves the history aābab, encoded [a]ā[b][a][b], while the Oracle holds the state of [t][t]. Proposition 4.10 does not cover this case. C.8 Where Non-empty Answers and Frame-Faithfulness Hold Two conditions matter more than their statements suggest: the convention of non-empty answers (Ā§2) and Frame-faithfulness (Ā§4.1). For each, this subsection says where it holds by construction, where a realization must preserve it, which results use it and what fails without it. The contract and the safety boundary use neither. Non-empty answers. For an internally autoregressive Oracle called through the Frame interface, the convention is a consequence of Definition 4.1, not an assumption: every Frame ends with the terminator, and Dā”(Ļ)=ā®D(Ļ)= , so every decoded Frame ends with ā® . Through the Step interface it holds when no symbol of ĪR _R decodes to Ī» (Ā§4.1). With characters as the machine-side symbols, a byte-level vocabulary can break this, since a token that holds only the first bytes of a multi-byte character decodes to no character (the paragraph on the decoder, above). For an Oracle that is not internally autoregressive, and for a model behind an interface, the convention is an obligation of the codec. An interface may return an answer with no visible text: when the output limit is spent on reasoning that the interface does not return, when a filter withholds the content, or when a refusal is reported apart from the content. A codec keeps the convention in one of two ways. It can decode such an answer to a fixed non-empty word, ā® alone for instance, which in O-mode is an empty request at a yield trap and which the kernel handles as an error (Definition 3.8). This makes the real Oracle total in this respect (Ā§2). Or it can treat the answer as a failure of the Oracle operation, which writes nothing and leaves it to the kernel to decide whether to enter the task again (Appendix C.10). The Oracle is then not total, and the realization handles the failure. Four results use the convention. The kernel distinguishes a yield trap from a budget trap by whether the task stack ends with ā® (Definition 3.6). The interpreter of Proposition 3.11 tests a stack top that belongs to the new answer (Appendix B). Within an append-only epoch the queries on a task strictly grow, so a query recurs on a task only after the kernel rewrites the task. And an O-mode iteration never returns to the configuration it left (Ā§2). Without the convention, the first two need a record of where each answer begins, which a kernel or an interpreter can keep beside the stack. The last two fail: an empty answer repeats the query, which samples the Oracle again with no write of the kernel, and an excursion can then run in place until a budget, if there is one, ends it. K5 does not use the convention. Frame-faithfulness. Frame-faithfulness is a property of an Oracle with its codec, on the Frames the Oracle can generate. For a language model it holds when three conditions hold at once: the model generates only tokenizations that the tokenizer produces, the decoder keeps every generated token, and the next query is encoded by the same tokenizer, with nothing rendered around the answer. Each can fail. ā¢ Sampling. A model may generate a tokenization that the tokenizer never produces (Appendix E.1). Restricting the model to canonical encodings, by conditioning or by construction [243], removes this cause. ā¢ Decoding. A decoder that maps some generated symbols to Ī» drops them from the history. The reasoning of a model whose interface returns it apart from the answer, and leaves it out of the next query, is an example (Appendix C.9). Then Eā”(Dā”(y))E(D(y)) is the encoding of a text without them, and for a tokenizer Eā”(Dā”(y))ā yE(D(y))ā y whenever such symbols were generated. ā¢ Rendering. A chat interface renders the history through a template on the providerās side, and the template is then part of the encoder. A Frame is Frame-faithful only if the template renders a past answer as the tokens that were generated. A budget trap inside a Frame (above) is a fourth situation, outside the definition, which concerns completed Frames only. Theorem 4.4(2) says exactly when Frame-faithfulness holds on a history that ends at a Frame boundary, Proposition 4.10 assumes it, and the remark after Proposition 4.6, that a Frame-faithful Oracle shows its number of Steps, uses it. Theorem 4.4(1) with its three consequences, Proposition 4.9, the contract and the safety boundary do not. When it fails, the cost is bounded and local. The next query recomputes |Eā”(Dā”(y))|ā|lcpā”(y,Eā”(Dā”(y)))||E(D(y))|-|lcp(y,E(D(y)))| symbols beyond the push, at most the re-encoding of the last Frame (Ā§4.2). The completed Frames before it still agree (consequence (i) of Theorem 4.4), and the difference does not outlast the next query, which is encoded afresh. Under hypotheses (i), (i) and (iv) of Proposition 4.10, with the private state cache of its item 2, an Oracle that is never Frame-faithful therefore computes each answer once by generation and prefills its re-encoding at most once. Both conditions can be checked on a realization: the first by counting the answers that the codec had to repair, the second by comparing each generated Frame with the encoding of its decoding, which needs an interface that returns the Oracleās symbols (Ā§4.1). C.9 Reasoning: Kept, Dropped or Hidden A model that reasons before it answers generates a Frame y=yrāyaāĻy=y_r\,y_a\,Ļ, in which yry_r is the reasoning. Whether yry_r enters the history is a choice of the codec or of the kernel, not of the machine: an Oracle is the triple (A,E,D)(A,E,D) (Ā§2), and each choice below leaves A unchanged. K1āK4, the crossing invariant and the safety boundary hold for every Oracle, and so for every choice, and K5 holds wherever the machine is good. What changes is which hypotheses of Ā§4 hold, and what the Priestess stores. ā¢ Kept. D writes the reasoning onto the stack, and E reads it back with the rest. This is the codec the body adopts. The Oracle can then be Frame-faithful, and the Priestess holds the reasoning and finds it in each request. ā¢ Dropped by the decoder. D maps every symbol of yry_r to Ī». Working symbol by symbol, it can distinguish such a symbol from the same token in the answer only if ĪR _R marks each token with the part of the Frame it belongs to, as a modelās reasoning channel does. The step relation can always add the mark, since it sees whether the reasoning has ended. So the Oracle is still internally autoregressive, and the encoder is unchanged. Frame-faithfulness fails whenever reasoning was generated (the decoding case of Appendix C.8), at the bounded, local cost given there: the next query recomputes at most |Eā”(Dā”(y))||E(D(y))| symbols beyond the push, the encoding of the visible part of the answer, and the states computed for the reasoning are not reused. The Step interface is not an Oracle with this decoder, since a Step of reasoning decodes to Ī». Since the history is all that one Step passes to the next, such a Step could not condition the next one either, so the reasoning is confined to one transition, at the Frame interface. It never reaches the Priestess: the request at a yield trap is Dā”(ya)āā®D(y_a)\, . ā¢ Dropped by the encoder. D keeps the reasoning, and E leaves it out, as a chat template does when it renders past answers without their reasoning. If E leaves out all reasoning, it can do so piece by piece between two ā® , since a Frameās reasoning contains no ā® , and it then factorizes at ā® when the encoder it wraps does. As long as the kernel writes the same, and writes no reasoning itself, the Oracle receives the queries of the previous case, with the same failure of Frame-faithfulness (the rendering case) and the same cost. The difference lies on the Priestess side, which holds the reasoning, for a log or a checkpoint. A template that keeps the reasoning after the last user message and leaves out the rest does not factorize at ā® . Let the kernel push a user message v, ending with ā® , onto a history w that ends with ā® and contains reasoning after its last user message. Then Eā”(w)E(w) holds reasoning that Eā”(wāv)E(wv) leaves out, so Eā”(w)ā¢Eā”(wāv)E(w) E(wv), although (w,v)(w,v) is a Frame pair. Between two user messages the prefix chain can hold. If the template is otherwise a separator, the next query costs, beyond the push, the encoding of w from the start of that reasoning on, now without it: the chain breaks as at a rewrite, although the machineās history only grows. ā¢ Dropped by the kernel. The kernel removes the reasoning from the task stack, at each trap or at a swap (Ā§6.3). This is a rewrite: it starts a new epoch, and its price depends on where it begins (Appendix E.2). A kernel that removes an answerās reasoning at the trap after the answer can read the reasoning first. Its rewrite begins after the last query, so with the state of that query still cached it pays what the decoder above pays. In the Workflow form the program does the same when it rebuilds its operand. ā¢ Hidden. An interface may return the reasoning as an opaque block, encrypted or signed, that the client must send back unchanged, or keep it on the providerās side and return a reference to it. Either is a codec: D writes the block or the reference, and E restores the reasoning from the block or looks it up. The machine does not model which code can interpret a symbol, so to its results the block is reasoning written in symbols that the Priestessās code does not interpret. Frame-faithfulness holds or fails as for kept reasoning, and the reasoning re-encodes to itself by construction if the block carries the generated symbols, not their text. Three properties change. The encoder is partial: a block that fails its check is rejected, so Proposition 4.5 does not apply, and a kernel that changes part of a block and enters the task again makes the machine fault (Ā§3); it may still remove a block whole. A block is made for its Oracle: the encoder of another Oracle may reject it or leave it out, and a task moved there then loses its reasoning as well as the states of its history. And a block of authenticated encryption depends on all of the reasoning, so the decoder does not work symbol by symbol, the Oracle with this codec does not meet Definition 4.1 as stated, and the Step interface cannot return the reasoning. Theorem 4.4 uses the decoder only on whole Frames, and only to know that a decoded Frame ends with ā® and contains it nowhere else, so its proof still applies at the Frame interface. So does that of Proposition 4.10, with its hypothesis (i), which the partial encoder does not meet, replaced by the acceptance of every query on u. A check at the boundary still sees every block cross (Theorem 4.12), but it can read an encrypted block only with its key. A reference into a store that expires its entries makes the encoder change over time, which the machine, whose Oracle is fixed, does not model. A realization can treat an expired reference as an encoder error (Appendix D.3), and backing off from it is a rewrite. C.10 Protection, Channels and Attacks Program Operating system What protects the operating system from the program What protects the program from the other side Agent form Oracle Priestess: kernel and library T with the locality lemma: a task writes only its own stack, and requests enter only at ātrap _trap (K1, K3) nothing in the machine: the kernel is privileged, may rewrite the task, and is trusted, as in a conventional operating system Workflow form Priestess none mediates the task nothing to protect S and T: answers are data, reach only their operand and gain no execution right at the call (K4); validating them before a promotion is the programās obligation Table 13: Protection by form. Further protections. S restricts only the Oracle side, and the Priestess, the trusted side, may touch any stack. Protections that also restrict the trusted side are further protections, as with SMEP and SMAP on current processors [92]. Under the first, the Priestess does not execute memory the Oracle can write. Under the second, it touches Oracle storage only through explicit operations, so that a kernel bug cannot read or write a taskās history by accident. When the Priestess is restricted in such ways, the branch to lel_e of a P-mode call still shows whether a word that it copies lies in domā”(E)dom(E). This is an architectural channel, unlike the transient ones of Meltdown and Spectre [225, 226]. What a task observes. By K1 and K2, the past of the run, another task or the Priestess stacks can change the possible histories of a task only through two Priestess actions: the Priestessās writes to the task, and its choice of when, and how often, to enter it. The machine opens no content channel into a task other than the kernelās writes, and the kernelās scheduling of the task is a control channel. The statement is about sets of possible outcomes. A statement about probabilities needs, in addition, that the distribution of answers depends only on the query. A realization in which Priestess code reads a clock adds channels outside the model: the latency of a call reveals whether a prefix was resident in a cache shared across tasks or users. Replay. If the Oracle is not deterministic, either side can call it again and again until it produces a vulnerable program, or a thunk of one. A bad answer of probability p>0p>0 to w appears among n independent queries of w with probability 1ā(1āp)n1-(1-p)^n. On the machine, answers are non-empty and an Agentās queries therefore strictly grow, so the Agent does not re-sample within its own epoch, and a query recurs on a task only after the kernel rewrites the task. A service allows the same query again if it gives a task a history equal to an earlier one (by copying a frozen history, restoring a saved one, or loading the same initial content again). Such services are writes of the kernel, on the boundary of Theorem 4.12, and they are sufficient for replay but not necessary, since different histories may extend to the same word. A copy that is followed by different replies gives histories that share a prefix but differ, so one request is continued twice. A realization adds paths that the machine does not model. An Oracle operation that fails or is refused writes nothing, so entering the task again issues the same query once more. On the machine, that is the kernelās decision to return with an empty reply, whereas a retry inside the Oracleās unit is inside the Oracle. A replay policy at those services and paths can limit them, or give a fixed answer per query. A fixed answer per query returns answers within Oā”(w)O(w), as a recording does, so it still produces executions of the machine. Zheng et al. check the operations checkpoint, fork, restore and merge, against an execution record whose log of authorizations is append-only, and reject an edit that would authorize an action twice, break the policy, or discard a result the task still requires [175]. That check sits at the same services and applies to authorization, not the re-sampling of the Oracle. In the Workflow form the program may re-issue a query freely, and replay is a property of its code. CaMeLās interpreter, for instance, prompts the privileged model up to ten times in all, again after each exception, until the modelās code runs [244], and LLMbda observes that this retry loop lets an adaptive driver launder a secret one bit at a time [21]. Syscall and return. A system call is a yield trap whose request lies in LĪL_ (Definition 3.8), and the return is the kernelās reply, appended to the task before the next uret. Membership classifies the request, but whether the kernel recognizes it and can serve it is the kernelās own judgement. The machine would equally resume an unanswered task, and what the task does then is a property of the Oracle. That every system call is answered first is the kernelās protocol. Appendix D More on ArchNights This appendix gives the parts of Ā§6 that the body summarizes: the Oracle instruction and its asynchrony, more on PRTS, the exceptions of an Oracle unit and how PRTS handles them, communication and system calls, more on the distribution, and the rest of ZOOTās design. D.1 The Instruction Set in More Detail Encoding. The Oracle instruction is a 32-bit R-type instruction in the custom-0 opcode space (Table 14). Its funct3 field is fixed at 111, the value with which RoCC reads both source registers and writes the destination register. Its funct7 field holds three subfields above two reserved bits: the operation, which is PROBE, STEP or RUN; the direction in which the stack grows, towards its limit or towards its base; and a profile. PROBE has the single encoding funct7=āfunct7= 0x00. For STEP and RUN, funct7=(āŖ3)āā£(āŖ1)ā£āfunct7=(profile 3) (op 1) , so that, under P0, STEP is 0x02 downwards and 0x03 upwards, and RUN 0x04 and 0x05. An instruction is illegal if it has any other funct3, the reserved operation, non-zero reserved bits, any other funct7 with the operation PROBE, or a profile the unit does not implement. The source registers are read before the destination register is written, so an operation whose destination names a source register still sees the old operands, and a destination x0 discards only the result, not the operation. Bits Field Value or meaning 31:25 funct7 reserved[6:5] =0=0; profile[4:3]: 00 P0, 01 P1, 10 P2, 11 P32; op[2:1]: 00 PROBE, 01 STEP, 10 RUN, 11 reserved; dir[0]: 0 down, 1 up 24:20 rs2 the offset of the top, with the budget (RUN) or the write bound (STEP) 19:15 rs1 the segmentās base and its capacity in pages 14:12 funct3 111: read rs1 and rs2, write rd 11:7 rd the result 6:0 opcode 0001011 (custom-0) Table 14: The fields of the Oracle instruction. Profiles and registers. The profiles fix the widths of the fields packed into the registers (Table 15), and with them the largest segment and the largest budget that an operation can name. P0, P1 and P2 target RV64 and trade the width of the offset against the widths of the budget and of the step count; P32 serves RV32 implementations. Under P0 the registers are rs1 1 =[63:12],_[11:0], =\\,base[63:12],\ cap\_pages[11:0]\,\, rs2 2 =or[63:24],[23:0], =\\,budget\ or\ wlimit[63:24],\ offset[23:0]\,\, rd =[63:60],[59:24],[23:0]. =\\,status[63:60],\ steps[59:24],\ bytes[23:0]\,\. The other profiles keep this frame with the widths of Table 15. P1 and P2 split the capacity: its low twelve bits stay in rs1, and its high bits sit in rs2 between the bound and the offset. P2 reserves four bits of rd above its step count, and P32 four bits of rs2 above its budget. The base is rs1 with its low twelve bits cleared, so a segment is aligned to a 4 KiB page; its capacity is ā_āā 4096cap\_pagesĀ· 4096 bytes, and its limit is +base+capacity. All the fields are unsigned, and reserved bits are written as zero. Profile XLEN offset steps budget pages bound largest P0 64 24 36 40 12 40 B 4095 P1 64 28 32 32 16 32 B 65535 P2 64 32 24 24 20 24 P 1048575 P32 32 22 6 6 12 10 P 1023 Table 15: The widths, in bits, of the fields each profile packs into the registers: the offset of the top (also the width of the published byte count), the step count of the result, the budget of a RUN, the capacity in pages, and the write bound of a STEP, counted in bytes (B) or in pages (P). Largest: the largest segment, in pages. Operands and direction. The offset is measured from the base. A stack that grows up stores its content in [,+)[base,base+offset), and an answer of n bytes is written at +base+offset, after which the offset grows by n. A stack that grows down holds its content in [+,)[base+offset,limit), and the answer is written just below +base+offset, after which the offset shrinks by n. Either way the answer only extends the content and leaves what was there unchanged. The direction is an arbitrary choice: an instruction names it, and O-mode, which runs no instruction, takes its direction from the systemās configuration, as the direction of a process stack is fixed. Before evaluation the unit checks that the offset lies within the capacity, that the whole range can be addressed, and that it may be accessed. A write bound of zero forbids a STEP to write, and the all-ones value sets no bound beyond the room left. The budget of a RUN is soft (Ā§6.2). The result register. The result contains the status, the number of steps and the number of bytes published. The bytes are those of the whole answer and of nothing else. For an Oracle that offers STEP, the steps are the Steps committed; for a language model they are its output tokens, saturated at the largest value the field holds, while the descriptor keeps the full count. The status reports how the operation ended (Table 16): with the yield symbol (a Halt, also when the first step yields), with a Step that did not yield (Continue), with the budget spent, or with an exception of one of the unitās parts (Appendix D.3). An exception keeps what was published before it and publishes no descriptor. Publication is mediated by rd: its byte count delimits what the operation added to the segment, so the kernel that handles an exception knows exactly what the operation left. Code Part Meaning 0 Continue: a Step that did not yield 1 Halt: the answer ended with the yield symbol 4 decoder no room: the answer, or a STEPās write bound, does not fit 5 controller budget spent before a yield 6 encoder short input: the content is too short to form a request 8 encoder illegal argument, refused before evaluation 9 encoder the content cannot be encoded 10 compute timeout, recoverable 11 compute unavailable 12 decoder the answer is incomplete or malformed 2, 3, 7, 13ā15 reserved Table 16: The status field of the result. PROBE. PROBE ignores its source registers, computes nothing and changes no stack. Bits 0 to 3 of its result say which of P0, P1, P2 and P32 the unit implements, and bit 4 (DESC) whether its STEP and RUN answers come with a descriptor. Bits 5 and 6 report what the bound Oracle can do: bit 5 (AR) that it is internally autoregressive, and bit 6 (STEP) that it offers STEP. Bit 5 decides whether the Oracle may run in O-mode. The higher bits are reserved. The report applies to the current binding and is refreshed when the binding changes. An Oracle that offers only RUN may overrun its budget by the Frame it is in, and the Oracleās own output limit bounds that Frame. The descriptor. With DESC set, a STEP or RUN that ends normally writes a descriptor just past the answer, in the direction of growth and inside the window. The descriptor is not counted in the bytes and does not move the top, so it is not part of the next query, and the next answer may overwrite it. Its fixed header has 32 bytes, little-endian and with no alignment required: a format byte (0xFF in this version); a checksum byte, chosen so that the bytes of the whole descriptor XOR to zero; a byte of flags, two of which indicate whether the input and the total counts are valid, the rest left to the Oracle; the length of an extension after the header, in blocks of 16 bytes; a 32-bit request number, increasing for each Oracle and wrapping around; and the Oracleās input, output and total counts as 64-bit numbers, for a language model its tokens. The checksum detects a changed byte but authenticates nothing. Where the asynchrony goes. An asynchronous realization preserves the synchronous semantics, and the asynchrony can be put in one of three places. In the microarchitecture, the Oracle instruction is an instruction of long latency, and an out-of-order core can execute independent instructions while the unit computes. The instructions after it do not commit before it completes, so the architectural state is the synchronous one. What speculation leaves behind is a side channel of the kind discussed in Appendix C. Through an SMT abstraction, the wait is hidden as simultaneous multithreading hides a long miss: the core runs another hardware thread while one thread waits for its answer. In the operating system, the kernel issues the operation for one task and runs other tasks meanwhile, as it does around a disk request. It never runs one task twice at once: a task is in O-mode on at most one processor, and no processor writes it meanwhile. With one dispatch point on one processor this holds trivially, whereas a kernel on several processors makes it a scheduler invariant. D.2 More on PRTS Fork in Linux. In Linux, fork gives the child a copy of the parentās address space, copied on write, and a copy of its descriptor table. The copied descriptors share the parentās open files, their offsets included, so a pipe whose ends both processes inherit has two readers and two writers until each closes the ends it does not use. Fork also copies the working directory, the credentials and the signal dispositions. The child has a new identifier, and its resource accounting starts at zero. D.3 Exceptions of an Oracle Unit and in PRTS The exceptions of an Oracle unit. Each part of an Oracle unit may raise exceptions of its own: ā¢ the encoder: an illegal argument, insufficient memory, an encoding failure. An operand whose top lies beyond its limit is an illegal argument, and a history that a language model cannot take as input (a request without its reply, for instance) fails to encode. ā¢ the compute part: a recoverable error, such as a timeout of a modelās service, and an unrecoverable one, such as the loss of the service. ā¢ the decoder: insufficient capacity, when the answer does not fit the room left, and a decoding failure, when the answer is incomplete or malformed (an answer of zero bytes among them). ā¢ the controller: the budget, when it is spent before a yield. This is the budget trap of Definition 3.6, not a fault. How PRTS responds to each exception. An unrecoverable error usually ends the process, and the checkpointing system saves the process as a checkpoint. A recoverable error is retried, inside the Oracle by its unit and inside the Priestess by the kernel, which enters the task again. The Priestess answers an encoder error by backing off: the kernel pops what made the history impossible to encode, and tries again. A decoder error is met by computing the answer again, a re-sample, which a replay policy (Appendix C.10) can limit. An error in the arguments of a system call (an unknown operator, a malformed argument or a missing right) is answered with an error reply that names what was wrong. For an unknown operator, the reply also gives the nearest name the task may use. The other calls in the same answer still run. Two more exceptions come from the limits of a realization. When an answer does not fit its segment, the kernel enlarges the segment and calls again, as a segment grows like a vector in Ā§5. When a Frame is cut off before it yields and cannot be continued, as when a language modelās answer is cut off at its output limit, the kernel backs off the unfinished answer by the byte count in rd, compresses the history and tries again. In an interactive session the person decides instead of the kernel. D.4 Communication and System Calls in PRTS How do tasks communicate? Through the mechanisms of Unix: files, pipes, the exit status a parent collects by waiting, and the terminal. Files live in the virtual file system. PRTS changes two things. Fork connects a parent and its child by default, with a result channel whose write end the child holds and whose read end the parent holds, so that a childās result reaches its parent without the parent wiring a pipe. And the Oracle holds no end of a pipe: pipes are made by the operator that runs a pipeline, by the shell, and by fork for its result channel. Apart from what the kernel writes itself (the declaration, the replies and the records of a session), content from these mechanisms or from the system libraryās operators enters a history only through an explicit, bounded read by the task that owns it. Output shown to a person, and the output of a program that its caller did not ask to capture, are not recorded in any history. System calls. PRTSās internal system calls are designed much as Linuxās are, as a set of kernel functions in groups (Table 17). They lie one level below the system calls of Definition 3.8, a taskās requests, and are not exported to O-mode by default: what the Oracle sees is the operators of the system library, each of which issues one or more of these calls. Group Calls Processes spawn, exec, fork, wait, exit, sleep, yield, shutdown Files open, close, read, write, truncate, stat, list, mkdir, remove, rename, chdir, getcwd Descriptors name a descriptor, find a descriptor by its name Pipes create a pipe, query its state Terminal read a line, ask a question, print Credentials check an access, require a right Histories create, push, pop, read and set the metadata, run an Oracle on a history Checkpoints save a checkpoint, load a checkpoint, compress a history Table 17: PRTSās internal system calls, by group. D.5 More on the Distribution Why does the Oracle not see the internal system calls? Low-level calls force the Oracle to wire descriptors, pipe ends and the order of waits, and each call costs a round trip through the Oracle and a piece of its context. Fewer calls, each doing more, is also what the Lynchpin hypothesis suggests. PRTSās internal system calls are therefore not exported to O-mode by default (Table 17), and the system libraryās operators are organized by intent (Table 8). One operator performs one action a program wants, and descriptor numbers, pipe ends and the order of waits stay inside the kernel and the system library. One call of run with a command line a | b, an input and a request to capture the output does what a Unix shell does with a dozen system calls: it creates the pipes, starts each stage with its descriptors in place, writes the input, reads the captured output to its end, and collects every stage. One call of file_patch reads the file, checks that it is still the version the task read, applies the patch and writes it back, or refuses and says so if the file changed in between. Merging also costs flexibility: the Oracle cannot hold a pipe end, so it cannot build an arbitrary topology of pipes; signals and non-blocking pipes are not exposed; and the declaration, part of every query, grows with every operator. The obligation of Ā§5 is that each operator performs the same services as the sequence of calls it replaces. Core tools and sodo. The distribution has core tools such as echo and ls; some are builtins of the shell, and some are also O-mode programs. sodo (Super Oracle do) switches temporarily to the privileged O-mode user, which gains the right to run commands on the host through the hostās Bash, and every use of sodo goes through its check. The operator bash carries the semantics of sodo by default: every call of it goes through sodoās check before it reaches the host, so a task of the ordinary user may call it, and no call bypasses the check. Whoever controls sodoās check therefore controls the channel by which a task gains rights on the host. Shell. The shell is an interpreter of the kind that runs a script in its own process. What the person does at the prompt (running a program, changing directory, starting a job) reaches the Oracle as one-line events, and so do the jobs that the session collects. These carry no output and are placed before the next request in the same user record. A program that the person runs writes to the terminal, and its output enters no history. Four kinds of line. A line is one of four kinds, told apart by its first character: ā¢ an empty line prompts again; ā¢ a line that begins with / is a builtin, which the session runs without the Oracle; ā¢ a line that begins with ! runs on the host, through sodo; ā¢ any other line is a request in natural language, for the Oracle part. Of the builtins, /run runs a pipeline in the foreground with the terminal, /bg runs one in the background, and /wait waits for a job. /cd, /pwd and /echo are as in other shells, and /source runs a fileās lines as if they were typed. /clear replaces the history with a fresh one, and /compact swaps the history now. /exit ends the shell, and /shutdown shuts the system down. The sessionās loop, with what it does at each kind of line, is in Figure 9. A history, record by record. Figure 10 shows a history of the shell as it grows. It extends the running example of Figure 1 as ArchNights records it: the person first asks to see the file and then runs a program that changes it, so the first patch is refused and the task reads the file again. Seen from O-mode, the history is one program that keeps receiving its continuation (Figure 11). Each call forces a thunk that the declaration offers. The kernel evaluates it in P-mode and returns a value, and the rest of the history is the continuation to which the value is returned. Let c1c_1, c2c_2 and c3c_3 be the calls at lines 9, 11 and 13; lines 9 to 15 then become āc1āx1. force\ c_1\ to\ x_1. āc2āx2. force\ c_2\ to\ x_2. āc3āx3. force\ c_3\ to\ x_3. ā return\ result, and the Oracle writes each step only after the value before it has arrived. The kernelās code never appears in the history, only its results, so the history stays the Oracleās own program, written as it is run. Had the answer at line 9 been a fork, the parentās history and the childās would both be lines 1 to 9, each followed by its own reply. loop collect the jobs that ended, and note each as an event if the next line comes from the terminal and other tasks are ready: yield line ā ā next line of the innermost script, or else a call of the Human class in P-mode case line of empty: continue "!ā¦ ā¦": if typed at the prompt, run it on the host; note an event "/ā¦ ā¦": run the builtin; note an event otherwise: append the user record "events ā„\| line" to the history enter the Oracle part: the Oracle answers and the kernel serves its calls, until an answer calls no operator; that answer is the lineās result, written to standard output Figure 9: The loop of the shellās session. 1 declaration input, print, run, fork, ā¦ ā¦, file_read, file_patch, ā¦ ā¦ 2 system conventions; the shellās text; the profile 3 user program /bin/ansh; cwd /home/oracle; stdin a terminal 4 user show me notes.txt 5 answer file_read(notes.txt) 6 reply "# notes / - prepare teh meeting agenda", stamp s1 7 answer notes.txt: # notes / - prepare teh meeting agenda āÆĀ·s the person types /run /bin/note buy milk ; the program appends to notes.txt āÆĀ·s 8 user [user ran: /bin/note buy milk ā ā exit 0] fix the typo in notes.txt 9 answer file_patch(notes.txt, teh ā ā the, stamp s1) 10 reply refused: the file changed since stamp s1 11 answer file_read(notes.txt) 12 reply "# notes / - prepare teh ā¦ ā¦ / - buy milk", stamp s2 13 answer file_patch(notes.txt, teh ā ā the, stamp s2) 14 reply done 15 answer Fixed: teh ā ā the. The file had changed, so I read it again first. Figure 10: A schematic, abridged history of the shell, record by record, from a session of ArchNights-SE. A blue square marks a record the kernel writes (declaration, system, user, reply), an amber square an answer of the Oracle. 1ā89āc1 force\ c_110āx1 to\ x_111āc2 force\ c_212āx2 to\ x_213āc3 force\ c_314āx3 to\ x_315ā return\ resultevaluate c1c_1evaluate c2c_2evaluate c3c_3O-mode: the historyP-mode: the kernel(a) lines 9 to 151ā9parentās replychildās reply(b) had line 9 been a fork Figure 11: The history of Figure 10 read from O-mode as one program (amber: the Oracleās answers; blue: the kernelās replies and its work in P-mode). (a) Each call cic_i forces a thunk the declaration offers. The kernel evaluates it in P-mode, and the value is returned and bound with to. The rest of the history is the continuation. (b) Had the answer at line 9 been a fork, the parentās history and the childās would share lines 1 to 9, each followed by its own reply. Shell mechanisms. The shell has mechanisms close to those of Bash and other shells. Pipelines run in the foreground and in the background, by /run, /bg and /wait. The operator run shares these builtinsā parser and pipeline code, so that a command line means the same to the person and to the Oracle, although only the personās /run gives a program the terminal. A system profile and a user profile are read at login. Their builtin lines run silently, and their other text becomes standing instructions in the shellās system record, so that logging in asks the Oracle nothing. /source runs a script as if its lines were typed, and a host command in a script is refused, since the Oracle may have written the file. /clear begins the conversation afresh in the same process. After an Oracle error the session returns to the prompt with the conversation kept, and the person decides whether to ask again. An error that would recur ends the shell, and the init system starts a new one. The Oracleās exit ends only its turn, and only the person ends the session. D.6 ZOOT Users and resource isolation. Mainstream instruction sets have at least two privilege levels. Mainstream operating systems mostly use two, and use M mostly for firmware. We consider the three levels U, S and M. U has many users, while S and M have one each. With O-mode added, a question arises: O-mode may have several users; must each of them be tied logically to a particular user of U? The relation between U and S has had three design philosophies in history. ā¢ Users exist in S as well, and the checks on Sās rights are raised to M, which then checks the users of two levels. ā¢ Kernel-isolating virtualization [102]: each guest still has a single S, and kernel isolation in effect runs several S-level users on one machine. ā¢ Kernel-sharing virtualization [228]: one S is divided into containers by namespaces and capabilities. All three should be possible on a machine with an extended privilege level. PRTS has one O-mode user and one privileged O-mode user. ZOOT adopts the second philosophy for the users of U and S. Tasks and memory. The basic unit of scheduling in ZOOT is still the task, and logically each task of ZOOT shares one task structure. The U-mode kernel needs full access to some of its fields, so the U-mode task structure is stored in the user address space. As in PRTS, O-mode and P-mode share one task identifier. At boot, U-mode init switches further to O-mode init. For memory, ZOOT adopts PRTSās scheme: O-mode reuses the U address space, and has no virtual addresses of its own. This costs O-mode flexibility in the memory it can use, since a large Oracle stack needs a large region reserved in advance in the U-mode kernel. But the U virtual address space is large enough to hold the Oracle stacks, and with lazily committed pages, committed before each entry as in PRTS, a large reservation costs little. The fetch condition of Ā§5 is then the U-mode kernelās: the Oracle stacks lie in its address space, and it must not execute them. File system. O-mode can access the physical file system. For resource isolation, the file system must then support discretionary access control for O-mode, which needs new fields for permissions and ownership. Another way is to virtualize O-modeās file system, which suits the LLM class better. With several users and separate kernels the file systems are separate too: each user has an O-mode file system of its own, and some files can be shared. Boot. As on an ordinary computer, a computer with O-mode boots in layers, and the final target of the boot is an O-mode program. The design intends any further level below U to be transparent to M and S. Bridging to Linux. ZOOT can be bridged to the Linux kernel. The design is meant to need no intrusive change to Linux beyond the drivers that may be needed and the mechanism that delegates the new exceptions. Appendix E Further Discussion This appendix takes up topics that the body leaves open. It examines the encoders, caches and schedulers of current systems on the machine, places the defences built for agents relative to the safety boundary, gives the reversed ordering a machine of its own, separates the two breakings into a general machine and derives the boundary and the trusted computing base there, asks what several levels of privilege amount to, turns to the Oracles other than language models and to what is known of the Lynchpin hypothesis, and ends with applications and extensions. E.1 Encoders Ā§4 requires two properties of an encoder: that it factorize at the yield symbol, which a tokenizer does when it splits its input at a registered special token, and that its backtrack inside an open Frame be bounded. The formal theory of tokenizers bears on the second. The work on the boundary between a prompt and its continuation bears on a history that ends inside a Frame, and the work on action tokenizers bears on which Oracles the results reach. A formal theory. A tokenizer is a pair of stochastic maps, and an encoder of bounded variation [58] (after Berstelās prefix distance [242]) is subsequential by Choffrutās theorem [245] if its inverse images preserve regular languages. The loss of Definition 4.2 is a Step-level form of bounded variation (Appendix C). Byte-pair encoding has a formal semantics and, with a proper dictionary, a finite lookahead, which depends only on the dictionary, and a left-to-right algorithm in constant memory [59]. It also has a deterministic automaton [246] and an incremental algorithm that maintains the tokenization of every prefix of its input [247]. The finite lookahead is what bounds the Step backtrack of BPE (Ā§4.1). An incremental algorithm does inside an open Frame what the encoding cache does across Frames: it extends the encoding as the history grows. The boundary between a prompt and its continuation. Ā§4.2 notes a mismatch at this boundary. Token healing backs up one token there [63] and token alignment backs up several [248]. Tokenization biases sampling [234], and exact conversions to bytes and characters remove the bias [249, 250], or remove it up to the probability of invalid token sequences [251]. The partial-token problem is common in practice [64]. On the machine a prompt that may end inside a token is a history that ends inside a Frame. In O-mode such a history arises at a budget trap inside a Frame, the third place where the prefix chain breaks (Appendix C). When the encoder factorizes at ā® the loss stays in the open Frame (consequence (i) of Theorem 4.4), and a history that ends at a Frame boundary, with the separator, leaves nothing to repair. Models also assign probability to encodings the tokenizer never produces [243]. Such an encoding is a Frame that does not re-encode to itself, the second of the three places where the prefix chain breaks (Ā§4.2). Action tokenizers. Vision-language-action models that predict action tokens are autoregressive Oracles whose alphabet includes actions. RT-2 writes actions as text tokens [95], OpenVLA predicts discretized action tokens [96], and FAST compresses action chunks with a discrete cosine transform followed by byte-pair encoding [252]. The encoder results of Ā§4 therefore apply to an alphabet of actions whenever its tokenizer meets their hypotheses, which is checked per tokenizer, as it is for text. E.2 Caches Ā§4.2 models an Oracle call as one hierarchy, from the history down to the state cache; it states the prefix chain within an append-only epoch and locates each mechanism of the serving systems. This subsection says how the systems work and what the model adds to each: where shared prefixes come from, what is gained by keeping a state between turns, what a rewrite of the history costs, and which kinds of reuse fall outside the model. Shared prefixes. SGLang keeps the KV cache in a radix tree keyed by token sequences and evicts the least recently used entries [17], and vLLM pages the KV cache in blocks and shares blocks within and across requests [16]. ChunkAttention detects at run time that requests begin with the same prompt and shares the chunks of their keys and values in a prefix tree, and Hydragen computes attention over a shared prefix and over the unique suffixes separately, batching the prefix part across sequences [75, 76]. The machine accounts for the shared prefix differently in each form. In the Agent form the kernel makes it: the histories of one program share their first records, and a fork or a restore copies a history (Table 10), so the tree grows at run time, by services the kernel decides to serve. In the Workflow form the program makes it, by pushing one prefix onto the operands of several calls, as SGLangās fork primitive does in its frontend language [17]. The tree is then written in the program text and can be inspected before the calls are made, which is why SGLangās frontend can pass it to the runtime (Ā§4.3). Either way these are the shared prompts and the trees of prompts that these systems serve. Under the hypotheses of Proposition 4.10, moreover, each query of a task within an append-only epoch extends the state after its last Frame (item 1), so the keys of one task lie on one path of the tree, which each Frame lengthens. These systems share state only along a common token prefix, so a history is reused as far as its encoding agrees with a cached one, and Proposition 4.9 prices the rest: from the entry of a history, a lookup of an extension recomputes, beyond the growth of the encoding, exactly the encoderās loss, zero at a Frame boundary when the encoder factorizes at ā® . Tiers and turns. Several systems keep the state of a conversation between its turns. CachedAttention saves the KV caches of all requests in a hierarchy of accelerator memory, host memory and disk, loads them back layer by layer while the model computes, and places them in the tiers by hints from the scheduler of inference jobs [61]. Pensieve keeps the state of each conversation in GPU and CPU memory [77]. Mooncake separates the clusters that prefill from those that decode and pools the KV cache in the clusterās host memory and disks [62], and LMCache keeps KV caches outside the accelerator and shares them across engines and queries [37]. On the machine, a conversation whose turns only append is a task in an append-only epoch. Under the hypotheses of Proposition 4.10, its item 2 says what keeping the state saves: each turn costs only what was appended since the last answer, and every symbol is computed once. The item assumes a cache that never evicts. Tiers approximate it by moving a state down instead of dropping it, so that a turn pays a transfer from a lower level instead of a prefill (Definition 4.7). Two of the designs are taken further under the model. CachedAttentionās scheduler can hint only at the jobs submitted to it, which are all of the next keys the Oracle side has (Ā§4.3); the Priestess side holds the rest. And in the model a prefill and a decode are one operation, an application of Ļ per symbol; under the same hypotheses the prefill computes the symbols that the Priestess wrote, and the decode computes those that the Oracle generates (Figure 1(c)). Mooncake runs the two on different systems, so the state that a prefill computes reaches the decoder by a transfer, a connection of two systems in the sense of Construction C.1. What becomes of a taskās state while its tool call runs is a decision of the schedulers (Appendix E.3). Rewrites of the history. Agent systems manage their context by rewriting it: they truncate the oldest turns, compact part of the history into a summary, or move content out to external storage, as MemGPT does [104]. Each is a rewrite of the task and starts a new epoch (Table 10), whose first query pays costcost from the nearest cached prefix (Ā§4.2), and the model says how large that price is. Under the hypotheses of Proposition 4.10, and as long as a cache keyed by encoded prefixes still holds the old states, the reuse extends at least over the encoding of what precedes the rewriteās first change, up to the last ā® there (consequence (i) of Theorem 4.4), and the later queries of the epoch extend the new history again. The price thus depends on where a rewrite begins and how often it recurs. A rare rewrite that keeps the head of the history costs a long prefill now and then, as PRTSās swap does (Ā§6.3). A window that slides at every turn makes every query the first of an epoch, and only the head kept ahead of the window is reused. LMCache reports from its deployments that context truncation, a widely applied technique, can cut the hit ratio of the prefix cache by half [37]. Quineās exec, which renews the context [29], starts a new epoch in the same way, and so does PRTSās exec (Ā§6.3). The same rewrite looks different in the Workflow form. There a compaction is the programās: it pops its operand d and rebuilds it with a summary, the answer of a P-mode call. Between two calls on d the query grows by the answer and the pushes unless the program pops d in between (Proposition 2.7), so the chain can break only across a ād pop\ d, a point that can be found in the program text before it runs. In the Agent form, by contrast, where and when the kernel rewrites a task is its policy at run time, as the threshold of PRTSās swap is. Reuse beyond prefixes. Some systems reuse what is not a prefix. CacheBlend reuses independently cached chunks and recomputes a selected part of their KV entries to restore the interactions between them [68]. Prompt Cache reuses the attention states of modules that a schema declares, at positions the schema reserves, so a module need not begin the prompt [18]. When a conversation overflows the context window, CachedAttention truncates its saved KV caches and keeps them valid by decoupling the positional encoding [61]. Leylineās directives remove or replace a span inside a cached history, in one of Leylineās modes without recomputing what follows the span [69]. All four fall outside Definition 4.8, in which the state of a prefix is computed through every symbol before it. The last two lower exactly the price of a rewrite above, by keeping the states after the removed or edited span. The states kept are then not those of the new history in the sense of Definition 4.8, a trade the model does not cover. E.3 Scheduling Table 4 in Ā§4.3 sorts the systems into four cells, by which sideās scheduler they are and which side they schedule. This subsection analyses the three cells that involve the Oracleās computations, beginning with the Oracle sideās own, and says for each system how it schedules and what the model says of its decision. In the fourth, the Priestess side schedules only its own work. The Oracle sideās own work. A server batches requests, and paging the KV cache lets more of them share the acceleratorās memory [16]. Across devices, Preble places requests by weighing the reuse of cached prompts against the load of each device, with a hierarchical scheduler [78]. This is the trade-off of Ā§4.3 between cache affinity and load balance, and for a task in an append-only epoch the model quantifies affinity. Under the hypotheses of Proposition 4.10, the device that answered the taskās last Frame holds the state of its whole history, so the next query costs there only what the kernel pushed since (item 2). On another device it costs costcost from the nearest prefix cached there, the whole encoding if there is none (Definition 4.8). The prefill that the next query needs stays the size of one push, while the price of a move grows with the history, so within an epoch, and while the state cache of the last device stays resident, the longer an agent runs, the more its affinity weighs against load. Which program runs. Parrot lets an application annotate the inputs and outputs of its requests as semantic variables, so that the service can analyse the dataflow between requests and schedule them with the application in mind [65]. Agentix (formerly Autellix) intercepts the calls that a program submits, and preempts and prioritizes each by the calls its program has already completed, against head-of-line blocking [66]. ThunderAgent treats an agentic workflow as one program and schedules its calls taking its KV cache and its tool environments into account [67]. A server sees the program because the program exposes it or because the server intercepts its calls. On the machine the keys already link the queries of one task within an append-only epoch, since they lie on one path of the prefix tree (Appendix E.2). They stop doing so at a rewrite, which starts a new epoch in the same task: the next key no longer extends the last, and a common prefix alone does not tell the same task from another. Nor can they tell apart two tasks whose histories coincide, as after a restore. The taskās identifier links its queries in both cases. In ArchNights every Oracle operation carries it, as the program identifiers of Agentix, Continuum and ThunderAgent do [66, 33, 67]. A taskās state during a tool call. Here the cache and the schedulers meet. Inference engines treated each call to a tool as the end of a request and formed a new request when the tool returned. InferCept measured the resulting recomputation of the context at 37ā40% of the modelās total forward time, and it chooses at each interception whether to keep the KV cache, discard and recompute it, or swap it out, so that it wastes the least GPU resource [32]. Continuum pins the cache for a time-to-live that is set by the cost of reloading it and by the queueing delay that an eviction would cause [33]. Ask the Tool argues that an estimate that is fixed before a call starts cannot know the callās duration. It has the running tool report its progress, and in its evaluation comes close to a policy that knows every return time [73]. On the machine a tool call is a yield trap, and while the kernel serves it the Oracle holds s^ā(Eā(q)āy) s(E(q)\,y), from which the next query qāDā(y)āvq\,D(y)\,v costs |Eā”(v)||E(v)| under the hypotheses of Proposition 4.10 (Ā§4.2). The three choices are three costs of the model, each paid on top of that |Eā”(v)||E(v)|: nothing if the state is kept; the costcost of rebuilding it from the nearest cached prefix (the whole encoding if none is left) if it is discarded, as in the engines that InferCept measured; and a transfer from a lower level if it is swapped (Definition 4.7). The decision also needs to know when the task returns, and that lies on the Priestess side: the kernelās service decides when the task is entered again, and nothing in the queries that the Oracle side has received reveals when it returns. Proposition 4.11 prices this. Between keeping and discarding, no deterministic policy that does not know when the task returns stays within less than twice the cost of one that knows, and the time-to-live R/Ī¼R/Ī¼ stays within twice. Continuumās time-to-live is a policy of this kind. Ask the Toolās result approaches the remark of Appendix C that each side knows the other exactly when the other is transparent to it, since the running toolās report makes the Priestess side partly transparent. In the Workflow form the same interval lies between two calls that share a prefix, and the program knows the next keys. KVFlow reads them from the workflowās schedule, which it represents as a graph of agent steps; it evicts by each agentās number of steps to execution, keeping the prefixes of the agents due soon, and prefetches those of the agents due next [34]. The Priestess side schedules the Oracle. In the Agent form these decisions are the operating systemās: which task enters O-mode, when, and for how long. PRTS chooses the task and its slice, the budget, counted in the Oracleās own steps (Ā§6.3). Two results of Ā§4 bear on the slice. Steps need not be visible in Frames (Proposition 4.6), so a slice counted in steps needs an Oracle that exposes them, as the descriptor of PRTSās unit does. And with an Oracle that offers STEP, a slice can end inside a Frame, which leaves a history that Proposition 4.10 does not cover (Appendix C); an Oracle that offers only RUN is preempted between its Frames (Ā§6.2). Where a slice ends can thus cost cache as well as time. In the Workflow form the decisions are the programās. Composable effect handlers separate a scriptās logic from its effectful operations (model calls, input and output, and concurrency among them), so that a handler can run the calls concurrently without changing the script; in a Tree-of-Thoughts case this gives a tenfold speedup [81]. Such a handler sees the programās calls before the Oracle does, which is where Ā§4.3 places the next keys. Its decision is written in the programās language (Ā§7.4). Pie runs programs, which it calls inferlets, inside the serving system and gives them control of generation and of the KV cache [82]. An inferlet is code on the Priestessās side of the interface, deployed on the Oracleās: the sides are logical, not places. With the cache in reach, the Priestess side can know, instead of estimating, which entries are resident, since the Oracle side is then transparent to it. An Oracle-side scheduler can take these decisions only from what the Priestess exposes to it, a program identifier, a graph of calls or a hint while a call runs. E.4 Safety Theorem 4.12 names where content crosses between the two computations. On the way in it crosses at the Priestessās writes to an operand: in the Agent form, the taskās initial content, the declaration included, and the kernelās writes, its replies among them. On the way out it crosses at the trap and the gates. Indirect prompt injection, which plants instructions in data that an application is likely to retrieve [83], crosses twice. In the Agent form it enters a task as part of a reply, which is a write of the kernel. Whatever it leads the task to write, any request included, reaches the kernel first at ātrap _trap. In the Workflow form it enters an operand that the program builds, and reaches control only through the gates. AgentDojo places such injections in the results of tools and counts an attack as successful when the attackerās goal is met [239]. A defence can therefore sit on the way in, inside the Oracle, or on the way out. This subsection places the defences built for agents at these three positions and states what the theorem gives at each of them. Whether a defence works is not part of its placement, and a harness reproduces runs of the machine only if it implements the machine faithfully. On the way in. What the theorem guarantees a defence here is completeness. By its first item the Priestessās writes are all that a task reads beyond its own answers, so a filter or a type at those writes sees every symbol that enters a task from outside it, provided it also applies to the initial content and every record the kernel builds, not only the replies. The defences here are of two kinds. The first decides what reaches a task at all: by the provenance of each part of a toolās result [253, 254], by showing the privileged model only the names of variables that contain a quarantined modelās outputs [255], by types that let only numbers, booleans and enumerations through [256], by a hub through which applications exchange all their messages [257], or by rules and a classifier that intercept content before it enters the context [113]. A defence of this kind keeps its decision for every Oracle, since the Oracle never reads what it withholds. In the dual-LLM pattern the quarantined model is a P-mode call whose answer is data (K4). The second kind marks what reaches a task and leaves the rest to the Oracle. Spotlighting delimits, marks or encodes untrusted text [258], StruQās front-end builds each query from reserved delimiters that the data cannot forge [259], and AgentKernel also tags each source with a level of trust [113]. A mark writes provenance for the Oracle to read, and is a defence only together with one inside the Oracle. Inside the Oracle. The instruction hierarchy trains a model to rank instructions by the record they appear in, with tool results lowest [260], and StruQ trains a model to ignore instructions in the data channel [259]. Provenance-aware transformers give each input token a ring ID for its origin, supplied by the application, and learn an attention bias by origin [261]. Such a defence changes the answer relation. By Proposition 4.13, no rule of the machine can certify it, since which request crosses is a property of the Oracle on its history, and the first two papers state that strong adversarial attacks remain a risk. What the machine gives such a defence is its input. The delimiters, the ring IDs and the record that holds each piece of content are written on the way in, so a defence inside the Oracle is only as sound as the writes it reads. This is where the escalation below strikes. On the way out. Here too the theorem gives completeness, at a position that depends on the form. In the Agent form every request reaches the kernel first at the service entry, so a check there sees every request (K3, Corollary 3.5). The checks of requests in the kernels of Ā§7.1 are all the kernelās service policy at ātrap _trap, and so are a privilege policy over every tool call [176] and a re-run of the model with the userās task masked [262]. The re-run stops the run when a tool call resembles one the masked run made, and the masked run is a further Oracle call on a history the kernel writes. Pirch et al. ask for policy checks outside the model, and the service entry is also where these would sit [263]. The theorem fixes where these checks sit, not what they decide: Progent decides by privilege and declaration, deterministically, and MELON by the similarity of embeddings. AKTS narrows the request instead. An agent that tunes a kernelās scheduler acts only by writing an index into an array of policies verified when they were loaded, and an invalid index names an empty slot [264], so every request selects a policy that was verified before the request was made. In the Workflow form the boundary lies in the program, at the gates. CaMeL has a privileged model write a program from the userās query alone and runs it in an interpreter of its own. A quarantined model with no tools returns values of a given schema, and security policies are checked before each tool call, on its arguments and their dependencies [244]. Plan-then-execute and code-then-execute follow the same outline [265]. On the machine the modelās program is the answer of a P-mode call that the Priestess interprets, so the task runs in the Workflow form with the Agent paradigm (Table 10). By the second item of the theorem untrusted content then reaches control only through the gates, here the interpreterās. The quarantined modelās answers are data, but the program may branch on them. CaMeLās strict mode is a check at the gates: it adds the condition of each branch, or the iterable of each loop, as a dependency of every variable assigned inside it. When the harness escalates privilege. He et al. show how a harness defeats a defence inside the Oracle and one on the way out together [266]. When a harness reconstructs a context for a sub-agent, a persistent goal or a scheduled task, it moves content that entered as a toolās result into a user or system record. On the machine that is a write of the kernel, which the contract does not prevent, since the kernel is trusted. The instruction hierarchy then treats the promoted content as privileged, and so does a permission reviewer that sits at the service entry and infers authorization from the same records; the reviewer is a further Oracle call like MELONās masked run. The escalation is a fault of the kernelās writes, not a crossing around the boundary, and a defence on the way in sees the promoted content only if it covers every record the kernel builds, as the first item of the theorem asks. A systematization from the other side. Zhang et al. reach the same division from the side of the defences [240]. They grade each crossing of an agent by whether its question concerns provenance, which admits a deterministic predicate, or the meaning of content, which does not. Their two structural gaps, at the input to the agent and between reasoning and action, are the way in and the way out. The machine settles neither question, since which request crosses is the Oracleās, as noted above for defences inside the Oracle. Their projection principle, that a deterministic mediator can be obtained by narrowing what a crossing controls, is what typed handoffs do on the way in and what a program fixed in advance does on the way out. Their design rule is that enforcement stays in a mechanism that the model may propose to but not rewrite. It holds on the machine for the Priestessās code, since no rule writes Ī and an excursion writes only its own stack (K1, K4). The machine thus fixes where each defence outside the Oracle must be placed, and what it can see there. In a run of the machine content crosses between the two computations nowhere else, so a defence sees all of it when it is placed at every crossing, the initial content included. It does not see the kernelās choice of when, and how often, to enter a task, which is a control channel (Appendix C). The type bypass of Ā§4.4 lies outside the runs the theorem is about, and so do channels outside the model, a cache shared across tasks among them. What a defence decides, and whether that is right, is its own. What this account does not model. The boundary is a statement about where content crosses, and it is not a security model. Of the classical account it uses two things: complete mediation in its usual sense [84], and the shape of a reference monitor, which confines a party by the crossing it must make and assumes nothing of its interior [236]. It proves no non-interference property [237], and Proposition 4.13 shows that no property that holds for every answer can exclude a given one. What it does not supply is a lattice or a declassification policy, a treatment of channels outside the modelātiming, the kernelās choice of when to enter a task, and a cache shared across tasks among themāor any claim about whether a defenceās decision is right. A defence placed at this boundary is one component of a security argument, not the argument. Where the paper needs more it says so: the privilege levels of Appendix E.7 inherit the boundary at each crossing and nothing beyond it, and a tower of levels would need a theorem of its own, which this paper does not state. E.5 Privilege Reversed Ā§3.5 takes the bottom row of Table 3 as the placements of a taskās program when privilege is reversed. Humanāautomation interaction has been modelled as interacting transition systems, whose transitions the user triggers or the machine takes by itself [267, 268, 269]. These models represent the person by a model of the user and ask whether it predicts the machine. We found none that puts the person on a privileged side through which the programās effects must pass. Where a person is an Oracle in the sense of Definition 2.4, the machine is privileged: a Turing machine with a human oracle [270], the human procedure call of TurKit [271] and a shield that restricts the choices of a human operator [272] all have the ordering of Ā§3. A person by itself does not produce the bottom row; privilege does. This subsection gives the reversal a machine. The Oracle is in the privileged mode and decides which task runs and what it is answered, and Priestess code runs confined to its own stacks and reaches the Oracle only by a trap. Its contract carries over item by item, and the one item that changes says what trusting an Oracle costs. Definition E.1 (reversed transition breaking TĀÆ T). Fix an Oracle stack Īŗ, the kernel stack, and a finite set of tasks. A task t has a set CtC_t of labels of the program, its code, with an entry label etāCte_tā C_t, and a set StS_t of Priestess stacks, its stacks, with an input stack itāSti_tā S_t. The sets StS_t are pairwise disjoint. Fix a symbol āātāāāĪ£Qā©Ī£R t ā _Qā© _R for each task, the dispatch symbol āÆāĪ£R ā _R, three symbols Ļ,Ļ,Ī·āĪ£QĻ,Ļ,Ī·ā _Q, and a slice Ī²āāĪ² with Ī²ā„1Ī²ā„ 1. Add the instruction ās sys\ s, for s a stack. Task code is well formed: an instruction at a label of CtC_t is not halt, names only stacks of StS_t, and every label a rule can give as its successor, ā+1 +1 and lel_e included, lies in CtC_t. An answer r is a dispatch if rāĪ£RāāāātāāāVāāāÆrā _R^*\, t \,V^*\, , where V is Ī£R _R without the task symbols and āÆ ; its decision is (t,v)(t,v), with vāVāvā V^* the word between āātāā t and āÆ . Configurations are āØ,Ļ,Ļā© O,Ļ,Ļ and āØ,t,ā,b,Ļ,Ļā© P,t, ,b,Ļ,Ļ , where Ļ gives each task its resumption point, a label of CtC_t and a stack of StS_t, and b is the remaining slice. Runs start in āØ,Ļ0,Ļ0ā© O, _0, _0 with Ļ0ā(t)=(et,it) _0(t)=(e_t,i_t). The rules: ā¢ O-mode. With w=Ļā”(Īŗ)ādomā”(E)w=Ļ(Īŗ) (E) and rāOā”(w)rā O(w): if r is a dispatch with decision (t,v)(t,v) and Ļā”(t)=(ā,s)Ļ(t)=( ,s), then āØ,Ļ,Ļā©āāØ,t,ā,Ī²,Ļ,Ļ[Īŗā¦wā r][sā¦Ļ(s)ā v]ā© O,Ļ,Ļ ā P,t, ,Ī²,Ļ,Ļ[Īŗ wĀ· r][s Ļ(s)Ā· v] ; otherwise āØ,Ļ,Ļā©āāØ,Ļ,Ļ[Īŗā¦wā r]ā© O,Ļ,Ļ ā O,Ļ,Ļ[Īŗ wĀ· r] . ā¢ P-mode. If the instruction at ā is ās sys\ s, then āØ,t,ā,b,Ļ,Ļā©āāØ,Ļ[tā¦(ā+1,s)],Ļ[Īŗā¦Ļ(Īŗ)ā ātāā Ļ(s)]ā© P,t, ,b,Ļ,Ļ ā O,Ļ[t ( +1,s)],Ļ[Īŗ Ļ(Īŗ)Ā· t Ā·Ļ(s)] , a trap whose request is Ļā”(s)Ļ(s). Otherwise, if the O-2-PDA steps (ā,Ļ)ā(āā²,Ļā²)( ,Ļ)ā( ,Ļ ), the task takes that step and its slice falls by one; at b=1b=1 the step ends in āØ,Ļ[tā¦(āā²,it)],Ļā²[Īŗā¦Ļā²(Īŗ)ā ātāā Ļ]ā© O,Ļ[t ( ,i_t)],Ļ [Īŗ Ļ (Īŗ)Ā· t Ā·Ļ] , a slice trap. If the O-2-PDA has no step and ā=n+1 =n+1, the task has finished its code, and the configuration goes to āØ,Ļ[tā¦(ā,it)],Ļ[Īŗā¦Ļ(Īŗ)ā ātāā Ī·]ā© O,Ļ[t ( ,i_t)],Ļ[Īŗ Ļ(Īŗ)Ā· t Ā·Ī·] , a completion trap; if āā n+1 ā n+1, the task is stuck, and the configuration goes to āØ,Ļ[tā¦(ā,it)],Ļ[Īŗā¦Ļ(Īŗ)ā ātāā Ļ]ā© O,Ļ[t ( ,i_t)],Ļ[Īŗ Ļ(Īŗ)Ā· t Ā·Ļ] , a fault trap. A segment of t is a maximal part of a run in which t runs in P-mode, together with the dispatch that starts it and, if it is finite, the trap that ends it. The O-2-PDA-TĀÆ T is the O-2-PDA with TĀÆ T. In words: the Oracle deliberates on the kernel stack until an answer names a task and a reply; the reply is appended to the stack the task last named, and the task resumes where it stopped. The task runs its own code on its own stacks, and returns control by a system call, by exhausting its slice, by finishing its code or by getting stuck, and each of these appends its name and a request to the kernel stack. Task code is well formed and so contains no halt, which makes n+1n+1 its only normal exit: a request Ī· says that the task ran its code to the end, and ĻĻ that it got stuck, as a pop on an empty stack does. The machine is good if every query reached on Īŗ is accepted. Runs start in the privileged mode, as on the O-2-PDA-TS. Proposition E.2 (the reversed contract). For every Oracle, every program whose task code is well formed and every run of the O-2-PDA-TĀÆ T: ā¢ KĀÆ K1 (a task writes only its stacks). A P-mode transition of t changes no stack outside StS_t, except that a trap appends āātāā t and its request to Īŗ. An O-mode transition changes only Īŗ, by appending its answer, and, at a dispatch to t, one stack of StS_t, by appending the reply. ā¢ KĀÆ K2 (a task reads only its stacks). In P-mode a task t reads only stacks of StS_t: what its own instructions wrote there, and the replies that dispatches to t appended, the initial content included. No task reads Īŗ or another taskās stacks. ā¢ KĀÆ K3 (control passes only at a trap and a dispatch). Every transition from P-mode to O-mode is a trap of the running task, and every transition from O-mode to P-mode is a dispatch, which enters t at the label of Ļā”(t)Ļ(t): its entry label, the label after its last sys, or the label at which another trap stopped it. ā¢ KĀÆ K4 (a request is input to a decision, never a decision). Which task runs next and what reply it receives are the decision of an Oracle answer on Īŗ. A request reaches O-mode only as content appended to Īŗ by the trap that ends its segment. ā¢ KĀÆ K5 (control returns to the kernel). Every segment ends with a trap within Ī² P-mode transitions. Proof. ā¢ KĀÆ K1. A P-mode transition of t takes at most one O-2-PDA step, and a trap adds to it only an append of āātāā t and the request to Īŗ and a new Ļā”(t)Ļ(t): a slice trap takes the step it ends, and the other traps take none. The step is on an instruction of CtC_t, which names only stacks of StS_t by well-formedness, and by the locality lemma it changes at most the stack it names. The O-mode rules update Ļ at Īŗ and, at a dispatch, at the stack of Ļā”(t)Ļ(t), which lies in StS_t since only traps of t and Ļ0 _0 set it. ā¢ KĀÆ K2. An instruction reads the store only at the stack it names: jeq and pop read its top, and the Oracle instruction and sys its content. By well-formedness that stack lies in StS_t, and ĪŗāStĪŗā S_t since Īŗ is an Oracle stack. By KĀÆ K1 and its proof, a stack of StS_t changes only by instructions of t or by the reply of a dispatch to t. ā¢ KĀÆ K3. Immediate from the rules: the only rules from P-mode to O-mode are the traps, and the only rule from O-mode to P-mode is the dispatch, which enters at the label of Ļā”(t)Ļ(t); only Ļ0 _0 and the traps of t set Ļā”(t)Ļ(t). ā¢ KĀÆ K4. The successor of an O-mode configuration is fixed by an answer rāOā”(Ļā”(Īŗ))rā O(Ļ(Īŗ)), and by KĀÆ K1 a task changes Īŗ only at its traps. ā¢ KĀÆ K5. The P-mode rules give every P-mode configuration a successor: a sys traps, an O-2-PDA step is taken, and where there is none the task traps. Each transition that is not a trap lowers the slice by one, and at slice 11 every transition traps.ā The items mirror K1āK5, and the proofs derive them from the rules as before. KĀÆ K5 needs no good machine, since P-mode has a successor everywhere, but it is the return of control to the kernel. Its counterpart for the tasks, that a dispatch eventually occurs, is a property of the Oracle: a person may never decide. What does not carry over. In CBPV the two kinds of force change sides. A dispatch forces the task code at the label of Ļā”(t)Ļ(t), as a trap forces k on the O-2-PDA-TS, and a trap forces the thunk on Īŗ, as uret forces the thunk on a task stack. So the operating system here is the Oracleās computation on Īŗ, which forces the task code and is forced by its traps. K4 makes every answer data to the kernel because the kernelās code Ī lies apart from its stacks and no rule writes it. The Oracle has no code apart from its query: Īŗ is an Oracle stack, on which content may have type UāBU\,B (Definition 3.2), and a trap appends every request to it. So a request becomes part of the program the kernel runs next, and no type keeps it data. KĀÆ K4 is the counterpart of K4 in what it preserves: a request selects among the decisions the dispatch language names, and only through the Oracleās answer, as an answer selects among the successors Ī ās labels allow, and only through Ī ās tests. What it loses is a selector that can be checked. A kernel on the O-2-PDA-TS is a program and can be verified against its specification [55, 56]; on this machine the selector is the answer relation of the Oracle, which no proof inspects. So KĀÆ K4 is verified as K4 is, for every Oracle and every program: no request bypasses the trusted party, and every decision is its own. What no proof can verify is that the trusted party decides well, for an Oracle the contract treats as a relation it never inspects. On the O-2-PDA-TS trust in the kernel can be discharged by verifying its code; here, for an Oracle fixed only by its answer relation, it can be assumed, or measured, and an Oracle whose policy is code can be verified as a kernelās can, at which point the assumption moves to the specification of that policy. Which Oracles are of which kind, and what a specification of a decision policy looks like, is outside this paper. A measurement certifies an average, not a decision: for a stochastic Oracle on a fixed domain, certifying with error at most Īµ that its reliability is at least p1p_1 rather than at most p0p_0 takes, to leading order, ln(1/Īµ)/D(p1ā„p0) (1/ )/D(p_1\,\|\,p_0) turns [126]. The reversed contract confines the program completely, and says nothing about the judgement of the party it trusts. Automated systems and humanācomputer interaction. Definition 3.9 applies with the roles exchanged: the privileged side is the Oracle, and the Oracle mediates a task when the task runs in P-mode and the Oracle serves its traps. In automated systems the taskās program is task code: it runs confined, and the Oracle decides at its traps, so the Oracle is its operating system. Turingās choice machines are an early instance: at an ambiguous configuration such a machine cannot go on until an external operator has chosen [273]. Human-centred automation states the ordering as a design principle, that the pilot remains in command [274], while other work shifts the final authority between the person and the automation as the situation changes [275], which on the machine would move the privileged side during a run, outside both machines. In humanācomputer interaction the taskās program is the Oracleās, on Īŗ: the person dispatches tasks as tools and reads what their traps report, as Workflow code reads the answers of P-mode calls, and nothing mediates the person. Lickliderās symbiosis divides the work this way: people set the goals and perform the evaluations, and machines do the routinizable work [276]. The levels of automation run from one in which the person does everything to one in which the computer does [277], separately for acquiring information, analysing it, selecting a decision and implementing it [278]. On the machine, a level says which decisions the dispatch language leaves to Īŗ and which the task code makes by itself. Trusting the Oracle. What KĀÆ K4 leaves to the Oracle is what the formal models of humanāautomation interaction check, by putting a model of the user in the personās place. Degani and Heymann compose the user model with the machine model and require that the composite reach no error state and no blocking state [267]; Rushby model-checks a mental model against the machine to find automation surprises [279]; and full control requires that the user know exactly which commands are available and anticipate every observation [268]. On the reversed machine these are conditions on the Oracleās decisions, which the contract cannot state, since it holds for every Oracle. Security has the same division. User-driven access control grants a permission only on an authentic user action, which no application can generate [280]; on the machine this is KĀÆ K4, which follows from the rules. The trusted path asks in addition that untrusted software cannot imitate the channel to the person [281]. A request may contain task symbols or āÆ , which do not dispatch but may mislead the Oracle that reads them, so a realization keeps them out of task content. What neither guarantees is the personās judgement: in one study, 17% of participants paid attention to the permissions an application asked for at installation [282]. For a language model as the kernel, a request that steers the decision is a prompt injection that lands on the privileged side. That is the case the ordering of Ā§3 excludes by placing an untrusted Oracle below the Priestess, and the reason this paper orders the sides that way for a language model. An interpreter. As in Proposition 3.11, the reversed kernel can run inside the ordinary machine: Priestess code calls the Oracle in P-mode on a Priestess stack that stands for Īŗ, decodes a dispatch and jumps to the taskās resumption point, and each sys becomes code that appends the request and jumps back. An event loop or an approval gate builds the reversal this way, and its confinement is then an obligation of the interpreterās code and of a check of the task code, as in Singularity [52]. An agent harness that asks a person before it runs a tool request combines the two orderings: the person above the Priestess, and the Priestess above the model. That chain has two Oracles of different classes and different trust, which neither machine formalizes alone (Ā§8). E.6 Black-Box Confinement Each breaking of Ā§3 is stated for one colour of stack. Write X for the colour that S lets hold a program the Oracle runs, and Y for the colour whose mode T makes privileged, and call the result the XY-2-PDA; on the O-2-PDA-TS of this paper X is O and Y is P. The two letters play different roles, and this subsection sets out the difference. Sās designation decides which stored content may be run; on a machine that has it, a system then decides, task by task, whether a taskās program is placed there at all (Definition 3.9). Tās designation decides which side holds the privileged mode, and since a privilege is the set of operations a mode is granted (Ā§3.3), writing the other side in that place is not a renaming but a second set of rules, the one Appendix E.5 gives. What travels between the two is the contract and the reading that S gives content, not the rules and not the colours. The subsection then derives the contract on the general machine the two names leave. The designation of X. Of the two, this one does little work. Sās typing holds for either colour in place of X, and on the O-2-PDA-S the designations differ in no run: erasing the types maps the machine whose subject colour is X to the one whose subject colour is the other, so no observation distinguishes them (Ā§3.2). The reason is that the Oracle instruction is available on both colours and the program may call it on either, which is what lets the Priestess call it at all; naming one colour the subject is therefore a way of reading one machine, not a way of separating two. For the two names to stand for two machines, the breaking would have to take the instruction away on one side rather than constrain how its operand is typed, and S does not go that far. A machine that did so would have no Workflow form, since a Workflow is task code that calls the Oracle in P-mode (Ā§3.5), and no hybrid either, since a hybrid has a Workflow part. That is the expected price of separating the colours into two machines, and S does not pay it. This paper consequently fixes X to O without loss, and the designation names the program side of a task; it does not choose a machine. The parity of the two colours is the paperās claim that S restricts no run, and it is what lets the contract hold for every program, including an adversarial one: a designation derived from the colours asks nothing of a program, so there is no well-formedness condition for a program to fail. The designation of Y. This one does have a machine behind each value, and it is the designation of privilege. T runs the program in the privileged mode, and the Oracle instruction has its P-mode rule on Priestess stacks alone (Ā§3.3); to exchange the two sides here is to exchange what a mode may do, which rewrites the transition rules. The two machines share the contract: K1āK5 depend on no type and hold on the O-2-PDA-T already, and on the reversed machine the same five items hold with the roles exchanged, derived from the rules as before (Proposition E.2). What changes between them is one item stated with the roles exchanged, and the price of trusting an Oracle is what it states. So the two letters are not a choice of two breakings but the two names each breaking fixes, and with only one machine behind each name of Y, Table 3 is a table of placements, not of machines: its columns are the two placements of a taskās program, its rows the two assignments of Y, and only the first row is the machine of this paper. Its four cells are the four ways the two roles can be assigned, who acts and who is trusted, and an operating system is the case in which they fall on different sides (Definition 3.9). Exchanging the two colours maps each cell to the one on the other diagonal, which is what remains of the symmetry the breakings give up spend. The contract needs no Oracle. Once the two letters are separated this way, the contract as a statement about a boundary emerges. Write R for any map that assigns a non-empty set of words to each word of a set domā”(R)dom(R), and let the machine with R be the O-2-PDA of Definition 2.5 with O replaced by R, taking T as Definition 3.3 takes it: an accepted query appends one of the words R allows, and a rejected one continues at lel_e. Call the machine good for R if every query reachable in O-mode lies in domā”(R)dom(R). Proposition E.3 (the contract without an Oracle). For every such R, K1āK4 and the crossing invariant hold on the machine with R and T, and K5 holds with budgets on a machine that is good for R. Proof. The proofs of Theorem 3.4, Corollary 3.5 and Proposition 3.7 use the rules of Definitions 2.1, 2.5, 3.3 and 3.6, the locality lemma, and the convention that answers are non-empty. The Oracle enters them only through domā”(E)dom(E) and Oā”(w)O(w), and R has those two as well. So each proof applies verbatim. ā So the contract is a property of the boundary, and not of the party behind it. This is the property a reference monitor has, and it is what lets the classical account of confinement apply to a party whose interior is not assumed [236]. What the machine adds is why the property asks nothing of that party: the confined side executes no instruction of its own and only appends, so nothing of what it does to answer is used, and Proposition E.3 obtains the property for every R, with no well-formedness condition asked of R. A realization in which the confined side does execute has to supply the same items by mechanisms of its own (Definition E.6). The boundary uses S, and at one place only. The contract needs no Oracle, and the boundary of Theorem 4.12 needs it no more, but the boundary does use S, and in one item only. Its In item says that whatever a call reads beyond the answers its own mode appended, the Priestess wrote there. In O-mode this is K2 with the crossing invariant, which hold on the O-2-PDA-T. In P-mode it is S: a P-mode call reads a Priestess stack d, an uret under S enters only Oracle stacks, and by K1 no excursion writes d. Nowhere else does S enter, and the condition it supplies there can be obtained directly. Definition E.4 (safe program). A program is safe on the O-2-PDA-T if no stack is both the operand of an uret and the operand of a P-mode Oracle call. The machine with a safe program is safe. Stack operands are names written in the program, so safety is decidable from Ī . It is a condition on the program, where goodness is a condition on the codec (Ā§3.3, Proposition 5.1), and it mirrors it: goodness keeps every query of a run answerable, and safety keeps every P-mode operand out of an excursionās reach. Proposition E.5 (the boundary without S). On the O-2-PDA-T with a safe program, K1āK4, the crossing invariant and the safety boundary hold for every Oracle, and so does Proposition 4.13. Proof. K1āK4 and the crossing invariant hold on the O-2-PDA-T: the contract follows from the transition rules, none of which depends on a type, so it holds on the machine without S (Ā§3.4), and the Out item of the boundary does not use S either. For the In item in P-mode, a call on d takes Ļā”(d)Ļ(d) alone; by safety no uret names d, so no excursion entered on d, and by K1 none wrote it. So Ļā”(d)Ļ(d) holds only the answers of earlier P-mode calls on it and what the Priestess wrote there, the initial content included. The O-mode case is K2 with the crossing invariant, and the last claim quantifies over the Oracle alone. ā S implies safety, since under S an uret enters only Oracle stacks, a P-mode call reads only Priestess stacks, and the two colours are disjoint, so every program of the O-2-PDA-TS is safe. Safety is strictly weaker, admitting an uret on a stack that no P-mode call reads whatever its colour, and it is weaker in kind, constraining the programās operands and not the machineās colours. A P-mode call is the only transition at which the boundary can break, and it breaks there exactly when the callās operand holds content that an excursion appended. Safety rules this out by the operands alone. The machine without P-mode calls needs no condition at all: with the Oracle instruction on Priestess stacks removed, the In item in P-mode is vacuous and the boundary holds on the bare O-2-PDA-T for every program. That machine has no Workflow form, and no hybrid. What a realization supplies in place of the rules. The propositions above say what confinement of this shape achieves when the confined side executes no instruction of its own. A realization in which it does execute has to supply the same items by other means, and the list is what a trusted computing base is. Definition E.6 (trusted computing base). A realization of the machine in which the confined side executes instructions of its own has a trusted computing base when it supplies: (i) isolation, so that the confined side writes and reads only its own storage; (i) an entry, so that it reaches the trusted side only at a fixed place; (i) a discipline for what crosses back, so that no content from it becomes an instruction or a code address of the trusted side; and (iv) a bound, so that it returns control. The first supplies K1 and K2 together, and the rest are K3, K4 and K5 in turn. One side of the realization is the base that supplies them. The items are stated in the vocabulary of the contract so that a proof of the contract carries over to a realization: where the machineās rules give each item, the baseās mechanisms give it, and the items then hold there as they hold of the machine, for every interior the confined side may have. This is narrower than the classical notion of a trusted computing base [281, 236], which is a whole systemās protection mechanism defined against an evaluation and a policy; what is defined here is only what the contract requires. Two things are worth separating. The operating system of Definition 3.8 is defined relative to a task: it is the party that schedules the programs on Oracle stacks, and it needs a task whose program is placed against its privilege. The base is defined relative to a party whose interior is not assumed: it is one side of an interface, and it needs no task at all. So a base can confine a party that is nobodyās task, and a task can meet an operating system that is not a base, which is the interpreter of Proposition 3.11. A base is one way to put the items of Definition E.6 behind a confined party, and it is the way that keeps the party on the processor and moves the checks into the trusted sideās code. A realization that instead gives that party hardware of its own, reached through one interface, has the shape the machine already has (Ā§2, Ā§5), since the machine assumes nothing of the Oracleās interior and gives it no code of its own; the items are then properties of a component boundary, not of a check in the trusted sideās code, and they ask no more of the realization than the machine asks of an Oracle. Proposition E.7 (what a base cannot do). For every R and every run of the machine with R, a party confined behind a base reaches the trusted side only at the entry of Definition E.6 and only as data, whatever its interior. Which content reaches it is not fixed. Proof. The first claim is items (i) and (i) of Definition E.6, which are K3 and K4 as they hold on a realization. For the second, apply Proposition 4.13 with R in place of the Oracle: it quantifies over the answers alone, and no property that holds for every answer can exclude one. On the machine the item that carries both is K4, and it is the one item a realization cannot inherit, since an Oracle has no instructions to forge with and a program has. ā E.7 Several Levels of Privilege The previous subsection separates the two letters and derives the contract for a confined party that answers. This one asks what that leaves of a computer that has several levels of privilege. The computers in use. This also answers a readerās first question here: whether the same account fits an ordinary computer, which has several privilege levels and no Oracle. In part it does. Treat the Oracle as a user-mode program and the Priestess as a kernel, and the boundary of Theorem 4.12 is the one between user mode and the kernel. In part it does not, in the way Ā§4.4 warns about: the two restrictions that give O-mode its position, that it runs no instruction of its own and only appends, are not properties of user mode, where a program runs instructions of its own and is confined in its rights, not in its execution. In the terms of the two letters, the levels of such a computer are assignments of Y in which the mode that runs the userās program is denied operations but still executes, which is the weaker form of the breaking. Their order is an order of rights, and Ā§5 has already placed them: P-mode contains the processorās existing privilege levels, and on a realization with an Oracle the Oracle mode is added below user mode (Ā§6). A tower of levels. Put the two together and the levels compose: O below U, and U, S and M one above another inside P-mode. Each crossing is a fixed entry to the level below and a trap back to one fixed entry above it, as the crossing between P-mode and O-mode is by K3, and no content of a lower level reaches the control of a higher one except through that entry. Complete mediation, which Theorem 4.12 gives at one boundary, can be required at each of them in turn: a check at an entry sees every crossing into the level below it. For the levels the processor supplies, this is the processorās own guarantee, stated in its privileged architecture [41]. There the higher level fixes each entry, not the instruction set: a trap goes to an address that a higher level has set in a register the lower level cannot write, one per cause of interrupt in vectored mode and at the level that delegation selects, and a return goes to the address that the higher level leaves in its exception program counter. What the lower level cannot do is choose where it enters a higher one, which is what K3 secures for the Priestess. What the machine adds to the tower is the bottom level, which those levels do not supply: a level whose transitions are computed by a party that runs no instruction of the level at all. How the users of one level interact with those of another is the old question that Ā§7.5 and Appendix D answer in three ways, by kernel-isolating virtualization, by kernel-sharing virtualization and by a monitor above both. What the tower does not inherit. The contract is a theorem about one Oracle, one program and one run, and a tower does not inherit it: a level may apply it to what runs at that level, and the tower as a whole would need a theorem of its own, which this paper does not state. Nor is the tower the only nesting. An approval gate has two Oracles of different classes and different trust, which is a combination of the two assignments of Y, instead of a stack of levels, and Ā§8 leaves it open. E.8 Oracles and the Lynchpin Hypothesis Ā§5 runs in O-mode only the Oracles that are autoregressive inside, and lets P-mode call any Oracle. This subsection says what that leaves open for the Oracles other than language models, and then reviews what is known of the Lynchpin hypothesis and of the remedy that Ā§5 proposes for it. Oracles other than language models. Ā§5 places the classes. An action-conditioned world model and vision-language-action models that predict action tokens may run in O-mode, and the actions of the latter reach P-mode as requests that control a robot; a diffusion model, Jev and usually a person are called in P-mode. A diffusion-native runtime describes its computation as the refinement of a current global state, instead of the extension of an immutable prefix, and lets the model update some parts of that state and the environment and the runtime the others [283]. On the machine such a model is called in P-mode, and the state it refines is Priestess content that the Priestess rewrites between calls, outside the append-only epochs of Ā§4. A survey covers vision-language-action models [284]. What the placement leaves open is whether such an Oracle meets the hypotheses of Ā§4. For an action tokenizer, factorization at the yield symbol is checked per tokenizer, as it is for text (Appendix E.1). A world model such as Genie learns latent actions and an autoregressive dynamics over video tokens [87], so its answers are frames of video, and whether its codec is Frame-faithful is a property of each entity, as it is for a language model. The empirical evidence. The hypothesis concerns correct calls, and the evidence on tool calls bears on it most directly. There, accuracy falls with the size of the tool catalogue, the length of tool responses and the length of the conversation [94], and benchmarks measure calls in long, multi-step and agentic settings [285, 286]. The general evidence on long contexts is consistent with the hypothesis for current models. Accuracy depends on where information sits in a long context [93], and a modelās effective context is shorter than the length it accepts [287]. Performance falls with length when the question and the relevant passage share few words [288], across many models [289], and with length alone when retrieval is perfect [290]. A chain of thought can lower accuracy on some tasks [291]. None of this proves the hypothesis, and its principle is not understood. Theories that may bear on it. Three kinds of theory may bear on it. The first concerns errors over the steps of a composition. Errors may compound over the steps [292] or snowball from an early commitment [293], although teacher-forced training may fail to learn an accurate next-token predictor in the first place, so compounding is not the whole story [294]. The second concerns what a fixed model can compose over a long input. Communication lower bounds for decoder-only transformers [295] and lower bounds on chains of thought [296] limit it, and an empirical study of the serial-depth bottleneck is framed by the first [297]. The third supplies the terms for the dependence itself. Chains of infinite order, processes whose next symbol depends on the whole past, have a theory of continuity rates, loss of memory and Markov approximation [298, 299, 300, 301], in which an Oracleās dependence on a long history can be stated. The stochastic-oracle machines of Ā§7.1 give a structure to the distribution of answers [127]. Which of them, if any, explains the evidence is open. The remedy: call by name. Semantic delegation evaluates a computation by name rather than by value, delaying it until it is needed (Ā§5.4), much as lazy structures in probabilistic programming are evaluated on demand [302]. Whether it helps is a quantitative question. It shortens the history by the definition and by every intermediate step, at the price of a declaration that grows with every operator (Appendix D.5). A model of the Oracleās answers, for which the stochastic-oracle setting is a candidate, would say when the trade pays (Ā§8). E.9 Applications and Extensions Each paragraph places a direction of current work on the machine, says which part of the paper applies to it, and names the open item of Ā§8 it meets. No placement here is a result. Embodied agents. Robot foundation models split a slow model from a fast one: a vision-language model at about ten hertz and an action model at more than a hundred [303, 304], or a high-level policy that plans again every second and sends language commands to a low-level policy controlling at 50 Hz [305]. On the machine the slow model is an AARA_AR Oracle in O-mode, and the fast one an Oracle that P-mode calls, which may be non-autoregressive, as a flow-matching policy is, or Jev. The slow model can then write a program with a hole, switch (a) case ā¦ , which the Priestess forces at the control rate with a supplied by the fast model: semantic delegation (Ā§5.4) at the rate of control. Code as Policies is the nearest published instance. A language model writes Python that branches on the outputs of perception and calls only the control primitives in scope [306], and VoxPoser writes its code once per subtask and evaluates it again at every step of a model-predictive-control loop [307]. We have found no work in which a learned action model fills that hole at the rate of control. PhyAgentOS supports both places for the decision loop, a loop that the runtime manages over a policy model and a loop in which the agent selects tools online, and prohibits the agent from issuing raw hardware commands [308]. On the machine these are the Workflow and the Agent form, and the prohibition holds by K1 and K2, since an excursion writes only its own stack. Two placements need care. When the hand-off between the two systems is a latent and both are trained end to end, as in Helix and GR00T N1 [304, 303], they are one Oracle on the machine, and nothing that passes between them can be observed. And a world model used for planning is called in P-mode: V-JEPA 2-AC is autoregressive, but a search planner calls it many times for each action [309]. What the machine adds is the safety boundary. Every actuator command is a P-mode request, so a check on the Priestess side sees all of them, and an attack that jailbreaks the robotās language model [310] reaches the motors only through that check. That is the position of a guardrail on plans [311], of a control-barrier filter on actions [312] and of the decision module of the Simplex architecture [313]. ROS 2 supplies much of the communication the Priestess needs: its services and actions are requests with responses, and actions can be cancelled [314]. Its topics, however, are publishāsubscribe, so the boundary holds only if access control leaves the Priestess the only publisher to the actuators [315]. The open items are those of Ā§8: Oracles of different classes on one machine, and asynchrony. Reasoning as code. A chain of thought is a history that the Oracle iterates on in O-mode. Program-aided reasoning makes it a program: the model writes code, an interpreter computes the answer, and āsolving is delegated to the interpreterā [316, 317]. On the machine the answer is then one force of a thunk in P-mode, and the history contains the program, not the steps of its evaluation. Chain of Code runs the program line by line and hands each line the interpreter cannot run to the model, which emulates it and updates the program state [318]. On the machine, the Priestess evaluates the program and calls the Oracle in P-mode for its semantic leaves. Tool-integrated reasoning trains the interleaving [319, 320], and frontier models use tools inside their chains of thought [321]; there each program is forced as soon as it is written and its value enters the history, by value rather than by name. At the other end the model emulates its own program in context with no interpreter [322, 323], and a continuous chain of thought feeds hidden states back as inputs, so that nothing of the reasoning stays on the history to be read [324]. The evidence on emulation favours execution. In Chain of Codeās ablation on BIG-Bench Hard, interleaving execution with emulation scored 84, emulation 63, emulation with a state trace 57, and Python alone 48 [318], and in 2024 GPT-4 with a chain of thought predicted the output of Python functions of 3 to 13 lines in 81.9% of cases [325]. What this suggests is a chain of thought that is a program, whose answer is the force of one thunk and which the Priestess evaluates. It meets the Lynchpin hypothesis (Appendix E.8): a history that holds the program and not its evaluation is shorter, and whether it is also more often right is the open question of semantic delegation. Code and language: one Oracle or two. An agent needs both code and natural language [326], and training for one can cost the other. At a fixed budget, the share of code in pre-training trades code generation against natural-language tasks, although a moderate share helps both [327]. A code expert branched from a general model gains on code and loses on knowledge [328], fine-tuning on code causes more forgetting than fine-tuning on mathematics [329], and mixed fine-tuning datasets conflict when they are plentiful [330]. The record is not one-sided: reinforcement learning on software evolution improved general language understanding where supervised fine-tuning degraded it [331]. Two remedies are in use. One separates the models in the system. An architect model describes the solution and an editor model writes the edits [332], and Magentic-One specializes a coder agent by its system prompt, can run it on a different model from the rest, and executes its programs on a deterministic terminal [333]. The other switches inside one model, as a hybrid model switches between thinking and non-thinking modes [334]. That switch is one of reasoning depth, not of code and language, and its vendor later trained the two modes as separate models [335]. On the machine the first remedy is several Oracles of different classes, among which the Priestess chooses at each call, and Ā§8 leaves that machine open. The second is the Oracleās interior, which the machine does not see. The machine adds one placement: whichever Oracle writes a program, the program runs only when the Priestess runs it (K4), as the programs of Magentic-Oneās coder run on its terminal. Learned prefetch. A model can learn when to yield and what to request. Reinforcement learning can make it call tools less often [336]. A fine-tuned model issues its longest-running calls first and goes on decoding while they run [337], and a model trained on its own rollouts learns to predict its next tool call from a partial trajectory, so that the call can be issued before the model reaches it [338]. On the machine this is speculation across the yield. Its precedent in operating systems is a program that, while stalled on I/O, runs ahead speculatively to issue hints for its future reads [339]. The Priestess can serve a predicted request before the task makes it, as speculative actions do with a fast model that guesses the next action and commits only when the real action matches [340]. A reply the Priestess caches changes no task stack, so the contract is untouched until the reply is returned. What the machine leaves to the designer is the handling of effects. A request with effects cannot simply be undone, and current work speculates only requests without effects or with effects that can be rolled back [340, 341, 338], runs speculated calls in copy-on-write sandboxes and commits them in order [342], or divides effects into those that can be buffered, those that can be compensated and those released only at commit [343]. Issuing a request is itself observable. A speculative call that only reads still discloses the userās inferred intent to the service it reaches [344], the agentās counterpart of the side channels of speculative execution [226] and of Appendix C. So an early request must have no effect and also reveal nothing that the taskās own request would not. The learning has a loop of its own: a model that learns from its own traces to request early changes the traces it learns from, as a learned prefetcher changes the distribution of the misses it is trained on [345]. When the large model prepares work for smaller ones, as in a protocol in which a cloud model decomposes a task into subtasks that small local models run [346], its request is served by the Priestess calling the smaller Oracles in P-mode, and the open items are again several Oracles and asynchrony.