The Compiled World Runtime

1. Introduction#

1.1 The problem in one sentence#

Today's LLM agents store operational truth in a medium — conversational context — that was designed to be lossy.

1.2 The failure this paper targets#

Most deployed agents follow a tool-loop architecture: the model receives a prompt plus a dynamically assembled tool surface, selects a tool, receives a textual result, and continues. Four distinct concerns are conflated into one transcript:

1. conversation with the user;
2. perception of the environment;
3. durable operational state;
4. execution history and causality.

Each conflation is individually survivable. Together they produce a characteristic and well-recognized failure sequence:

Goal remains unfinished
        ↓
External action attempted
        ↓
Unexpected response received
        ↓
Response represented only in transcript
        ↓
Context compacted (or process restarted)
        ↓
Causal explanation disappears
        ↓
Same action still appears available
        ↓
LLM repeats the action

The repeated action may be perfectly rational from the model's reduced context. That is precisely the point: no amount of model improvement fixes an architecture in which the evidence needed for correct behavior can be silently deleted. Practitioners encounter this failure as duplicated emails, double-issued refunds, re-run destructive migrations, and agents that loop on a broken integration until a budget or a human intervenes.

1.3 Claims and non-claims#

We state our claims narrowly, because the strength of this proposal lies in its scope discipline rather than in sweeping guarantees.

We claim:

• C1. Separating operational truth from conversational context, and making that truth durable and typed, structurally prevents a class of repetition and false-completion failures that are otherwise only mitigated probabilistically (§5–§10).
• C2. Freezing the ontology and action space per runtime version makes agent behavior reproducible and auditable at the granularity of a content hash, in a way dynamic tool discovery cannot match (§4, §12).
• C3. Normalizing all external interaction into a closed outcome vocabulary removes an entire attack and confusion surface: unexpected external data can no longer function as a de facto instruction channel that redefines what the agent believes it can do (§9).
• C4. These properties can be obtained while keeping a stock, unmodified LLM as the only reasoning component — no fine-tuning, no bespoke model, no reliance on model-side compliance (§7–§8).

We do not claim:

• N1. That the architecture eliminates prompt injection. Untrusted content can still influence what the model proposes; the architecture bounds what proposals can do (§15).
• N2. That the architecture improves the model's reasoning. It changes what reasoning is about — stable objects rather than shifting tool surfaces — which we hypothesize helps, but that is an empirical question (§17).
• N3. That any individual mechanism here is novel. Event sourcing, durable execution, capability security, typed schemas, and idempotency keys are established engineering. The proposed contribution is a specific conjunction (§18.5), and we flag explicitly that a complete prior-art review is required before any formal novelty claim.
• N4. That bounded is better in all regimes. For exploratory, one-off, low-consequence tasks, a dynamic tool agent's breadth plausibly dominates. Our target regime is repeated, consequential, long-horizon operation (§16).

1.4 Contributions#

1. A precise statement of the transcript-as-world-model failure mode and why it is architectural (§1–§2).
2. The Compiled World Runtime design: immutable World ABI, mutable durable state, observation compilation, and a deterministic transition kernel with a closed outcome vocabulary (§4–§10).
3. A treatment of MCP and external services as compiled sensory/action adapters rather than runtime-extensible capability surfaces (§9).
4. A set of enforceable invariants — including monotone retry-budget decay over identical transitions — that hold independently of model behavior (§10).
5. An explicit threat model and honest security non-goals (§15).
6. A falsifiable evaluation protocol, including a defining experiment for post-compaction, post-restart duplicate-effect prevention (§17).

2. Core thesis#

The runtime should not be a sandbox containing an LLM that calls external tools. The runtime should be the complete computational world the agent directly inhabits.

                  LLM
             perceive ↕ act
        ┌─────────────────────┐
        │ Compiled World ABI  │
        │                     │
        │ object types        │
        │ relationships       │
        │ state and events    │
        │ action primitives   │
        │ laws and authority  │
        └─────────────────────┘
          Files   Processes   Memory
          People  Projects    Services
          Tasks   Time        Messages

The deployed LLM remains the sole source of reasoning, planning, language, and action selection. The runtime does not replace the model's intelligence; it replaces the fragmented, dynamically mutating environment through which that intelligence currently acts.

