\documentclass[11pt]{article}
\usepackage[margin=1in]{geometry}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage{lmodern}
\usepackage{microtype}
\usepackage{amsmath,amssymb,amsthm}
\usepackage{graphicx}
\usepackage{booktabs,tabularx,array,longtable,multirow}
\usepackage{enumitem}
\usepackage{xcolor}
\usepackage{hyperref}
\usepackage{tikz}
\usepackage{float}
\usepackage{caption}
\usepackage{verbatim}
\usetikzlibrary{arrows.meta,positioning,fit,calc,backgrounds,shapes.geometric,shapes.multipart}
\hypersetup{
    colorlinks=true,
    linkcolor=blue,
    citecolor=blue,
    urlcolor=blue,
    pdftitle={Worldline: Causally Versioned Operational Twins for Agentic Developer Harnesses},
    pdfauthor={Chaitanya Mishra}
}
\setlength{\parskip}{0.6em}
\setlength{\parindent}{0pt}
\linespread{1.06}

\newtheorem{definition}{Definition}
\newtheorem{principle}{Principle}

\definecolor{wlblue}{RGB}{36,82,148}
\definecolor{wllight}{RGB}{232,240,252}
\definecolor{wlgray}{RGB}{92,99,112}
\definecolor{wlgreen}{RGB}{69,124,79}
\definecolor{wlorange}{RGB}{184,110,35}
\definecolor{wlred}{RGB}{166,58,58}
\definecolor{wlpurple}{RGB}{97,73,138}

\tikzset{
box/.style={draw=wlblue, rounded corners=3pt, thick, fill=wllight, align=center, minimum height=0.9cm, minimum width=2.4cm},
layer/.style={draw=wlgray, rounded corners=4pt, thick, fill=white, align=center, inner sep=10pt},
arrow/.style={-Latex, thick, draw=wlblue},
mutedarrow/.style={-Latex, thick, draw=wlgray},
actor/.style={draw=wlgreen, rounded corners=3pt, thick, fill=green!8, align=center, minimum height=0.9cm, minimum width=2.2cm},
warn/.style={draw=wlred, rounded corners=3pt, thick, fill=red!8, align=center, minimum height=0.9cm, minimum width=2.3cm},
accent/.style={draw=wlpurple, rounded corners=3pt, thick, fill=purple!8, align=center, minimum height=0.9cm, minimum width=2.4cm},
plainbox/.style={draw=wlgray, rounded corners=3pt, thick, fill=gray!6, align=center, minimum height=0.8cm, minimum width=2.2cm}
}

\title{\textbf{Worldline: Causally Versioned Operational Twins for Agentic Developer Harnesses}}
\author{Chaitanya Mishra\\Independent Researcher}
\date{March 2026}

\begin{document}
\maketitle

\begin{abstract}
Agentic developer systems are currently built around a tool-centric assumption: the environment is treated as a collection of callable interfaces, and intelligence is expected to emerge from prompts plus tool selection. This assumption is useful for peripheral integration, but it is too weak to support deep autonomy, durable memory, reliable replay, precise permissions, or multi-agent coordination across the full surface of software work. Real software tasks span code, terminals, build systems, runtime state, logs, traces, infrastructure, documentation, version history, and human intent. They are not isolated calls. They are constrained transformations of a live world.

This paper introduces \emph{Worldline}, a new primitive for agentic developer harnesses. A Worldline is a causally versioned, executable operational twin of a developer environment. It continuously projects raw environmental signals into a typed world model composed of entities, evidence, memories, branches, capabilities, and receipts. Agents no longer act by calling tools directly. They act by proposing verified transition contracts over world state. The runtime computes intent-scoped context closures, plans transitions, executes them through actuators, verifies postconditions through observers, and records receipts that support audit, replay, and recovery.

The result is a harness architecture in which context extraction, execution, memory, trust, observability, and coordination become parts of a single stateful substrate rather than separate ad hoc layers. The paper presents the conceptual model, semi-formal framework, architecture, security model, replay semantics, and coordination model for Worldline. It also outlines a concrete adoption path in which existing tool protocols become leaf adapters beneath the Worldline runtime, not the primary programming primitive. The central claim is that autonomous software work should be grounded in an executable world model, not a menu of remote procedures.
\end{abstract}

\textbf{Keywords:} agentic systems, developer tools, software engineering, operational twins, replay, autonomy, observability, orchestration, memory, trust

\section{Introduction}

The current wave of coding agents has produced a useful but incomplete abstraction. Agents are frequently given a prompt window, a short-lived message history, and a set of tool endpoints. When the task is local, linear, and short-lived, this arrangement can work. When the task crosses repository boundaries, shell state, runtime telemetry, deployment context, incident history, or team knowledge, the abstraction begins to collapse. The agent is forced to reconstruct the world every few minutes. State is fragmented across logs, terminals, version control, CI, dashboards, documents, and human explanations. Memory drifts. Permissions are coarse. Debugging becomes archaeology.

This is not merely an implementation problem. It is a primitive problem. A developer environment is not fundamentally a set of tools. It is a living operational world whose state evolves over time and whose meaningful units are entities, constraints, causal dependencies, and legal state transitions. Treating that world as a set of tool invocations produces brittleness for the same reason that treating a database as a set of shell commands would produce brittleness. The representation is too weak relative to the structure of the work.

This paper proposes \emph{Worldline}, a state-first harness architecture for agentic software development. In Worldline, the environment is continuously projected into a causally versioned operational twin. Agents receive not an arbitrary pile of recent outputs, but an intent-conditioned closure over that twin. They do not directly invoke external systems as their primary programming model. They propose transitions that are checked against preconditions, permissions, budgets, and postconditions, then executed through a transaction fabric and recorded as receipts. Execution becomes replayable. Memory becomes anchored. Multi-agent work becomes branchable. Audit becomes native.

The paper makes four claims.

First, the primary abstraction for agentic developer systems should be an executable world model rather than a tool registry.

Second, reliable autonomy requires unifying context extraction, execution, policy, and memory inside a single causally versioned substrate.

Third, multi-agent software work is best modeled as branch-based coordination over shared operational state, not as loosely coupled prompt exchanges.

Fourth, existing tool-call protocols remain useful, but only as device-driver layers beneath a stronger harness architecture.

The rest of the paper develops this claim from problem statement to architecture to evaluation.

\section{Problem Statement}

Software work is a special class of operational reasoning. It is not pure planning, because the environment is mutable, partially observed, and adversarially complex. It is not pure execution, because meaningful action depends on latent structure and developer intent. It is not pure memory retrieval, because what matters is often a live dependency across layers of the system. Agentic developer harnesses therefore face five simultaneous demands:

\begin{enumerate}[leftmargin=1.8em]
    \item \textbf{Cross-layer visibility.} The agent must understand code, terminal activity, version history, build rules, dependency graphs, runtime signals, documents, and infrastructure as parts of one environment.
    \item \textbf{Durable semantics.} Facts discovered during work must survive the session in a form that remains attached to the entities they concern.
    \item \textbf{Governed action.} Execution must be shaped by explicit permissions, trust zones, budgets, and secret boundaries.
    \item \textbf{Replay and diagnosis.} Developers must be able to answer what the agent knew, why it acted, what changed, and how to replay or recover the episode.
    \item \textbf{Long-horizon coordination.} Multiple agents and humans must be able to work concurrently on related subproblems without collapsing into unstructured chat.
\end{enumerate}

Existing systems satisfy pieces of this list. None makes the list native. The gap becomes especially visible in long-running tasks such as framework migrations, dependency upgrades across service boundaries, flaky test diagnosis, incident response, secrets rotation, or infrastructure hardening. In those settings the main failure mode is not lack of raw capability. It is loss of coherent world state.

