body.tex

\section{Introduction}
\label{sec:intro}

Consider a personalized agent whose memory contains 100 trips accumulated across years of conversation. The user may ask, ``Where did I stay in Paris?'', but also ``How many times have I traveled to Europe?'' or ``How many trips did I take in 2025?'' The first question may be answered from one relevant memory. The latter questions generally require enumerating the complete trip history, filtering it, and counting the matching records: omitting even one trip can change the answer. These examples expose two distinct uses of long-term memory: factual recall and analytical inference over a collection.

Most agent-memory systems store conversations as text, extracted facts, linked notes, or graphs and answer questions through top-$k$ retrieval. This interface is effective when the answer appears in one or a few records, but retrieval is designed to return the most relevant evidence, not to enumerate a complete collection. Once the number of relevant records exceeds $k$, an exact count or aggregate becomes unreliable. Passing the entire history to the model restores access to the records, but incurs growing context cost and still asks the model to parse and count them in-context. Existing long-term-memory benchmarks likewise emphasize query-driven recall~\citep{maharana2024locomo,wu2025longmemeval,hu2025memoryagentbench} rather than complete-set computation.

A conventional structured database addresses the computational problem only after a suitable data model has been provided. For the travel example, a developer might define a \texttt{Trip} table with dates, countries, and regions, after which the desired counts are straightforward. A general personal agent, however, encounters evolving information across travel, health, finance, relationships, and domains not known in advance. Requiring developers to anticipate and maintain a schema for every such domain turns open-ended user memory into an ontology-engineering problem. Although database schemas can be migrated, the system still needs an agent that decides what structures to create and how they should evolve.

We propose \textbf{User as Code} (UaC), which gives that responsibility to the language model. UaC uses the code-generation capabilities of modern LLMs to maintain an executable view of user data and its data model as typed Python. Its two-phase write path first appends facts from each session without overwriting prior evidence, then periodically generates schemas and typed state from a bounded prefix of the accumulated fact serialization. As the user changes, the model can introduce or revise dataclasses and collections rather than fitting every fact into a fixed human-authored ontology. An interpreter can then enumerate typed records for exact aggregation. Textual fact and archive channels remain available for evidence not represented in the bounded code view.

UaC does not claim that Python alone improves reasoning: on clean, already structured inputs, Full Context with a Python REPL matches UaC. The contribution is a persistent write-and-use architecture that converts unstructured conversation into an evolving, code-readable representation and reuses it across later questions. Specifically, we contribute:
\begin{itemize}[leftmargin=*]
\item \textbf{An LLM-generated executable memory view} whose schemas and typed state are generated rather than fixed by a human. The representation supports attribute access and complete-set computation with ordinary Python.
\item \textbf{A durable-source/write-view architecture} that retains append-only facts and raw conversation separately from the generated code view. The three answer-time channels can therefore recover evidence that the bounded structuring input or generated schema omits.
\item \textbf{Evaluation across recall and analytical inference:} full 1{,}986-question LOCOMO suites and 100 deterministically scored analytical cases. UaC has the highest observed persistent-system judge accuracy with Luna/Gemini (78.8\%/80.6\%), with metric-dependent token-F1/refusal tradeoffs, and reaches 100\% analytical accuracy.
\end{itemize}

\section{Related Work}
\label{sec:related}

Most agent-memory systems follow a store--retrieve pattern. They store atomic facts (Mem0~\citep{chhikara2025mem0}), linked notes (A-MEM~\citep{xu2025amem}), temporal graphs (Zep/Graphiti~\citep{rasmussen2025zep}), episodes (MemMachine~\citep{wang2026memmachine}), or hybrid logical networks (Hindsight~\citep{latimer2025hindsight}). OS-inspired systems such as MemGPT~\citep{packer2023memgpt} manage text pages through an editable memory hierarchy. UaC instead makes a generated view of persistent user state executable: schemas and instances are LLM-generated Python that evolves with the user.