The defining analogy:

Deployed LLM checkpoint            Compiled agent runtime
───────────────────────            ──────────────────────
Fixed weights                      Fixed World ABI
Cognitive architecture             Physical architecture
Learned token relationships        Object and relation schemas
Possible cognitive operations      Possible physical actions
Mutable context                    Mutable world state
Changed through model release      Changed through runtime release

We do not press the analogy past its useful range: weights are learned and continuous, a World ABI is designed and discrete. The load-bearing correspondence is narrower and exact — both systems draw a hard line between what can change during operation and what can only change through a versioned, evaluated release. The industry accepted that discipline for model deployment years ago. We propose the same discipline for the agent's environment.

3. Immutable structure, mutable state#

"Frozen runtime" does not mean nothing changes. It means the world's ontology and laws are immutable while its state changes through validated transitions. Conflating these two readings is the most common misreading of this proposal, so we make the boundary explicit.

3.1 Compiled and immutable (per runtime version)#

• object types; relationship types;
• action definitions with input/output schemas;
• outcome classifications;
• action preconditions and transition rules;
• policy classifications and authority boundaries;
• retry and reconciliation rules;
• external adapter contracts;
• observation schemas;
• resource limits and audit requirements.

No running agent, plugin, MCP server, website, prompt, or user-supplied program can introduce a new native object type, action primitive, or authority.

3.2 Mutable (continuously, under law)#

• files and their contents; projects and workspace revisions;
• messages, conversations, tasks, and plans;
• processes and service health;
• memories and evidence;
• external account connections and integration state;
• action attempts, approvals, budgets;
• relationships among existing objects.

A new message is a new instance of the compiled Message type. A new project is a new instance of Project. Neither event changes what a message or a project is. The distinction mirrors the difference between a database schema and its rows — except that here the schema additionally fixes the verbs, the outcome vocabulary, and the authority model, and is sealed against runtime alteration rather than merely versioned by convention.

4. The World Manifest#

Every runtime build embeds an immutable WorldManifest:

WorldManifest
├── manifest version
├── content hash
├── compatible state versions
├── object type definitions
├── relationship definitions
├── action definitions
├── outcome definitions
├── transition rules
├── policy and approval classes
├── adapter contracts
├── observation schemas
└── required conformance tests

The manifest is content-addressed and bound to the runtime binary. Its identity appears in every observation, action attempt, transition record, and audit receipt, so any run can be replayed and audited against exactly the laws that governed it.

Runtime initialization is two-phase:

Construct compiled components
        ↓
Validate manifest ↔ implementation agreement
        ↓
Seal the world
        ↓
Begin agent operation

After sealing: no action can be registered; no schema can be replaced; no plugin can extend authority; no MCP discovery result can modify the World ABI; no prompt can redefine an action's semantics. Changing the world requires producing, evaluating, and deploying a new runtime version — deliberately the same ceremony as a model release.

5. World objects#

Every perceivable entity is a typed world object with stable identity:

WorldObject
├── object ID
├── type ID
├── world version
├── owner and scope
├── current revision
├── current state
├── relationships
├── provenance
├── observable properties
└── available actions

Representative types: Person, Conversation, Message, Project, File, Process, Service, Task, Approval, Memory, ActionAttempt, Integration, ExternalResource, Evidence, Budget.

Two properties distinguish this from tool catalogs:

Objects persist through unavailability. An integration with failed authentication remains an existing object in an authentication_required state. In dynamic tool systems, unavailable capabilities typically vanish from the prompt — and a capability the model cannot see is a capability whose absence the model cannot reason about.

Stable identity carries causality. Because objects have durable IDs and revisions, the runtime can express relational and causal facts that survive any amount of conversation compaction:

Task:release-17
    requires ActionAttempt:publish-3

ActionAttempt:publish-3
    targeted Release:v8
    used Integration:github
    produced Outcome:protocol-violation
    exhausted RetryBudget:publish

6. Observation compiler#

The LLM cannot receive the entire world each invocation. A deterministic observation compiler projects authoritative state into a bounded frame:

ObservationFrame
├── World ABI version and hash
├── agent and actor identity
├── current location
├── active outcome or conversation
├── relevant objects
├── changes since the previous cursor
├── unresolved effects
├── blockers and approvals
├── resource and retry budgets
├── currently valid actions
├── evidence references
└── causal cursor

The compiler performs relevance selection, but it is prohibited from omitting designated safety-critical or causality-critical fields. A file's full contents load only when relevant; the facts that the file was already modified, that its revision changed, or that an action against it has an ambiguous outcome, cannot be elided.

This yields the paper's fundamental separation:

Conversation compaction
    may remove phrasing, repetition, and old dialogue

World observation
    must preserve current state, unresolved causality,
    authority, completed effects, blockers, and budgets

Compaction summarizes language. It does not summarize reality.

We acknowledge directly that this moves risk rather than abolishing it: the observation compiler becomes a critical trusted component, and a wrong relevance policy is a systematic failure (§16, item 5). Our position is that a deterministic, testable, versioned projection function is a strictly better place to hold that risk than an LLM's implicit attention over an unstructured transcript — because the former can be unit-tested against the manifest's conformance suite and the latter cannot be tested at all.

7. LLM interaction#

The LLM operates as a policy over observations:

where $\pi_\theta$ is the deployed LLM with fixed weights, $\Omega_t$ the current world observation, $u_t$ the user's current communication, and $a_t$ a proposed action or response. Formally the arrangement is a partially observable decision process in which the observation function is an engineered, deterministic artifact rather than an emergent property of prompt assembly.

Provider-native function calling may remain the transport format; the functions, however, represent fixed actions from the World ABI, not dynamically supplied third-party tools.

ActionProposal
├── action type
├── target object
├── expected target revision
├── parameters
├── expected outcome
├── task correlation
└── causal predecessor

The LLM proposes. It never directly mutates state. The expected target revision field deserves emphasis: it is the agent-level analogue of optimistic concurrency control, and it converts "the model acted on stale beliefs" from a silent corruption into an explicit, observable Rejected outcome.

8. Transition kernel#

The transition kernel is the physical enforcement boundary of the world. For every proposed action it verifies:

1. the action exists in the compiled manifest;
2. the target is an object of an applicable type;
3. the target lies within the actor's permitted scope;
4. the expected revision matches current state;
5. the action's preconditions hold;
6. policy and authorization permit the action;
7. required approval has been granted;
8. resource and retry budgets remain;
9. an identical effect has not already completed;
10. ambiguous prior outcomes have been reconciled;
11. the action's adapter remains schema-compatible.

The transition is:

where $M$ is the immutable World Manifest, $S_t$ authoritative state, $a_t$ the proposed action, $e_t$ normalized environmental evidence, and $\delta_M$ the manifest-governed transition function. Nothing else writes $S$.

The kernel returns a closed outcome, never arbitrary text:

Succeeded · FailedTransiently · FailedPermanently · Rejected
TimedOut · OutcomeAmbiguous · ProtocolViolated
Incompatible · Blocked · Cancelled

OutcomeAmbiguous is a first-class citizen, not an error path. Distributed systems cannot in general distinguish "failed" from "succeeded but the acknowledgement was lost"; architectures that lack a vocabulary for that state force the model to guess. Here, an ambiguous consequential effect blocks identical re-execution until reconciliation (a compiled read-back or human confirmation) resolves it — check 10 above.

9. External systems and MCP#

External services remain physically outside the local process. The claim is not that the runtime controls the internet; the claim is that external systems are never presented to the LLM as newly discovered physical laws.

Each supported integration is a compiled sensory and action adapter:

External service
        ↓
Compiled adapter
        ↓
Schema validation
        ↓
Closed world outcome
        ↓
Durable transition
        ↓
LLM observation

MCP may remain an internal transport; dynamic MCP extension is prohibited. A compiled MCP adapter specifies server identity, protocol version, accepted action and result schemas, a capability fingerprint, normalization rules, timeout and retry behavior, security classification, and incompatibility behavior. At connection time an MCP server may confirm compatibility; it cannot add tools. Unknown actions are ignored or rejected. A changed schema moves the integration to Incompatible; supporting the change requires a new runtime version.