The correct design question is therefore not, ``How do we expose more tools to the agent?'' It is, ``What representation and runtime would let an agent work against the software world itself?''

\section{Why Tool-Centric Paradigms Fail}

Tool-centric harnesses, including those that package capabilities behind standardized server interfaces, solve a narrow but important problem: they provide a disciplined way to reach external systems. That is valuable. It is not enough. Their deepest limitations arise from the fact that they make tool invocation rather than world state the central primitive.

\subsection{The first-class object is wrong}

A tool registry says what may be called. It does not say what the world currently is. The agent must infer environment structure from scattered outputs at runtime. This reverses the correct information hierarchy. In real development work, state precedes operation.

\subsection{Context is assembled too late}

Tool-centric systems are predominantly pull-based. Relevant context is fetched on demand, often in response to prompt-time guesses. That means the agent repeatedly rediscovers the same facts. It also means important context is absent unless explicitly requested. Cross-layer dependencies, such as ``this flaky test is correlated with a deployment boundary and a specific infra change,'' are easy to miss because no stable operational model exists to connect them.

\subsection{Memory is weakly anchored}

Most current memory approaches are session transcripts, vector stores, or manually curated notes. These are not wrong. They are simply ungrounded. They lack typed attachment to the entities and causal episodes they describe. As a result, memory retrieval is often semantically shallow and prone to staleness.

\subsection{Execution lacks transactional meaning}

A tool call is an action attempt. It is not a semantically complete transition. It usually does not encode preconditions, postconditions, invariants, compensation, or blast radius. As a result, developers cannot reliably reason about what the agent \emph{intended} to change relative to the actual world.

\subsection{Permissions are endpoint-centric}

Allowing an agent to invoke a shell, write to a repository, or call a deployment API is too coarse. Real permission questions look like this: may an agent modify only files reachable from a declared service boundary, under a latency budget, without crossing into production write scope, while keeping secrets opaque and requiring human review for schema changes? Endpoint-centric policy has no native vocabulary for this.

\subsection{Observability is after-the-fact}

System logs can show that the agent called a tool. They do not naturally expose the chain from intent to context to action to verification to recovery. Developers are left with disconnected artifacts rather than a coherent causal record.

\subsection{Multi-agent coordination is externalized}

When multiple agents collaborate in a tool-centric setting, coordination is usually layered on top via prompts, shared notes, or thin task queues. There is no native merge model over shared operational state. The result is brittle decomposition and opaque handoff.

These are structural limitations. They do not disappear with larger models or more tools. A stronger primitive is required.

\section{Design Principles}

Worldline is guided by eight design principles.

\begin{principle}[State first]
The harness must maintain a live operational model of the environment rather than reconstructing the world from tools at decision time.
\end{principle}

\begin{principle}[Evidence first]
Every fact in the model must carry provenance, freshness, and confidence.
\end{principle}

\begin{principle}[Intent first]
Developer goals must be represented as typed objects with success predicates, invariants, budgets, and trust requirements.
\end{principle}

\begin{principle}[Transitions, not calls]
The primary action unit must be a state transition contract with preconditions, postconditions, observers, and compensation paths.
\end{principle}

\begin{principle}[Branch by default]
Speculative agent work must occur on isolated branches of world state that can be diffed, replayed, merged, or discarded.
\end{principle}

\begin{principle}[Capabilities over endpoints]
Authorization must attach to scopes, transition classes, budgets, and trust zones rather than only to raw interfaces.
\end{principle}

\begin{principle}[Anchored memory]
Memory must be attached to entities and episodes with validity conditions so that it can decay or invalidate as the world changes.
\end{principle}

\begin{principle}[Local-first adoption]
The architecture must provide value in a single-repo local mode, then expand to CI, runtime, and organization-scale knowledge without demanding a full-platform migration on day one.
\end{principle}

\section{Conceptual Model}

\begin{definition}[Worldline]
A \emph{Worldline} is a causally versioned, executable operational twin of a developer environment. It is composed of typed entities, evidence-backed facts, anchored memories, branch histories, capability state, and transition receipts, all evolving over time.
\end{definition}

The central insight is simple: the agent should reason over an explicit model of the software world and express desired changes as legal transitions on that model. Tools still exist, but they become leaf actuators. They are no longer the primary ontology.

\subsection{Core primitives}

Worldline is built from ten primitives.

\begin{table}[H]
\centering
\caption{Core Worldline primitives}
\label{tab:primitives}
\begin{tabularx}{\textwidth}{>{\raggedright\arraybackslash}p{2.4cm} X}
\toprule
\textbf{Primitive} & \textbf{Meaning} \\
\midrule
Entity & A typed object in the developer world, such as a repository, file, symbol, test, process, service, endpoint, deployment, document, incident, branch, secret scope, developer, or agent. \\
Evidence & A provenance-bearing observation from sensors, logs, commands, traces, documents, or human declarations. \\
Facet & A derived view over entities, such as dependency graphs, ownership maps, blast-radius maps, or failure clusters. \\
Intent & A typed developer goal with scope, success predicates, invariants, budgets, and trust envelope. \\
Closure & The minimal useful slice of the Worldline needed for a particular intent or sub-intent. \\
Transition Contract & A legal, verifiable state change with preconditions, action semantics, observers, postconditions, and compensation. \\
Branch & A speculative timeline rooted in a base state of the Worldline. \\
Receipt & An immutable record of attempted or completed transition execution, including evidence, deltas, policy checks, and outcome. \\
Anchored Memory & Durable memory bound to entities or episodes with freshness and validity rules. \\
Capability Envelope & The permissions, trust zone constraints, budgets, and review requirements under which transitions may execute. \\
\bottomrule
\end{tabularx}
\end{table}

\subsection{From tool menus to operational closure}

A prompt and a tool list provide possibilities. A Worldline provides \emph{closure}. Given an intent, the runtime extracts the subgraph of code, runtime state, history, tests, docs, policies, and prior episodes that makes the task actionable. The closure is not a bag of search results. It is a bounded operational slice with typed relations.

For example, the intent ``repair the failing checkout integration test without changing public API semantics'' expands naturally into a closure containing the test, touched modules, recent relevant commits, build targets, associated services, impacted endpoints, runtime errors, prior similar failures, owning team, and applicable policies. The agent begins from structure, not from guesswork.

\subsection{Operational twins versus passive digital twins}

The term ``operational twin'' is important. A passive representation of the environment is insufficient. Worldline is executable. It knows which transitions are legal, who may request them, what budgets apply, what observers verify them, and how to compensate when they fail. In other words, it combines model, control plane, and audit plane.

\section{Semi-Formal Framework}

This section provides a compact framework for reasoning about Worldline. The goal is not full formal verification. The goal is to make the architecture precise enough to implement and evaluate.

\subsection{State}

Let the Worldline state at time $t$ be

\[
\mathcal{W}_t = \langle G_t, E_t, M_t, B_t, \Gamma_t, R_t \rangle
\]

where:

\begin{itemize}[leftmargin=1.8em]
    \item $G_t$ is a typed multigraph of entities and relations.
    \item $E_t$ is the evidence ledger.
    \item $M_t$ is the set of anchored memories.
    \item $B_t$ is the set of branches and branch metadata.
    \item $\Gamma_t$ is policy, capability, and trust state.
    \item $R_t$ is the receipt ledger.
\end{itemize}

A fact in the graph is not a naked assertion. It is an evidence-backed claim

\[
f = \langle s, p, o, \pi, c, \varphi, \sigma \rangle
\]

where $s$ is subject, $p$ predicate, $o$ object, $\pi$ provenance, $c$ confidence, $\varphi$ freshness, and $\sigma \in \{\text{observed}, \text{inferred}, \text{stale}, \text{contradicted}\}$ is epistemic status.