The closest persistent alternative is LangMem~\citep{langmem2025}, which lets agents revise long-term natural-language instructions. UaC differs by storing typed state that an interpreter can query rather than instructions an LLM must reinterpret at read time. CoCoGen~\citep{madaan2022cocogen} likewise shows that code can improve structured generation, while Code as Policies and VeraFi~\citep{liang2023codeaspolicies,akinfaderin2025verafi} generate executable policies or machine-checkable constraints. Those artifacts are typically task-specific; UaC maintains generated schemas and instances as an evolving user-memory view. Learned memory policies such as Memory-R1 and AgeMem~\citep{yan2025memoryr1,yu2026agemem} optimize operations over memory APIs, a complementary direction that could train UaC's file-level operations.

Generated code has improved arithmetic and logical reasoning in PAL and Program-of-Thoughts~\citep{gao2023pal,chen2023pot}, agent actions in CodeAct~\citep{wang2024codeact}, and reusable skills in Voyager~\citep{wang2024voyager}. Those artifacts generally solve a task or encode a policy; UaC applies their determinism and verifiability to long-lived user state. Existing benchmarks test long-horizon recall~\citep{maharana2024locomo,wu2025longmemeval}; our analytical benchmark complements them with deterministically scored aggregation over collections of user records.


\section{Methodology: The User as Code Architecture}
\label{sec:method}

\begin{figure*}[htbp]
\centering
\includegraphics[width=0.98\textwidth]{figures/architecture.pdf}
\caption{Evaluated UaC architecture. Session facts are appended before periodic bounded structuring into typed state. Answering combines the typed state, retrieved facts, and raw-archive excerpts; analytical cases expose state to a Python REPL.}
\label{fig:architecture}
\end{figure*}

Extraction (Section~\ref{sec:extraction}) converts raw multi-session conversation into an append-only fact source and a periodically generated typed-code view. Retrieval and use (Section~\ref{sec:retrieval-use}) answers questions through the code, fact, and archive channels. We first show the generated state (Section~\ref{sec:code-example}), then describe the write and read paths; cross-cutting design principles follow in Section~\ref{sec:principles}.

\subsection{What ``User as Code'' Looks Like}
\label{sec:code-example}

Each generated code view contains typed state organized by domain. For example, a travel module may store a \texttt{PassportInfo} object and dated \texttt{Trip} records. The schema is generated by the LLM rather than fixed by a human. Because \texttt{trips} is an enumerable typed collection, the opening questions become Python filters---by \texttt{region} for Europe and by \texttt{departure\_date.year} for 2025. Completeness still depends on the bounded structuring input and the generated output, so the fact and archive channels remain part of the evaluated system.

\par\medskip
\noindent\begin{minipage}{\columnwidth}
\begin{lstlisting}[basicstyle=\footnotesize\ttfamily]
from datetime import date
from .schema import PassportInfo, Trip

passport = PassportInfo(
    number="AB1234567", country="US",
    issue_date=date(2015, 2, 18),
    expiry_date=date(2025, 2, 18),
    full_name="Jessica Marie Thompson",
)

trips = [
    Trip(
      destination="Paris",
      country="FR", region="Europe",
      departure_date=date(2024, 6, 12),
      return_date=date(2024, 6, 20),
      flight_number="AF-009",
      is_international=True),
    Trip(
      destination="Lisbon",
      country="PT", region="Europe",
      departure_date=date(2025, 3, 10),
      return_date=date(2025, 3, 17),
      flight_number="TP-218",
      is_international=True),
    # ... 98 additional trip records ...
]
\end{lstlisting}
\captionof{figure}{Excerpt from \texttt{domains/travel/state.py} of a UaC user project. Generated automatically from the append-only fact list.}
\label{fig:generated-state}
\label{lst:travel-state}
\end{minipage}

\subsection{Extraction: Memorize, then Structure}
\label{sec:extraction}

The write path separates a durable append-only fact source from a generated typed-code view.

\subsubsection{Phase 1: Memorize (per session, append-only)}

An LLM extracts every individual fact as a flat string from each session. Facts are appended to a running list---never overwritten, never deleted---and relative dates are resolved against the session timestamp. This produces roughly 50--75 facts/session; our run extracts 1{,}419 facts from the 19-session \texttt{conv-30}.\footnote{Phase~1 is mildly stochastic; an independent audit run reports 1{,}433 facts.} Each fact is indexed in ChromaDB; the raw conversation is also indexed as a fallback for direct-quote queries.

\subsubsection{Phase 2: Structure (periodic, bounded input)}