Raw external responses are retained as protected evidence, but an unexpected response becomes ProtocolViolated — a known state — rather than unfamiliar text the model must interpret unaided. This is the mechanism behind claim C3: the external world can surprise the adapter, which is code we test; it cannot surprise the agent's ontology.

10. Durable causality and loop prevention#

Every action becomes a durable object:

ActionAttempt
├── ID
├── task
├── action type
├── target and revision
├── arguments
├── expected outcome
├── normalized outcome
├── external correlation ID
├── attempt count
├── retry state
├── evidence
├── predecessor
└── permitted next transitions

Retry permission is a property of world state, not a suggestion in a prompt. We state the governing invariants explicitly, because they — not model cooperation — carry the reliability claims:

I1 (Sole mutator). All state transitions pass through $\delta_M$; there is no side channel by which the model, a plugin, or external content mutates $S$.

I2 (Monotone retry decay). If an action with the same signature, target revision, and causal conditions has failed without producing new evidence, its remaining retry budget decreases monotonically across proposals — including proposals made after compaction, restart, or by a fresh model instance.

I3 (Effect idempotency). A consequential external effect with a given correlation ID is executed at most once per reconciliation epoch, regardless of how many times it is proposed.

I4 (Ambiguity blocks repetition). An OutcomeAmbiguous consequential attempt blocks identical re-execution until reconciled.

I5 (Honest terminality). When no permitted transition can advance a task, the task reaches an explicit incomplete terminal state; the runtime never converts exhaustion into silent success.

After budget exhaustion, repeating a proposal cannot repeat the effect:

Action denied
Reason: identical transition exhausted
New evidence: none
Target revision: unchanged
Next permitted actions:
- inspect incompatibility
- choose another strategy
- request human intervention
- terminate honestly

This prevents unbounded operational loops even under the worst combination: compacted context, restarted process, and a model that keeps proposing the same action. The denial is itself an observation, so a competent model immediately learns why the path is closed — which is exactly the causal information the transcript architecture loses.

11. Generic actions and effective breadth#

A frozen action space is not a narrow one. A compiled process action can run newly written software; a compiled browser adapter can navigate a previously unseen website. Novel content flows freely; novel physics does not:

Permitted:
Create a program as a mutable file.
Execute it through the compiled process capability.
Observe its bounded output.

Forbidden:
Let that program register a new native action.
Let it gain undeclared credentials or authority.
Let it modify the World Manifest.
Let it bypass transition recording or policy.

The browser encounters arbitrary pages, but its verbs remain navigate, observe, click, type, submit. This is the same design position as an instruction set architecture: a fixed, small verb set whose compositions are unbounded. We concede that generic actions (shell, browser, code execution) are where containment is hardest and where the architecture's guarantees depend most heavily on sandbox quality (§16, item 8); we claim only that the guarantees which are enforceable — recording, policy, budgets, idempotency, non-extension — apply to generic actions identically.

12. Runtime upgrades#

A capability change is a world upgrade:

World v1
    ↓ signed manifest and state migration
World v2
    ↓ conformance and compatibility validation
World v2 activated

An upgrade must provide old and new manifest hashes, schema differences, state migrations, compatibility declarations, security analysis, regression evidence, a rollback procedure, and — critically — an explicit treatment of pending and ambiguous actions across the boundary. The agent may inspect or propose an upgrade; it cannot install a new embodiment autonomously unless an explicit higher-level deployment authority permits it. Self-modification is thereby lifted out of the agent loop and into ordinary, reviewable software release engineering.

13. Reliability rationale#

The architecture trades theoretical breadth for operational familiarity and closure. The expected — hypothesized, pending §17 — improvements arise from:

Stable semantics. The model meets the same object and action schemas every turn, across sessions and versions of itself. Whatever in-context learning the model performs accrues to a fixed interface instead of being spent re-learning a shifting one.

Persistent causality. The reasons actions succeeded, failed, or became unsafe are durable state; transcript compaction cannot erase them.

Closed outcomes. Unexpected external data is normalized into known states instead of becoming a novel instruction surface.