\subsection{Projection}

Sensors produce raw observations $\omega_t \in \Omega$, where $\Omega$ includes file-system events, version control deltas, shell transcripts, process metadata, CI signals, logs, traces, documents, policy changes, and human declarations.

The projection kernel updates the Worldline via

\[
\mathcal{W}_{t+1} = \Phi(\mathcal{W}_t, \omega_t)
\]

where $\Phi$ performs normalization, identity resolution, entity updates, evidence attachment, and memory invalidation or reinforcement.

\subsection{Intent}

An intent is modeled as

\[
I = \langle \Sigma_I, g_I, h_I, \beta_I, \tau_I, \alpha_I \rangle
\]

where:

\begin{itemize}[leftmargin=1.8em]
    \item $\Sigma_I$ is the declared scope,
    \item $g_I$ is the goal predicate,
    \item $h_I$ is the set of invariants,
    \item $\beta_I$ is the budget vector, including time, cost, blast radius, and review requirements,
    \item $\tau_I$ is the trust envelope,
    \item $\alpha_I$ is the acceptance policy.
\end{itemize}

\subsection{Closure}

Given intent $I$, the closure engine computes a task-specific context slice

\[
\mathcal{C}(I, \mathcal{W}_t) \subseteq G_t \cup E_t \cup M_t
\]

using a relevance function

\[
r(v, I) = \lambda_s s(v, I) + \lambda_c c(v, I) + \lambda_t t(v, I) + \lambda_m m(v, I) + \lambda_h h(v, I)
\]

where the terms correspond to structural proximity, causal dependency, temporal relevance, semantic similarity, and human or organizational priors. Expansion continues until either marginal utility drops below threshold or the closure budget is exhausted. The key property is that closure is \emph{intent-conditioned} and \emph{bounded}.

\subsection{Transition contracts}

A transition contract is

\[
\theta = \langle q, \phi_{pre}, a, \phi_{post}, \kappa, \lambda, \mathcal{O} \rangle
\]

where:

\begin{itemize}[leftmargin=1.8em]
    \item $q$ selects the target entities,
    \item $\phi_{pre}$ are preconditions over the current Worldline state,
    \item $a$ is the action semantics or compiled actuation plan,
    \item $\phi_{post}$ are postconditions,
    \item $\kappa$ is the compensation strategy,
    \item $\lambda$ is the capability envelope,
    \item $\mathcal{O}$ is the set of observers that verify effects.
\end{itemize}

A plan for intent $I$ is a sequence or partial order of contracts
\[
\Pi_I = \langle \theta_1, \theta_2, \ldots, \theta_n \rangle
\]
executed on a branch of the Worldline.

\subsection{Receipts and replay}

Execution of $\theta_i$ yields a receipt

\[
\rho_i = \langle I, \theta_i, \Delta_i, \upsilon_i, \pi_i, \chi_i, t_i \rangle
\]

where $\Delta_i$ is the state delta, $\upsilon_i$ is observer output, $\pi_i$ is policy evidence, $\chi_i$ is terminal status, and $t_i$ is timestamp. Replay re-executes $\Pi_I$ from a checkpointed state with original closure, capability envelope, and observation schedule, allowing bounded-deterministic diagnosis.

\section{System Architecture}

Figure~\ref{fig:architecture} presents the overall architecture. The design is layered to separate observation, state, reasoning, control, and human interface, but those layers share a common substrate.

\begin{figure}[H]
\centering
\resizebox{\textwidth}{!}{%
\begin{tikzpicture}[node distance=8mm and 10mm]
\node[actor] (dev) {Developers};
\node[actor, right=of dev] (agents) {Agents};
\node[layer, below=of $(dev)!0.5!(agents)$, minimum width=12cm] (experience) {
    \begin{tabular}{c}
    \textbf{Experience Plane} \\
    IDE overlay, CLI, review cockpit, replay explorer
    \end{tabular}
};
\node[layer, below=of experience, minimum width=12cm] (reason) {
    \begin{tabular}{c}
    \textbf{Reasoning and Control Plane} \\
    intent compiler, closure engine, planner, scheduler, policy engine
    \end{tabular}
};
\node[layer, below left=12mm and -2mm of reason, minimum width=5.6cm] (world) {
    \begin{tabular}{c}
    \textbf{Worldline Store} \\
    entity graph, evidence log, memories, branches, receipts
    \end{tabular}
};
\node[layer, below right=12mm and -2mm of reason, minimum width=5.6cm] (fabric) {
    \begin{tabular}{c}
    \textbf{Transaction Fabric} \\
    transition compiler, actuators, observers, compensators
    \end{tabular}
};
\node[layer, below=16mm of $(world)!0.5!(fabric)$, minimum width=12cm] (projection) {
    \begin{tabular}{c}
    \textbf{Projection Plane} \\
    sensors, normalization, identity resolution, graph updates
    \end{tabular}
};
\node[layer, below=of projection, minimum width=12cm] (env) {
    \begin{tabular}{c}
    \textbf{Developer Environment} \\
    code, terminal, runtime, CI, docs, VCS, infrastructure, telemetry
    \end{tabular}
};
\draw[arrow] (dev) -- (experience);
\draw[arrow] (agents) -- (experience);
\draw[arrow] (experience) -- (reason);
\draw[arrow] (reason) -- (world);
\draw[arrow] (reason) -- (fabric);
\draw[mutedarrow] (env) -- (projection);
\draw[mutedarrow] (projection) -- (world);
\draw[arrow] (fabric) -- (env);
\draw[arrow] (world) -- (reason);
\end{tikzpicture}%
}
\caption{The Worldline architecture. The environment is continuously projected into a stateful substrate, and all agent action flows through a transaction fabric that operates on world state rather than direct tool selection.}
\label{fig:architecture}
\end{figure}

\subsection{Projection plane}

The projection plane is responsible for turning raw environmental signals into stable world state. It includes collectors for repositories, file systems, editors, shell sessions, process trees, test runners, CI pipelines, logs, traces, tickets, documents, knowledge bases, and infrastructure APIs. Its two most important functions are \emph{identity resolution} and \emph{evidence management}. Without identity resolution, the same service may appear as a repository, a deployment, a dashboard label, and a package namespace without ever becoming one thing. Without evidence management, the system cannot distinguish observations from guesses.

\subsection{Worldline store}

The store is not merely a graph database. It combines several state forms:

\begin{itemize}[leftmargin=1.8em]
    \item a typed entity graph for operational structure,
    \item an append-only evidence ledger,
    \item a branchable change log,
    \item a receipt ledger for execution,
    \item checkpointed snapshots for replay,
    \item anchored memory records with validity rules.
\end{itemize}

This mixed representation matters. Graphs are good for structure. Logs are good for causality. Snapshots are good for replay. Memories are good for continuity. No single storage idiom is sufficient on its own.

\subsection{Reasoning and control plane}

The control plane includes intent compilation, closure construction, planning, scheduling, work decomposition, policy evaluation, and merge arbitration. Its job is not to replace model intelligence. Its job is to provide a stable substrate within which model intelligence can behave consistently.

\subsection{Transaction fabric}

The transaction fabric compiles abstract transition contracts into actuator-level operations. It may invoke shells, editors, test runners, deployment APIs, or existing tool servers, but it does so under a contract with observers and receipts. This is where the architecture cleanly subsumes tool protocols without centering them.

\subsection{Experience plane}

Developers interact with Worldline through several surfaces: an IDE overlay that highlights closure and risk, a command-line interface for branch and replay operations, a review cockpit for approving envelopes and merges, and a timeline explorer for understanding causal episodes.

\section{Context Extraction Model}