An LLM generates structured Python from the serialized fact list, organizing the visible facts into typed dataclasses: \texttt{date()} for dates, typed lists for collections, and \texttt{notes: list[str]} for hard-to-type facts. The evaluated \texttt{UserAsCodeV5.structure()} implementation truncates that serialization to the first 30{,}000 characters before the Phase~2 call. Consequently, the typed code is a bounded prefix-derived view rather than a structure of the complete LOCOMO fact corpus. The append-only fact index and raw archive retain the broader evidence and remain available at answer time. Hierarchical or incremental structuring is required to remove this ceiling.

\subsection{Retrieval and Use}
\label{sec:retrieval-use}

At answer time, UaC treats the typed state as one source and backs it with the fact and archive indices for coverage. In the analytical benchmark, a Python REPL executes queries over the typed records.

\subsubsection{Multi-Strategy Retrieval}
\label{sec:retrieval}

At query time, retrieval composes three channels rather than picking one. The two vector channels are standard retrieval-augmented generation~\citep{lewis2020rag} over the user's own history; the channel unique to UaC is the structured-code state, which the others backstop. Each channel addresses a different failure mode of the others: the structured-code channel can return a typed object but only for facts the structuring step has captured; the fact-vector channel covers the long tail of facts that did not make it into the typed schema; and the raw-archive channel preserves the exact conversational phrasing for queries that hinge on wording.

\textbf{(1)~Structured code state.} The structured code is included in the answer prompt, truncated to 6{,}000 characters. The agent can read typed dataclass instances without a separate parse step.

\textbf{(2)~Fact-vector retrieval.} A ChromaDB collection over the append-only fact list (one fact per record, $\sim$50 facts/session) is queried by cosine similarity against the question; the top 20 facts are appended. This recovers facts the structuring step compressed away or normalized to a different surface form.

\textbf{(3)~Archive retrieval.} A second ChromaDB collection holds the raw conversation chunked at session granularity; the top 10 chunks by cosine similarity are appended. Used as a last-resort fallback for direct-quote questions.

The three channels are concatenated under fixed headers (\texttt{[STATE]}, \texttt{[FACTS]}, \texttt{[ARCHIVE]}) and passed to the answer LLM with no reranking; the prompt instructs it to prefer structured state on conflicts. The leave-one-out ablation quantifies their contribution to LOCOMO recall, while the analytical benchmark separately tests code execution over enumerable state.

\subsection{Design Principles}
\label{sec:principles}

Two cross-cutting principles are evaluated directly in this paper:

\begin{enumerate}[leftmargin=*]
\item \textbf{Durable Sources and a Generated View.} Append-only facts and the raw archive remain available alongside the bounded typed-code view. The retrieval-channel ablation in Section~\ref{sec:channel-ablation} evaluates the three answer-time sources.
\item \textbf{Executable Analytical Representation.} Typed collections can be enumerated with ordinary Python. Section~\ref{sec:analytical} compares that interface with raw-record execution and retrieval-only systems.
\end{enumerate}

Three further principles guide production deployment but are not isolated by the experiments:

\begin{enumerate}[leftmargin=*,start=3]
\item \textbf{Modularity by Life Domain.} Memory partitioned into independent domain packages (e.g., \texttt{travel/}, \texttt{health/}, \texttt{finance/}). Limits cross-domain leakage and supports selective loading at scale.
\item \textbf{Progressive Disclosure.} Compact manifest ($\sim$200--300 tokens, always loaded) with on-demand domain loading. Keeps the prompt budget bounded as the user state grows.
\item \textbf{Agent-Native File System.} User project is a directory in the agent's workspace---no custom memory API needed.
\end{enumerate}


\section{Experiments and Evaluation}
\label{sec:experiments}

\subsection{Setup}

\textbf{Full LOCOMO protocol.}\label{sec:full-locomo-protocol} We evaluate all 1{,}986 annotations across 10 LOCOMO conversations~\citep{maharana2024locomo}: 1{,}540 answer-bearing questions (categories 1--4) and 446 adversarial questions (category~5). Each of seven systems is run through Krill's OpenAI-compatible endpoint (\texttt{https://api.krill-ai.net/v1}) with \texttt{gpt-5.6-luna} and \texttt{gemini-3-flash-preview}; the selected backbone handles applicable write, answer, and judge calls. Gemini uses the exact User-Agent \texttt{GeminiCLI/0.28.0/}\allowbreak\texttt{gemini-3-flash-preview}\allowbreak\texttt{ (darwin; arm64; terminal)}. Krill exposes no \texttt{thinking\_budget}, so neither suite transmits one.