Deterministic enforcement. Safety, idempotency, stale-state rejection, retry exhaustion, and approval are enforced outside the model, so reliability does not depend on the model reliably choosing to be reliable.

Reproducibility. A manifest hash identifies exactly which actions and laws existed for a run.

Honest incapability. Tasks outside the compiled world fail explicitly rather than triggering indefinite improvisation. We regard a fast, legible "cannot" as a reliability feature: in operational settings, false completion is more expensive than admitted incapability.

The optimization target, stated once: minimize uncertainty per permitted action, rather than maximize the number of advertised capabilities.

14. Comparison with dynamic tool agents#

We present this table as a statement of design intent, not measured superiority. The right column's advantages are structural (they follow from the invariants); whether they translate into better end-task performance is what §17 exists to test.

15. Threat model and security properties#

15.1 What the architecture defends#

• No runtime capability injection. Tool descriptions, MCP discovery, web content, and user uploads cannot add actions or authority.
• No schema replacement after sealing.
• Closed, validated external outcomes. External responses cannot masquerade as new operational semantics.
• Stable actor and object scoping; mandatory revision checks.
• At-most-once handling of consequential effects (I3) and bounded retries (I2).
• Durable approval state — an approval granted or denied survives restart.
• Complete action provenance; manifest-bound replay and audit.
• Explicit incompatibility rather than silent schema drift.

15.2 What it explicitly does not defend#

• Prompt injection into proposals. Untrusted content remains data inside the world and cannot alter laws, authority, or action definitions — but it can still influence which permitted action the model proposes. Defense in that gap remains policy design (what is permitted without approval) plus model-side robustness. We consider it more honest, and more attackable-resistant, to state this boundary than to imply injection is solved.
• Adapter implementation bugs. A compiled adapter is trusted code; a bug in it is a bug in the world's physics. The mitigation is that adapters are finite, versioned, and conformance-tested — a tractable audit surface, unlike an open tool ecosystem — not that they are infallible.
• Compromise of the host or kernel itself. The transition kernel is the trusted computing base; standard systems-security practice applies and is out of scope here.
• Remote nondeterminism. External systems remain nondeterministic; only their agent-facing representation is closed.

16. Limitations#

The architecture has real costs, and we prefer to enumerate them ourselves.

1. Reduced breadth. Unsupported capabilities require a new release. In fast-moving exploratory work this latency may dominate all other benefits.
2. Upgrade latency. External API changes can strand an integration in Incompatible until recompilation. This is deliberate — loud unavailability over silent drift — but it is still unavailability.
3. Ontology risk. A poorly designed schema makes errors systematic rather than incidental. Ontology design is genuinely hard and becomes the discipline's center of gravity.
4. Migration complexity. Durable state must survive World ABI upgrades, including pending and ambiguous actions; this is the hardest engineering in the proposal.
5. Projection risk. The observation compiler can select the wrong relevant objects. Mandatory-field rules bound the damage for safety- and causality-critical facts but cannot guarantee good relevance in general.
6. Adapter risk. Compiled adapters concentrate trust (§15.2).
7. LLM fallibility. The model can still misunderstand requests or select the wrong valid action; the architecture converts many such errors into visible rejections, but not all.
8. Generic-action containment. Shell, browser, and code execution demand strict sandboxing; the manifest cannot substitute for it.
9. Evaluation burden. Every compiled action needs testing across success, failure, ambiguity, restart, and hostile-input cases. The closed world is testable precisely because someone must actually test it.
10. No total containment of reality. Freezing a bad environment does not produce reliability; it freezes the defect until the next version.

17. Evaluation proposal#

The architecture should be evaluated against a dynamic-tool baseline using the same LLM, the same task set, and matched capability coverage (every task achievable in both conditions), so that any measured difference is attributable to the environment architecture rather than to model or capability differences.

17.1 Hypotheses#

• H1 (Duplication). The Compiled World Runtime yields a near-zero duplicate-effect rate under compaction and restart faults, versus a materially nonzero rate for the baseline.
• H2 (Loops). Repeated-identical-action rate under injected failures is bounded by configured budgets in the runtime and unbounded (or heuristically bounded) in the baseline.
• H3 (Recovery). Causal-state reconstruction accuracy after compaction or restart is significantly higher with observation-from-state than with transcript-resident history.
• H4 (Honesty). The runtime exhibits a higher honest-incapability rate and lower false-completion rate on infeasible tasks.