Worldline separates \emph{projection} from \emph{closure}. Projection builds the global operational twin. Closure extracts the task-relevant slice. This distinction is essential because many current systems conflate indexing with context selection.

\begin{figure}[H]
\centering
\resizebox{\textwidth}{!}{%
\begin{tikzpicture}[node distance=8mm and 8mm]
\node[plainbox] (fs) {Repo and FS};
\node[plainbox, below=of fs] (term) {Shell and Process};
\node[plainbox, below=of term] (ci) {Build and CI};
\node[plainbox, below=of ci] (rt) {Logs and Traces};
\node[plainbox, below=of rt] (docs) {Docs and Tickets};

\node[layer, right=18mm of ci, minimum width=3.6cm] (norm) {
    \begin{tabular}{c}
    \textbf{Sensor Layer} \\
    parsers, watchers, adapters
    \end{tabular}
};

\node[layer, right=12mm of norm, minimum width=3.9cm] (id) {
    \begin{tabular}{c}
    \textbf{Projection Kernel} \\
    normalize, resolve identity, attach evidence
    \end{tabular}
};

\node[layer, right=12mm of id, minimum width=3.6cm] (graph) {
    \begin{tabular}{c}
    \textbf{Worldline Graph} \\
    entities, edges, facets, memories
    \end{tabular}
};

\node[accent, above=12mm of graph] (intent) {Intent};
\node[accent, above=of id] (policy) {Budgets and Policy};

\node[layer, right=12mm of graph, minimum width=3.6cm] (closure) {
    \begin{tabular}{c}
    \textbf{Closure Engine} \\
    structural, causal, temporal, semantic expansion
    \end{tabular}
};

\node[layer, right=12mm of closure, minimum width=3.2cm] (pkg) {
    \begin{tabular}{c}
    \textbf{Context Package} \\
    bounded world slice plus evidence
    \end{tabular}
};

\draw[mutedarrow] (fs) -- (norm);
\draw[mutedarrow] (term) -- (norm);
\draw[mutedarrow] (ci) -- (norm);
\draw[mutedarrow] (rt) -- (norm);
\draw[mutedarrow] (docs) -- (norm);
\draw[arrow] (norm) -- (id);
\draw[arrow] (id) -- (graph);
\draw[arrow] (graph) -- (closure);
\draw[arrow] (closure) -- (pkg);
\draw[arrow] (intent) -- (closure);
\draw[arrow] (policy) -- (closure);
\end{tikzpicture}%
}
\caption{Worldline context extraction. Raw environment signals are projected into a canonical world model. Intent-conditioned closure then constructs the bounded context package used for planning and execution.}
\label{fig:closure}
\end{figure}

\subsection{Projection is continuous}

Projection is not invoked only when the agent asks. The harness continuously learns the environment. Repositories are parsed in the background. Branch topology is known before an action request. CI results are already attached to build targets. Runtime failures are already linked to services and releases. This shifts work from prompt time to system time.

\subsection{Closure is relevance with structure}

Closure uses multiple edge families:

\begin{itemize}[leftmargin=1.8em]
    \item \textbf{Structural edges:} imports, ownership, build dependency, deployment dependency, package graph, test coverage.
    \item \textbf{Temporal edges:} recent changes, deployment windows, failure bursts, recent conversations, incident overlap.
    \item \textbf{Causal edges:} stack traces, trace spans, command outcomes, dependency breakage, issue lineage.
    \item \textbf{Semantic edges:} doc similarity, symbol meaning, natural language references, design notes.
    \item \textbf{Normative edges:} policies, coding standards, secret boundaries, review rules.
\end{itemize}

An intent does not need all reachable state. It needs the \emph{smallest sufficient} operational slice. That is why closure is bounded by utility and budget. Worldline should improve agent autonomy without exploding context windows.

\subsection{Epistemic clarity}

Because every fact is evidence-backed, closure can preserve uncertainty. The context package can say, for example, that a deployment correlation is inferred with medium confidence from traces and timestamps, while a test failure is directly observed from CI output. This is more valuable than collapsing everything into flat text.

\section{Execution Model}

Worldline changes execution from ad hoc calls into verified transitions. Figure~\ref{fig:lifecycle} shows the lifecycle.

\begin{figure}[H]
\centering
\resizebox{\textwidth}{!}{%
\begin{tikzpicture}[node distance=8mm and 8mm]
\node[accent] (intent) {Intent};
\node[box, right=of intent] (closure) {Compute Closure};
\node[box, right=of closure] (branch) {Open Branch};
\node[box, right=of branch] (plan) {Plan Contracts};
\node[box, right=of plan] (exec) {Execute};
\node[box, right=of exec] (verify) {Verify};
\node[box, below=of verify] (recover) {Recover or Compensate};
\node[box, right=of verify] (commit) {Commit Receipt};
\node[box, right=of commit] (merge) {Merge or Escalate};

\draw[arrow] (intent) -- (closure);
\draw[arrow] (closure) -- (branch);
\draw[arrow] (branch) -- (plan);
\draw[arrow] (plan) -- (exec);
\draw[arrow] (exec) -- (verify);
\draw[arrow] (verify) -- node[above]{success} (commit);
\draw[arrow] (commit) -- (merge);
\draw[arrow] (verify) -- node[right]{failure} (recover);
\draw[arrow] (recover) |- (plan);
\end{tikzpicture}%
}
\caption{The Worldline execution lifecycle. Agents work on branches of world state, execute transition contracts through the transaction fabric, verify postconditions, and either merge, compensate, or re-plan.}
\label{fig:lifecycle}
\end{figure}

\subsection{Intent compilation}

Execution begins with a typed intent, not raw natural language. Natural language can still be the authoring surface, but the system compiles it into explicit scope, goals, invariants, budgets, and trust requirements. This closes a common gap between developer meaning and agent execution.

\subsection{Branches as execution spaces}

A branch is more than a git branch. It is a speculative timeline over the full Worldline. It may include code changes, terminal state, observed build failures, generated hypotheses, partial deployments, and memory updates. This means an agent can experiment, verify, and recover without corrupting the canonical world state.

\subsection{Transition compilation}

Each transition contract is compiled into concrete operations. For a code edit, the actuator may be an editor integration plus a formatting pass plus a test invocation. For a runtime diagnosis, the actuator may be a trace query, log slice, or container inspection. For an infrastructure change, the actuator may be an IaC update followed by plan verification. The key is that the agent asks for \emph{the transition}, not for specific low-level APIs.

\subsection{Observers and postconditions}

Observers verify whether the world moved as intended. They are independent of the actuation path. This separation prevents a common problem in current systems where the same tool that makes a change is implicitly trusted to describe its correctness. A deployment change may be observed by health checks, error budget monitors, and trace deltas. A code change may be observed by test results, compile status, and linter output.

\subsection{Compensation and recovery}

If postconditions fail, the runtime attempts compensation according to policy. Compensation may revert a file patch, restore a snapshot, halt a rollout, or quarantine the branch for human review. Recovery is first-class, not an afterthought.

\section{State and Memory Model}

Worldline distinguishes between \emph{world state}, \emph{episodic history}, and \emph{anchored memory}.

\subsection{World state}

World state is the current best-known model of the environment. It is live, partially observed, and evidence-scored. The system must tolerate uncertainty and stale edges. This is why each claim carries epistemic status.

\subsection{Episodic history}

Episodes record what happened: which intents were active, which closures were used, which transitions executed, what observers saw, what branches were merged, and how recovery proceeded. Episodes make autonomous work inspectable.

\subsection{Anchored memory}

Memory is represented as typed records attached to entities or episodes. Useful memory categories include:

\begin{itemize}[leftmargin=1.8em]
    \item \textbf{Factual memory:} durable facts such as ownership or service boundaries.
    \item \textbf{Heuristic memory:} repair patterns, migration rules, or known failure signatures.
    \item \textbf{Normative memory:} preferences, coding conventions, review practices.
    \item \textbf{Social memory:} who tends to approve, who owns a risk domain, who has historical context.
    \item \textbf{Incident memory:} what fixed a similar failure before and under what conditions.
\end{itemize}

Each memory record contains anchors, provenance, freshness policy, and a validity predicate. For instance, a memory that a certain migration script is safe may become invalid if the build graph or schema version changes beyond threshold. This is a direct answer to memory drift.

\subsection{Memory invalidation}

A crucial part of the model is forgetting. When the Worldline changes materially, some memories should weaken or expire. The system therefore supports invalidation triggers, such as dependency tree divergence, major release boundaries, policy changes, or contradictory evidence. An agent memory system that cannot forget is eventually untrustworthy.

\section{Permission and Trust Model}

Permission must be stated in the language of world transitions. This is one of the strongest departures from tool-centric systems.

\begin{figure}[H]
\centering
\resizebox{\textwidth}{!}{%
\begin{tikzpicture}[node distance=10mm and 10mm]
\node[layer, minimum width=3.2cm, minimum height=4.0cm] (local) {
    \begin{tabular}{c}
    \textbf{Local Zone} \\
    editor \\
    shell \\
    repo write
    \end{tabular}
};
\node[layer, right=of local, minimum width=3.2cm, minimum height=4.0cm] (ci) {
    \begin{tabular}{c}
    \textbf{CI Zone} \\
    build \\
    test \\
    artifact read
    \end{tabular}
};
\node[layer, right=of ci, minimum width=3.2cm, minimum height=4.0cm] (staging) {
    \begin{tabular}{c}
    \textbf{Staging Zone} \\
    deploy \\
    logs \\
    trace read
    \end{tabular}
};
\node[layer, right=of staging, minimum width=3.2cm, minimum height=4.0cm] (prod) {
    \begin{tabular}{c}
    \textbf{Production Zone} \\
    read mostly \\
    guarded write \\
    rollback only
    \end{tabular}
};

\node[accent, above=15mm of $(ci)!0.5!(staging)$] (policy) {Policy Engine and Capability Issuer};
\node[warn, below=15mm of $(ci)!0.5!(staging)$] (secret) {Secret Membrane};

\draw[arrow] (policy) -- (local);
\draw[arrow] (policy) -- (ci);
\draw[arrow] (policy) -- (staging);
\draw[arrow] (policy) -- (prod);

\draw[mutedarrow] (local) -- node[above]{envelope check} (ci);
\draw[mutedarrow] (ci) -- node[above]{promotion gate} (staging);
\draw[mutedarrow] (staging) -- node[above]{review gate} (prod);

\draw[arrow] (secret) -- (local);
\draw[arrow] (secret) -- (ci);
\draw[arrow] (secret) -- (staging);
\draw[arrow] (secret) -- (prod);
\end{tikzpicture}%
}
\caption{Trust boundaries in Worldline. Capability envelopes govern which transition classes may cross which zones. Secrets are handled through a membrane that exposes policy-checked handles rather than raw values to the broader Worldline.}
\label{fig:trust}
\end{figure}

\subsection{Capability envelopes}

A capability envelope answers not only \emph{who} may act, but also \emph{how}, \emph{where}, \emph{under what budgets}, and \emph{with what review requirements}. An envelope can state, for example:

\begin{quote}
The agent may modify application code under repository \texttt{checkout/}, may run local and CI tests, may query staging traces, may not cross into production write, may not materialize secrets, must request human approval before schema changes, and must stop if more than 12 files or 2 services are affected.
\end{quote}

This level of expression is impossible to capture with endpoint allow-lists alone.

\subsection{Trust zones}

Worldline models explicit zones such as local workstation, repository write, CI, staging, production read, production write, internet egress, and secret domains. Policies define which transitions are admissible across zone boundaries.

\subsection{Secret membrane}

Secrets must not become generic facts in the Worldline. The secret membrane exposes references, handles, or derived predicates instead of raw values. For example, the runtime can verify that an environment variable is present or that a credential rotates successfully without leaking the credential into the general memory graph.

\subsection{Proof-carrying actions}

Worldline does not require formal proofs in the theorem-proving sense, but it does require \emph{action certificates}. Each receipt includes machine-checkable evidence that preconditions, policy checks, and postcondition observers were satisfied or violated. This creates a higher-trust execution trail than plain logs.

\section{Observability, Replay, and Debugging}

Observability must explain the agent's behavior at the level developers actually care about: what the agent believed, which entities it considered relevant, which transitions it attempted, what changed, and where divergence occurred.

\subsection{Receipts as a causal ledger}

Receipts form a causal ledger. A developer can query:

\begin{itemize}[leftmargin=1.8em]
    \item Why did the agent edit this file?
    \item Which evidence linked this file to the declared intent?
    \item Which observer failed after the deployment step?
    \item What was the trust envelope at the moment of action?
    \item Which recovery pathway executed after the failed test?
\end{itemize}

The answer is computed from receipts and closure state, not reconstructed from chat.

\subsection{Replay}

Replay uses checkpointed state plus original receipts to reconstruct an episode. Figure~\ref{fig:replay} shows the model.

\begin{figure}[H]
\centering
\resizebox{\textwidth}{!}{%
\begin{tikzpicture}[node distance=10mm and 10mm]
\node[plainbox] (s0) {Snapshot $S_0$};
\node[plainbox, right=of s0] (s1) {Snapshot $S_1$};
\node[plainbox, right=of s1] (s2) {Snapshot $S_2$};
\node[plainbox, right=of s2] (s3) {Snapshot $S_3$};

\draw[mutedarrow] (s0) -- node[above]{receipts} (s1);
\draw[mutedarrow] (s1) -- node[above]{receipts} (s2);
\draw[mutedarrow] (s2) -- node[above]{receipts} (s3);

\node[accent, below=15mm of s1] (branch) {Branch from $S_1$};
\node[box, right=of branch] (replay) {Replay Engine};
\node[box, right=of replay] (diff) {Divergence Diff};

\draw[arrow] (s1) -- (branch);
\draw[arrow] (branch) -- (replay);
\draw[arrow] (replay) -- (diff);
\draw[arrow] (s2) -- (replay);
\draw[arrow] (s3) |- (diff);
\end{tikzpicture}%
}
\caption{Replay in Worldline. Checkpointed snapshots and receipts allow re-execution or diagnosis from an earlier state. Divergence can be inspected as a state diff rather than guessed from terminal history.}
\label{fig:replay}
\end{figure}

Replay may be deterministic, bounded-deterministic, or counterfactual. Deterministic replay is possible when all relevant inputs are captured or stubbed. Bounded-deterministic replay is used when external systems have changed but the harness can preserve the closure, policies, and action ordering. Counterfactual replay explores ``what if'' branches, such as trying a different patch or deployment ordering.

\subsection{Divergence diagnosis}

A powerful feature of a Worldline harness is that divergence has structure. The system can report whether failure arose from stale closure, unsatisfied preconditions, unreliable actuators, observer disagreement, environmental nondeterminism, or policy denial. This is a significantly higher level of introspection than raw task failure.

\section{Multi-Agent Coordination}

Multi-agent systems need a shared coordination substrate. Worldline provides it through branch-based work contracts rather than unstructured chatter.