\textbf{Scoring.} Categories 1--4 use LOCOMO's official category-aware token F1 and a binary same-backbone LLM judge~\citep{zheng2023mtbench} that accepts semantically equivalent answers. Category~5 uses the deterministic refusal criterion and is never judged. Judge accuracy supports within-panel comparisons; cross-panel differences also reflect judge calibration. Token F1 and refusal accuracy lack that judge confound.

\textbf{Baselines and other benchmarks.} Five memory systems are compared with a Full-Context reference. Mem0~\citep{chhikara2025mem0} (mem0ai 1.0.5) and A-MEM~\citep{xu2025amem} (agentic-memory 0.0.1) use their libraries with the selected Krill backbone in full LOCOMO. MemMachine~\citep{wang2026memmachine}, Hindsight~\citep{latimer2025hindsight}, and EverMemOS~\citep{hu2026evermemos} are same-backbone reimplementations on shared ChromaDB/\texttt{all-MiniLM-L6-v2}, not native-stack reproductions. LongMemEval retains its original direct-Google Gemini~3 Flash setup. The analytical artifacts use the same Gemini~3 Flash Preview model; 99 cases are from the original direct-Google run, while one year-ambiguous item was corrected and rerun for all five systems through Krill with the Gemini CLI User-Agent before aggregates were recomputed.

\textbf{Provider-safety handling.} Luna refused one benign Mem0 write about four dogs/veterinary checkups; only that turn received a documented meaning-preserving paraphrase after session splitting. It also refused four systems' judge calls for one benign book-comparison QA; only the retry prompt used deterministic domain-neutral terms. Stored questions, golds, predictions, and token-F1 paths are unchanged; all four judge decisions are WRONG and artifact-tagged. Unknown refusals fail the build.

\subsection{Standard Benchmarks}

\input{body_tables}


\textbf{Full LOCOMO (Table~\ref{tab:locomo}, $n{=}1{,}986$).} UaC has the highest observed persistent-system judge accuracy in both panels: 78.8\% with Luna (5.2pp above MemMachine; 3.5pp below Full Context) and 80.6\% with Gemini (5.7pp above MemMachine; 4.2pp below Full Context). Its token F1 (39.4\%/46.9\%) trails MemMachine and Full Context. Refusal is 64.3\% with Luna (behind Hindsight, EverMemOS, and Mem0) and 95.7\% with Gemini (all systems: 95.7--98.7\%). The divergence motivates separate lexical, semantic-judge, and refusal metrics rather than one LOCOMO accuracy.

\textbf{LongMemEval (Table~\ref{tab:longmemeval}, $n{=}500$).} The top three systems are within 2.4pp: Full~Context reaches 85.4\%, MemMachine 84.8\%, and UaC 83.0\%. UaC is highest on knowledge update (97\%) and single-session preference (83\%), while MemMachine is higher on multi-session (88\%) and temporal reasoning (69\%). These per-type differences are descriptive; the artifacts do not isolate a component or error mechanism that explains them. In particular, we do not attribute the rows to typed dates, timestamp loss, or contextual expansion without a controlled lesion study. The Mem0, A-MEM, and reimplementation numbers characterize this controlled stack rather than each system's strongest published deployment.

\subsection{Analytical Inference}
\label{sec:analytical}