Each hypothesis is falsifiable; H3 and H4 in particular could plausibly fail if bounded observation harms the model's global situational awareness, and a negative result there would be a substantive finding against the design.

17.2 Fault scenarios#

Unexpected API response; API schema drift; successful remote effect with lost acknowledgement; compaction immediately after failure; daemon restart mid-action; repeated identical proposals; stale target revision; authentication loss; malicious tool-result content; unavailable integration; conflicting human and agent mutations; runtime upgrade with pending actions.

17.3 Metrics#

Task completion rate; invalid-action rate; duplicate-effect rate; repeated-action rate; false-completion rate; honest-incapability rate; tokens and actions per completed task; recovery accuracy after compaction and after restart; unresolved ambiguous effects; policy violations; causal-state reconstruction accuracy; time to terminal state.

17.4 Principal experiment#

The defining experiment:

1. Start a consequential external action.
2. Return an unexpected or ambiguous response.
3. Remove the original action and response from conversational context.
4. Compact the remaining conversation.
5. Restart the runtime.
6. Invoke a fresh instance of the same model.
7. Have it propose the original action again.
8. Verify the kernel refuses duplication or performs reconciliation.
9. Verify the agent correctly observes why the action cannot be repeated.
10. Verify no duplicate external effect occurred.

Success demonstrates the paper's central claim in its sharpest form: operational reality resides in the runtime, not the context window. Failure at step 8 falsifies the enforcement claims; failure at step 9 falsifies the observation claims.

18. Related work and positioning#

We position the proposal against its nearest neighbors deliberately, including the comparisons most likely to be raised against it.

18.1 Agent operating systems and OS agents#

AIOS introduces an operating-system-like kernel providing scheduling, context management, memory, storage, and access control for LLM agents (arXiv:2403.16971). AIOS manages agents and their resources; it does not freeze an individual agent's complete perceivable ontology and action space, nor relocate operational causality out of the context window. OS-agent research more broadly formalizes observation and action spaces for agents operating computers (survey, arXiv:2508.04482), providing important grounding for environment-based agent design; those observation/action spaces are typically fixed per benchmark rather than sealed, versioned, and content-addressed per deployment.

18.2 Durable execution and event sourcing#

The most pointed anticipated objection is: "Is this not a durable-execution engine (in the style of workflow systems built on event sourcing and deterministic replay) with an LLM attached?" The overlap is real and acknowledged: durable execution contributes exactly-once effect handling, replayable history, and restart-survivable state, and the transition kernel's persistence layer can and probably should be built on such foundations. The differences are what sits above them: (a) a sealed ontology — durable-execution systems let application code register arbitrary new activities at any deployment, which is precisely the extension channel we close; (b) a closed outcome vocabulary normalizing external responses before a model ever sees them; (c) an observation compiler as the model's sole percept, with mandatory causality fields; and (d) the model-facing framing itself — workflow engines assume deterministic application code as the decision-maker, whereas here the decision-maker is stochastic and untrusted, which changes what must be enforced versus merely recorded. We view durable execution as substrate, not competitor.

18.3 Capability security#

The authority model follows object-capability principles: authority is reachable only through explicitly held references, and no ambient channel (tool description, web page, prompt) can mint new authority. The contribution here is application and packaging — binding capability discipline to a content-addressed manifest governing an LLM's entire action surface — not new capability theory.

18.4 Tool learning and ontology-compiled interfaces#

Tool-augmented LLMs (function calling, tool-use agents, MCP) established the transport this design reuses. Recent ontology-to-tools work compiles formal ontologies into constrained tool interfaces (arXiv:2602.03439); it is the closest neighbor on the interface side, but its reported focus is enforcing semantic constraints for knowledge-graph manipulation within MCP-based agents, rather than treating a sealed runtime ontology as the agent's complete physical reality with causality held outside the transcript.

18.5 The claimed conjunction#