\begin{figure}[H]
\centering
\resizebox{\textwidth}{!}{%
\begin{tikzpicture}[node distance=10mm and 10mm]
\node[accent] (base) {Shared Base Worldline};
\node[box, below=of base] (coord) {Coordinator: decompose intent into work contracts};

\node[actor, below left=of coord] (a1) {Scout Agent};
\node[actor, below=of coord] (a2) {Editor Agent};
\node[actor, below right=of coord] (a3) {Verifier Agent};

\node[box, below=of a1] (b1) {Branch A};
\node[box, below=of a2] (b2) {Branch B};
\node[box, below=of a3] (b3) {Branch C};

\node[box, below=18mm of b2] (arb) {Merge Arbiter and Policy Gate};
\node[box, below=of arb] (merge) {Canonical Merge};

\draw[arrow] (base) -- (coord);
\draw[arrow] (coord) -- (a1);
\draw[arrow] (coord) -- (a2);
\draw[arrow] (coord) -- (a3);
\draw[arrow] (a1) -- (b1);
\draw[arrow] (a2) -- (b2);
\draw[arrow] (a3) -- (b3);
\draw[arrow] (b1) -- (arb);
\draw[arrow] (b2) -- (arb);
\draw[arrow] (b3) -- (arb);
\draw[arrow] (arb) -- (merge);
\end{tikzpicture}%
}
\caption{Multi-agent coordination in Worldline. A coordinator decomposes an intent into work contracts, assigns branch spaces, and merges results through an arbiter that enforces policy, conflict rules, and acceptance predicates.}
\label{fig:multiagent}
\end{figure}

\subsection{Work contracts}

A work contract is a sub-intent with explicit interface conditions: input closure, output schema, acceptance predicate, budget, dependency set, and capability envelope. This sharply improves decomposition quality. An agent is not merely told ``investigate the bug.'' It is given an operational contract.

\subsection{Branch isolation}

Each agent works on its own branch of the Worldline. Branches may overlap in scope, but conflicts are explicit and mergeable because the underlying world model is structured. For example, two agents can both inspect the same service while only one is authorized to mutate deployment state.

\subsection{Merge arbitration}

The merge arbiter evaluates acceptance predicates, policy compliance, observer results, and entity-level conflicts. In simple cases this resembles version control merge. In richer cases it resembles transaction arbitration over operational state, such as choosing which runtime diagnosis becomes canonical or whether a deployment rollback branch supersedes a code-fix branch.

\subsection{Long-horizon continuity}

Because Worldline preserves shared state, agents can leave and re-enter work without relying on long prompt transcripts. The branch itself is the handoff artifact.

\section{Failure and Recovery Model}

Autonomous systems are only as useful as their failure semantics. Worldline treats failure as a first-class state transition outcome.

\subsection{Failure classes}

Failures are categorized into at least five classes:

\begin{enumerate}[leftmargin=1.8em]
    \item \textbf{Context failure:} the closure omitted a relevant entity or over-trusted stale evidence.
    \item \textbf{Planning failure:} the chosen transition sequence was invalid or incomplete.
    \item \textbf{Actuation failure:} the low-level operation did not execute as intended.
    \item \textbf{Verification failure:} the transition executed but postconditions were not met.
    \item \textbf{Policy failure:} the action was denied, exceeded budget, or crossed a trust boundary.
\end{enumerate}

This classification allows recovery to be precise.

\subsection{Recovery pathways}

Recovery pathways are modeled objects. They may include retry with refreshed closure, compensation, rollback, branch quarantine, human escalation, or alternate plan selection. Because recovery is captured in receipts, future agents can learn from past failures in a bounded and trustworthy way.

\subsection{Leases and heartbeats}

For long-running tasks, each active branch carries a lease. Agents must renew the lease via progress receipts. If the lease expires, the coordinator can reassign or freeze the branch. This addresses silent abandonment in multi-agent workflows.

\section{Developer Experience Model}

Worldline must not feel like a systems paper trapped in a data model. It must improve day-to-day developer life. Figure~\ref{fig:workflow} sketches the workflow.

\begin{figure}[H]
\centering
\resizebox{\textwidth}{!}{%
\begin{tikzpicture}[node distance=8mm and 8mm]
\node[actor] (dev) {Developer};
\node[box, right=of dev] (intent) {Declare Intent};
\node[box, right=of intent] (inspect) {Inspect Closure};
\node[box, right=of inspect] (approve) {Approve Envelope};
\node[box, right=of approve] (delegate) {Delegate to Agents};
\node[box, right=of delegate] (review) {Review Receipts};
\node[box, right=of review] (merge) {Merge};

\draw[arrow] (dev) -- (intent);
\draw[arrow] (intent) -- (inspect);
\draw[arrow] (inspect) -- (approve);
\draw[arrow] (approve) -- (delegate);
\draw[arrow] (delegate) -- (review);
\draw[arrow] (review) -- (merge);
\end{tikzpicture}%
}
\caption{A simplified developer workflow in Worldline. The developer works in terms of intent, closure, envelopes, and receipts rather than manually curating prompts and post hoc logs.}
\label{fig:workflow}
\end{figure}

\subsection{The human interface}

The developer experience should center on a few high-leverage concepts:

\begin{itemize}[leftmargin=1.8em]
    \item \textbf{Intent authoring:} express outcome, scope, invariants, and budget.
    \item \textbf{Closure inspection:} inspect the world slice the agent will use.
    \item \textbf{Envelope approval:} approve or tighten the transition permissions.
    \item \textbf{Receipt review:} understand exactly what happened and why.
    \item \textbf{Replay and branch diff:} debug or compare alternative episodes.
\end{itemize}

These are far more legible than a chain of prompts plus tool logs.

\subsection{A possible command surface}

A reference CLI might include commands such as:

\begin{verbatim}
wl intent create "Upgrade billing service to API v3 without p95 regression"
wl closure inspect --intent billing-v3
wl branch open --intent billing-v3
wl run --intent billing-v3 --agent editor
wl replay --branch billing-v3/fix-attempt-2
wl explain --receipt rcp_01482
wl merge --branch billing-v3/fix-attempt-2
\end{verbatim}

The important point is not the exact syntax. It is the user model. Developers reason about world branches and verified changes, not about which tools were called in which order.

\section{Case Studies}

This section presents scenario-based case studies. They are intended to illuminate the architecture rather than to claim empirical results.

\subsection{Case study 1: framework migration across code, tests, and docs}

Consider a migration from framework version $N$ to $N+2$ across a large monorepo. A tool-centric agent can call search, edit, and test endpoints, but it struggles to retain the full migration state over time. Worldline represents the migration as an intent with explicit invariants, such as passing target test suites and preserving public API contracts. The closure includes dependency graphs, migration guides, affected build targets, prior similar edits, known incompatibilities, and owner-specific review rules. Multiple agents can then branch into package-level remediation, documentation updates, and compatibility verification. Their results merge against the same operational twin.

\subsection{Case study 2: flaky integration test diagnosis}

A flaky test is rarely a text-local problem. It can involve timing, deployment history, trace anomalies, recent commits, or hidden shared-state assumptions. In Worldline, the closure for the intent ``stabilize checkout integration test'' naturally includes test history, runtime traces during failures, suspect services, recent dependency shifts, and past incidents with similar signatures. A scout agent explores causal hypotheses on one branch. An editor agent prepares a code fix on another. A verifier agent reproduces the failure under controlled branch snapshots. The developer reviews receipts rather than a maze of logs.

\subsection{Case study 3: incident hotfix with guarded production scope}

Suppose staging reveals that a recent release caused a read-path regression. The organization allows production read access to agents but restricts write access to human-approved rollback operations. Worldline can encode this directly. The agent closure includes the deployment diff, relevant traces, configuration drift, and rollback playbook. The transition fabric permits log and trace queries, patch preparation, and rollback simulation, but production write remains behind a review gate. The result is more autonomy where safe, without pretending that all actions are equally permissible.