Beyond recall, agents may need \emph{aggregate inference over the user's records}---``how many contacts did I meet during undergrad'', ``average dining spend in 2024 by cuisine'', or ``did my workout count increase from Q1 to Q2''. Counts, group-bys, time-window filters, and joins are one-line Python over typed objects but can be lossy under top-$k$ retrieval, so this is where code-readable collections should help.

\textbf{Benchmark construction.} 100 cases over 10 record types (trips, contacts, meals, transactions, sleep, workouts, books, medical visits, meetings, purchases), 10 cases each covering 10 question patterns (count, sum, average, group-by, time-window filter, multi-condition filter, top-$k$, min/max, threshold, trend). Per-case record counts span $N \in \{20, 50, 100, 200, 500\}$. Scoring is deterministic with type-specific normalization: exact integer and collection checks, 1\%/0.01 tolerance for floats, and case-insensitive string containment; no LLM judge is used. One sleep-trend item originally omitted the year even though its gold computation used 2024; we corrected it to ask explicitly about Q1 to Q2 of 2024 and reran that item for all five systems.

\textbf{Systems.} Five systems, identical cases, Gemini~3 Flash throughout: Full~Context (in-head reasoning over raw JSON), Full~Context+REPL (same data plus \texttt{python}/\texttt{read\_file} tools), UaC (records structured into typed Python, exposed via REPL), MemMachine (top-20 sentence retrieval with contextual expansion), Mem0 (flat fact extraction, top-20).

\begin{table}[t]
\centering
\caption{Deterministically scored analytical accuracy (\%) on 100 cases. FC+REPL executes over raw records; UaC executes over typed state.}
\label{tab:analytical}
\scriptsize
\setlength{\tabcolsep}{1.5pt}
\begin{tabular}{@{}lrrrrrr@{}}
\toprule
\textbf{System} & \textbf{All} & $N{=}20$ & $N{=}50$ & $N{=}100$ & $N{=}200$ & $N{=}500$ \\
\midrule
FC + Python REPL & 100.0 & 100 & 100 & 100 & 100 & 100 \\
UaC + Python REPL & 100.0 & 100 & 100 & 100 & 100 & 100 \\
Full Context & 94.0 & 100 & 90 & 100 & 90 & 90 \\
MemMachine & 43.0 & 100 & 55 & 20 & 15 & 25 \\
Mem0 & 6.0 & 5 & 10 & 0 & 0 & 15 \\
\bottomrule
\end{tabular}
\end{table}

\begin{figure}[t]
\begin{lstlisting}[basicstyle=\footnotesize\ttfamily]
# N=100 benchmark case: count trips in H1 2024
start = date(2024, 1, 1)
end = date(2024, 6, 30)
trips_in_range = [
    trip for trip in data
    if start <= trip.date <= end
]
print(len(trips_in_range))
# stdout: 16  (gold: 16)
\end{lstlisting}
\caption{A representative aggregation case from the experimental data. UaC enumerates all 100 typed trip records and returns the exact count, 16. On the same question, MemMachine retrieves 61 records and answers 9; Mem0 retrieves 8 and answers 5.}
\label{fig:aggregation-example}
\end{figure}

The results (Table~\ref{tab:analytical}, Figures~\ref{fig:aggregation-example} and~\ref{fig:analytical-scaling}) split by access interface. MemMachine drops from 100\% at $N{=}20$ to 15\% at $N{=}200$, and Mem0 remains at 0--15\% for $N\geq 50$. Full~Context without tools ranges from 90--100\%. FC+REPL and UaC+REPL are both 100\% across every value of $N$. After the year-qualified rerun, the former UaC miss is no longer an analytical error: the corrected question, gold, and UaC prediction are all \texttt{increase}.

\begin{figure}[htbp]
\centering
\includegraphics[width=\columnwidth]{figures/analytical_scaling.pdf}
\caption{Analytical-inference accuracy as record count $N$ grows (log-scaled horizontal axis; 20 cases per value of $N$).}
\label{fig:analytical-scaling}
\end{figure}

The divide is between representations a code tool can enumerate (UaC and FC+REPL) and systems limited to retrieved subsets in this harness (Mem0 and MemMachine). The former remain accurate as $N$ grows; the latter do not. This synthetic benchmark deliberately isolates read-side representation and tool access: its inputs are already schema-clean and therefore do not test UaC's conversation-to-structure conversion. UaC matches the JSON+REPL reference here, establishing the value of an enumerable interface rather than an advantage of Python syntax itself.

\subsection{Retrieval-Channel Ablation}
\label{sec:channel-ablation}

To isolate the three retrieval channels, we evaluate leave-one-out variants on the same five-conversation, 300-question LOCOMO subset (Table~\ref{tab:channel-ablation}).

\begin{table}[t]
\centering
\caption{Retrieval-channel ablation on LOCOMO ($n=300$). $p$ is the paired McNemar test against Full.}
\label{tab:channel-ablation}
\small
\begin{tabular}{@{}lccc@{}}
\toprule
Configuration & Accuracy & $\Delta$ & $p$ \\
\midrule
Full       & 78.0\% & ---     & --- \\
$-$STATE   & 76.7\% & $-$1.3pp & .67 \\
$-$FACTS   & 68.7\% & $-$9.3pp & .0008 \\
$-$ARCHIVE & 70.7\% & $-$7.3pp & .008 \\
\bottomrule
\end{tabular}
\end{table}

Removing FACTS or ARCHIVE lowers accuracy by 9.3pp and 7.3pp, respectively, whereas removing STATE changes accuracy by only $-$1.3pp in this sample. Thus conventional recall primarily comes from the text channels; the analytical benchmark separately evaluates executable access to typed state.

\subsection{Modularity and Progressive Disclosure}
\label{sec:modularity}

We compare three loading strategies on 100 single-domain questions over a 10-domain, 500-record state: always inlining the full state (Monolithic), loading one domain on demand (Modular), or routing through one-line domain summaries (Manifest).

\begin{table}[t]
\centering
\caption{Loading-strategy ablation ($n=100$).}
\label{tab:modularity}
\footnotesize
\begin{tabular}{@{}lrrr@{}}
\toprule
Strategy & Accuracy & Prompt tokens & Cost \\
\midrule
Monolithic & 97.0\% & 10,155,765 & \$3.64 \\
Modular & \textbf{98.0\%} & \textbf{426,856} & \textbf{\$0.25} \\
Manifest & 87.0\% & 624,922 & \$0.38 \\
\bottomrule
\end{tabular}
\end{table}

Modular loading preserves accuracy while reducing prompt tokens 23.8$\times$ and cost 14.9$\times$ relative to Monolithic. The cost ratio is computed from the unrounded totals (\$3.638797/\$0.2446868), not the two-decimal values displayed in Table~\ref{tab:modularity}. Manifest routing is 10pp below Modular in this run; inspection of the stored traces attributes its errors to routing decisions based on the one-line summaries.

\section{Discussion}

UaC changes the access interface rather than uniformly improving every recall metric. Fact vectors and raw archives remain effective for surface details, while typed state enables complete-set computation. We therefore report full-LOCOMO token F1, same-backbone judge accuracy, and adversarial refusal separately rather than collapsing them into one score. Judge comparisons are meaningful within a model panel; comparisons across the Luna and Gemini panels also change the judge and should not be interpreted as an isolated backbone effect. The channel ablation shows that structured state changes conventional QA only slightly in this sample, whereas the analytical benchmark demonstrates the value of a code-readable, enumerable representation. Retrieval mechanisms remain complementary.

The approach has four main limitations. First, evaluated Phase~2 structuring reads only the first 30{,}000 characters of the serialized facts, so the typed state is not a complete view of long LOCOMO histories; fact and archive retrieval partly backstop this limitation, but hierarchical or incremental structuring is needed. Second, generated Python may be incomplete or incorrect and requires validation plus sandboxed execution. Third, the analytical benchmark is synthetic and starts from schema-clean records, so it does not measure conversation-to-structure errors. Finally, our controlled baseline implementations simplify some published retrieval stacks. The full LOCOMO judge is also the answer backbone within each panel; an earlier cross-family audit covers only the legacy 600-question subset (the first 60 QAs per conversation) and does not remove this limitation for the full runs. Larger real-world evaluations, independent full-scale judging, and native baseline reproductions are needed.

\section{Conclusion}

User as Code represents a generated view of persistent user memory as typed state while retaining append-only facts and raw conversation as separate evidence channels. Full LOCOMO shows metric-specific recall tradeoffs, and the corrected analytical benchmark shows that both typed-state and raw-record REPL interfaces can answer all 100 aggregate queries exactly. The result is evidence for enumerable memory interfaces: how an agent records a user determines not only what it can retrieve, but what it can compute.

\textbf{AI assistance disclosure.} Generative AI tools were used for language editing, code assistance, and manuscript formatting; the authors verified all research claims, analyses, and final text.

% Extended analyses, implementation details, and case studies are omitted from
% the conference manuscript and remain available in the full version.