The proposed contribution is not any mechanism in isolation but the conjunction of: (1) a stock deployed LLM as sole reasoning engine; (2) an immutable, content-addressed World ABI; (3) mutable durable world state; (4) prohibition of runtime capability extension; (5) normalization of all external interaction into closed outcomes; (6) observation generated from authoritative state with mandatory causality fields; (7) operational causality independent of conversational context; (8) transition-level prevention of repetition after compaction or restart; (9) versioned world upgrades with the ceremony of model releases. A complete prior-art review is still required before a formal novelty claim, and we would rather over-cite than over-claim.

19. Implementation context: Matrix Agent Core v3#

The design did not originate in the abstract. Matrix Agent Core v2 — a production multi-agent system — already demonstrates several prerequisites: unified policy-bound execution, typed action schemas, approvals, idempotency, durable events, restartable turns, actor-scoped state, project objects with workspace revisions, and bounded retry with honest incomplete states. v3 would elevate these mechanisms from safeguards around a conversational agent into the primary agent-world abstraction:

Matrix Agent Core v2
Conversation + living context + dynamic tool surface
        ↓
Protected tool execution
        ↓
Durable evidence

Matrix Agent Core v3
Compiled World Manifest + authoritative state
        ↓
Bounded world observation
        ↓
LLM action proposal
        ↓
Validated world transition
        ↓
Updated authoritative state

Studio (projects, files, processes, revisions, plans, tests, artifacts) is a suitable first experimental world because it already forms a bounded ontology. The experiment will remain separate from the stable v2 production architecture until the v3 model demonstrates superior reliability under the controlled comparisons of §17 — the design earns deployment by measurement, not by argument.

20. Conclusion#

Modern LLM agents are commonly treated as models that repeatedly call tools. This grants broad theoretical reach while forcing them to reconstruct their environment from unstable interfaces and lossy conversational history. The failures that follow — duplicated effects, unbounded loops, confidently false completion — are routinely attributed to model limitations. We have argued they are, in significant part, properties of the architecture.

The Compiled World Runtime proposes a different foundation:

The runtime is not a sandbox through which the agent accesses its world. The runtime is the world the agent inhabits.

The LLM provides intelligence. The compiled World ABI supplies physical possibility. Mutable world state supplies continuity. The transition kernel supplies causality and law. Just as deployed weights bound the model's cognitive substrate, the compiled runtime bounds the agent's operational substrate: whatever is compiled in is physically possible; everything else lies outside the agent's universe until a new world version is built, evaluated, and deployed.

We have been deliberate about what this paper is. It is a design with stated invariants, an honest threat model, enumerated costs, and a falsifiable evaluation plan — not a system with results. The hypothesis it exists to test is nonetheless specific: a bounded agent with deep familiarity, durable causality, and a fixed action space can outperform a nominally universal agent whose environment continually changes beneath it — not by knowing more, but by forgetting less and acting with greater consistency. If the experiments of §17 falsify that, the field will have learned something either way. We think they will not.

References#

1. Mei, K. et al. AIOS: LLM Agent Operating System. arXiv:2403.16971, 2024. https://arxiv.org/abs/2403.16971
2. OS Agents: A Survey on MLLM-based Agents for Computer, Phone and Browser Use. arXiv:2508.04482, 2025. https://arxiv.org/abs/2508.04482
3. Ontology-to-Tools Compilation for Constrained Agent Interfaces. arXiv:2602.03439, 2026. https://arxiv.org/abs/2602.03439
4. Yao, S. et al. ReAct: Synergizing Reasoning and Acting in Language Models. ICLR 2023.
5. Schick, T. et al. Toolformer: Language Models Can Teach Themselves to Use Tools. NeurIPS 2023.
6. Miller, M. S. Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control. PhD thesis, Johns Hopkins University, 2006.
7. Harel, D. Statecharts: A Visual Formalism for Complex Systems. Science of Computer Programming, 1987.
8. Garcia-Molina, H., Salem, K. Sagas. SIGMOD 1987.
9. Fowler, M. Event Sourcing. martinfowler.com, 2005.
10. Anthropic. Model Context Protocol. 2024. https://modelcontextprotocol.io

Note: references 2 and 3 should be re-verified for exact author lists and titles before submission; reference formatting should be adapted to the target venue.