\subsection{Case study 4: secrets rotation and policy hardening}

Secrets rotation is an instructive stress case because the agent must reason across config, runtime, CI, deployment, and policy without leaking secret material. Worldline handles this through the secret membrane, which exposes presence and validity predicates instead of raw values. The rotation intent can require that all dependent services verify connectivity, all CI jobs consume the new handle, and no receipt persists secret content. A purely tool-centric design makes this far harder to guarantee.

\section{Evaluation Framework}

The architecture proposed here is ambitious. It therefore requires a serious evaluation framework.

\subsection{Metrics}

Table~\ref{tab:metrics} lists representative metrics.

\begin{table}[H]
\centering
\caption{Representative evaluation metrics for Worldline}
\label{tab:metrics}
\begin{tabularx}{\textwidth}{>{\raggedright\arraybackslash}p{3.0cm} X}
\toprule
\textbf{Metric} & \textbf{Meaning} \\
\midrule
Closure Recall & Fraction of task-relevant entities present in the closure, measured against expert-labeled operational slices. \\
Closure Precision & Fraction of closure entities that prove relevant during execution, measuring over-expansion. \\
Replay Fidelity & Agreement between original and replayed outcomes, including postcondition and receipt consistency. \\
Permission Precision & Degree to which capability envelopes allow necessary actions while rejecting unnecessary or policy-violating ones. \\
Long-Horizon Success & Task completion rate for multi-step tasks requiring more than one branch or session. \\
Recovery Half-Life & Time from detected failure to safe compensated or escalated state. \\
Receipt Completeness & Fraction of meaningful actions with causal receipts sufficient for explanation and audit. \\
Merge Quality & Rate at which multi-agent branches combine without hidden conflict or semantic loss. \\
Trust Lift & Human-rated confidence in agent behavior compared with a tool-centric baseline. \\
\bottomrule
\end{tabularx}
\end{table}

\subsection{Benchmark families}

A robust benchmark suite should include at least:

\begin{itemize}[leftmargin=1.8em]
    \item \textbf{MigrationBench:} large dependency or framework migrations with cross-cutting edits.
    \item \textbf{FlakeBench:} flaky test diagnosis with runtime and temporal context.
    \item \textbf{HotfixBench:} guarded incident response spanning code and deployment.
    \item \textbf{RecoveryBench:} induced actuator, observer, and policy failures.
    \item \textbf{MemoryBench:} long-horizon continuity across sessions and environment drift.
    \item \textbf{CoordBench:} multi-agent decomposition, branch merge, and handoff quality.
\end{itemize}

\subsection{Baselines}

A fair baseline should compare Worldline to strong tool-centric systems, not straw men. At minimum, baselines should include:
\begin{enumerate}[leftmargin=1.8em]
    \item an agent with direct tool registry access,
    \item the same agent plus retrieval-based memory,
    \item the same agent plus scripted orchestration and approval gates.
\end{enumerate}

The question is not whether Worldline can invoke tools. It obviously can. The question is whether Worldline's stronger state model materially improves autonomy, reliability, and trust.

\section{Comparison with MCP-Style Systems}

The comparison is best understood at the architectural level. Figure~\ref{fig:comparison} illustrates the shift, and Table~\ref{tab:comparison} summarizes it.

\begin{figure}[H]
\centering
\resizebox{\textwidth}{!}{%
\begin{tikzpicture}[node distance=8mm and 10mm]
\node[accent] (lefttitle) {Tool-Centric Harness};
\node[accent, right=45mm of lefttitle] (righttitle) {Worldline Harness};

\node[layer, below=of lefttitle, minimum width=4.1cm] (lprompt) {
    \begin{tabular}{c}
    prompt plus chat state
    \end{tabular}
};
\node[layer, below=of lprompt, minimum width=4.1cm] (ltools) {
    \begin{tabular}{c}
    tool registry
    \end{tabular}
};
\node[layer, below=of ltools, minimum width=4.1cm] (lenv) {
    \begin{tabular}{c}
    opaque environment
    \end{tabular}
};

\node[layer, below=of righttitle, minimum width=4.8cm] (rintent) {
    \begin{tabular}{c}
    typed intent plus budgets
    \end{tabular}
};
\node[layer, below=of rintent, minimum width=4.8cm] (rclosure) {
    \begin{tabular}{c}
    intent-conditioned closure
    \end{tabular}
};
\node[layer, below=of rclosure, minimum width=4.8cm] (rworld) {
    \begin{tabular}{c}
    worldline store
    \end{tabular}
};
\node[layer, below=of rworld, minimum width=4.8cm] (rfabric) {
    \begin{tabular}{c}
    transition fabric
    \end{tabular}
};
\node[layer, below=of rfabric, minimum width=4.8cm] (renv) {
    \begin{tabular}{c}
    instrumented environment
    \end{tabular}
};

\draw[arrow] (lprompt) -- (ltools);
\draw[arrow] (ltools) -- (lenv);

\draw[arrow] (rintent) -- (rclosure);
\draw[arrow] (rclosure) -- (rworld);
\draw[arrow] (rworld) -- (rfabric);
\draw[arrow] (rfabric) -- (renv);
\end{tikzpicture}%
}
\caption{Architectural contrast. Tool-centric systems place an interface registry between the agent and an opaque environment. Worldline inserts a continuously maintained operational twin and a transaction fabric between intent and execution.}
\label{fig:comparison}
\end{figure}

\begin{table}[H]
\centering
\caption{Conceptual comparison between MCP-style systems and Worldline}
\label{tab:comparison}
\begin{tabularx}{\textwidth}{>{\raggedright\arraybackslash}p{3.1cm} >{\raggedright\arraybackslash}p{5.0cm} X}
\toprule
\textbf{Dimension} & \textbf{MCP-style systems} & \textbf{Worldline} \\
\midrule
Primary abstraction & Callable tools and schemas & Executable world model and transition contracts \\
Context model & Pulled on demand from tools & Continuously projected, intent-scoped closure \\
Memory & External notes, transcripts, or retrieval stores & Anchored memory tied to entities and episodes \\
Execution semantics & Imperative calls & Preconditioned, observed, receipt-bearing transitions \\
Permissions & Endpoint or tool level & Capability envelopes over scope, zones, and budgets \\
Replay & Limited session reconstruction & Checkpointed, branch-based replay and divergence analysis \\
Observability & Tool logs & Causal receipts from intent through recovery \\
Multi-agent coordination & External orchestration & Shared world branches and work contracts \\
Role of existing tools & Primary programming interface & Leaf actuators beneath the runtime \\
\bottomrule
\end{tabularx}
\end{table}

The most important sentence in this comparison is the last row. Worldline does not deny the usefulness of tool protocols. It demotes them. They become part of the actuation layer in the same way device drivers sit beneath an operating system.

\section{Product Thesis and Adoption Path}

A serious architecture should imply a serious product.

\subsection{Product thesis}

The company that controls the Worldline for software work controls the trust layer for autonomous engineering. This is strategically stronger than controlling one more code assistant because it becomes the system of record for how agents understand, change, and explain the software world. It sits at the seam between IDEs, source control, CI, runtime telemetry, knowledge systems, and infrastructure. That seam is where durable value accumulates.

The defensibility comes from five sources:

\begin{itemize}[leftmargin=1.8em]
    \item \textbf{Cross-layer data network effects:} the Worldline improves as more environment surfaces are projected.
    \item \textbf{Policy embedding:} organizations codify trust, review, and blast-radius policy directly into the runtime.
    \item \textbf{Operational memory:} receipts and anchored memories form a proprietary corpus of engineering episodes.
    \item \textbf{Ecosystem position:} third parties can write sensors, facets, observers, and actuators against the Worldline substrate.
    \item \textbf{Switching costs:} once a team depends on replay, receipts, and branchable multi-agent state, returning to raw prompt orchestration is painful.
\end{itemize}

\subsection{Adoption path}

The adoption path should be progressive.

\textbf{Phase 1: Local mode.} Start with repository, shell, test runner, and git integration. Deliver closure, receipts, and replay for single-repo workflows.

\textbf{Phase 2: Team mode.} Add CI, build graph, and shared memory. Deliver better diagnosis and review.

\textbf{Phase 3: Runtime mode.} Add logs, traces, deployments, and incident workflows. Deliver cross-layer closure and guarded rollouts.

\textbf{Phase 4: Policy mode.} Add capability envelopes, secret membrane, compliance receipts, and org-level approval rules.

\textbf{Phase 5: Coordination mode.} Add multi-agent work contracts, merge arbitration, and workload-level scheduling across teams.

This path matters because it avoids the trap of requiring a full organizational platform bet before the first unit of value appears.

\section{Implementation Sketch}

Worldline can be implemented incrementally. A practical MVP would contain the following components.

\subsection{Local runtime}

A local daemon watches file system changes, git state, terminal transcripts, and test results. It stores an append-only event log plus snapshots and a typed graph in a local database. This is sufficient to create branchable replay for a single repository.

\subsection{Closure engine}

The closure engine uses static analysis, test coverage, recent diffs, semantic indexing, and terminal evidence to build intent-scoped packages. It should expose both a machine-readable schema and a developer-facing explainer.

\subsection{Transition fabric}

The transition fabric starts with a small set of compiled transition types: read, edit, test, build, search, inspect process, inspect trace, open issue, and propose patch. More types can be added over time.

\subsection{Receipt ledger}

Every transition attempt emits a receipt, even if denied or failed. This ensures the runtime can explain inaction as well as action.

\subsection{Cloud control plane}

A team deployment adds identity, policy synchronization, shared memory, runtime integrations, and multi-agent coordination. The architecture remains local-first because the local daemon can continue to operate when disconnected.

\section{Limitations}

Worldline is not free. It introduces real costs and open tensions.

\subsection{Projection cost}

Continuously projecting the environment consumes compute, storage, and integration effort. A naive implementation could become heavy. Practical systems will need progressive fidelity, selective sensor activation, and intent-aware caching.

\subsection{Ontology risk}

Any world model reflects an ontology. If the ontology is too rigid, it will fail to capture important project-specific meaning. If it is too loose, it will collapse into untyped mush. A successful implementation must support extensible schemas without giving up transactional semantics.

\subsection{Replay limits}

Perfect replay is impossible for many real systems, especially when external services, nondeterministic timing, or unrecoverable side effects are involved. Worldline therefore offers bounded-deterministic replay, not a universal guarantee.

\subsection{Policy burden}

Fine-grained capability envelopes are powerful, but they also create authoring burden. Organizations may initially misconfigure policies or over-constrain agents. Good defaults and policy simulation are required.

\subsection{Privacy and concentration risk}

A rich Worldline can become a sensitive concentration point for source code, traces, team knowledge, and operational history. Product design must therefore prioritize local-first storage, secret membranes, selective retention, and clear data governance.

\section{Future Work}

Several research directions follow naturally.

First, closure quality could be improved through learned relevance functions trained on successful engineering episodes.

Second, merge arbitration could benefit from richer semantic conflict models that reason beyond files and into service contracts, runtime risk, and policy implications.

Third, action certificates could be strengthened into more formal proof objects for especially sensitive transitions.

Fourth, the Worldline substrate could support simulation modes in which agents evaluate hypothetical refactors or migrations before acting.

Fifth, a mature ecosystem of third-party facets and observers could turn the Worldline into a category-level platform rather than a single product.

\section{Conclusion}

The dominant mental model in agentic developer tooling today is that the environment is a set of tools and the agent is a policy for invoking them. This paper argues that the mental model is wrong at its foundation. Software work is not primarily about calls. It is about transforming a live, constrained, partially observed world. The primitive should therefore be that world.

Worldline is an attempt to define such a primitive. It turns the developer environment into a causally versioned operational twin. It gives agents intent-scoped closure instead of brittle prompt assembly. It expresses action as verified transition contracts instead of raw calls. It grounds memory in entities and episodes. It makes permissions explicit in the language of scope, budget, and trust zones. It makes multi-agent work branchable and mergeable. It makes replay and recovery native.

If this architecture is correct, then tool-call protocols become what they should have been all along: useful integration adapters beneath a much stronger control plane. Developers will not look back on tool servers as the final form of autonomous software work. They will look back on them as the stage before the software world itself became programmable.

\appendix

\section{Appendix A: Example Schemas}

The following sketches the kind of typed objects a Worldline runtime might persist.

\begin{verbatim}
Intent {
  id: string
  summary: string
  scope: [entity_ref]
  goals: [predicate]
  invariants: [predicate]
  budgets: {
    time_minutes: int
    max_files_changed: int
    max_services_touched: int
    review_required: bool
  }
  trust_envelope: {
    zones_read: [zone]
    zones_write: [zone]
    allow_secret_materialization: false
  }
}
\end{verbatim}

\begin{verbatim}
TransitionContract {
  id: string
  target_query: world_query
  preconditions: [predicate]
  action: action_plan
  postconditions: [predicate]
  observers: [observer_ref]
  compensation: [action_plan]
  capability_envelope: envelope_ref
}
\end{verbatim}

\begin{verbatim}
Receipt {
  id: string
  intent_id: string
  transition_id: string
  branch_id: string
  before_snapshot: snapshot_ref
  after_snapshot: snapshot_ref
  delta: [entity_delta]
  observer_results: [observer_result]
  policy_checks: [policy_result]
  outcome: success | failed | denied | compensated
}
\end{verbatim}

\section{Appendix B: Example Episode}

A typical episode may unfold as follows.

\begin{enumerate}[leftmargin=1.8em]
    \item The developer creates an intent to stabilize a flaky integration test within one service boundary.
    \item The closure engine returns a bounded slice containing the failing test, suspect modules, relevant runtime traces, recent commit history, and past incident notes.
    \item A scout agent forms a hypothesis that a timeout threshold is coupled to a queueing delay introduced by a dependency bump.
    \item An editor agent opens a branch and prepares a code patch plus a tighter retry policy.
    \item A verifier agent replays the failure scenario against a checkpoint and observes reduced flakiness but increased latency.
    \item The planner rejects merge because a declared invariant forbids latency regression.
    \item A second patch is proposed, verified, and merged after human review of the receipt chain.
\end{enumerate}

This episode is not just text history. It is a structured branch of the Worldline and can be replayed, audited, and used to improve future closure and planning.

\begin{thebibliography}{9}

\bibitem{brooks1987}
Frederick P. Brooks, Jr.
\newblock No Silver Bullet: Essence and Accidents of Software Engineering.
\newblock \emph{Computer}, 20(4):10--19, 1987.

\bibitem{lamport1978}
Leslie Lamport.
\newblock Time, Clocks, and the Ordering of Events in a Distributed System.
\newblock \emph{Communications of the ACM}, 21(7):558--565, 1978.

\bibitem{gray1992}
Jim Gray and Andreas Reuter.
\newblock \emph{Transaction Processing: Concepts and Techniques}.
\newblock Morgan Kaufmann, 1992.

\bibitem{kleppmann2017}
Martin Kleppmann.
\newblock \emph{Designing Data-Intensive Applications}.
\newblock O'Reilly Media, 2017.

\bibitem{ousterhout2018}
John Ousterhout.
\newblock \emph{A Philosophy of Software Design}.
\newblock Yaknyam Press, 2018.

\end{thebibliography}

\end{document}