Large Language Objects (LLOs) Overview

• Large Language Objects (LLOs) are persistent language-model systems that maintain state, memory, and identity across interactions.
• One formulation uses a live Lisp metaprogramming loop to create, evolve, and retire tools via reflective code execution, while the other endows physical objects with evolving personas.
• Both approaches emphasize secure sandboxing, dynamic tool modification, and immersive user engagement through persistent memory and ritualized interfaces.

Large Language Objects (LLOs) is a 2025 research term used for two distinct constructions centered on persistence, memory, and situated identity. In "From Tool Calling to Symbolic Thinking: LLMs in a Persistent Lisp Metaprogramming Loop" (Torre, 8 Jun 2025), an LLO is a language-model-driven agent endowed with a persistent identity and memory, operating inside a live, symbolic runtime. In "A(I)nimism: Re-enchanting the World Through AI-Mediated Object Interaction" (Mykhaylychenko et al., 29 Sep 2025), LLOs are AI-mediated, persistent object-personas that give everyday physical things a voice, memory, and evolving character through a LLM with vision coupled to a tangible, ritualized interface. In both usages, the LLO is not treated as a stateless conversational endpoint; it is a composite entity whose state persists across turns or encounters.

1. Definitional scope

The Lisp paper defines a Large Language Object as an agent that does not merely call tools, but constructs, names, invokes, inspects, evolves, and retires them over time. Its distinctive properties are persistent identity and memory; symbolic manipulation; tool definition, invocation, and evolution; reflective self-modification; and interaction with an environment through a closed-loop interaction with a persistent REPL and middleware that executes embedded code, returns observations, and updates state (Torre, 8 Jun 2025). The A(I)nimism paper defines LLOs as AI-mediated, persistent object-personas that give everyday physical things a voice, memory, and evolving character through a LLM with vision, memory-based agents, and multi-sensory feedback instantiated within a tangible portal (Mykhaylychenko et al., 29 Sep 2025).

Dimension	Lisp metaprogramming LLO	A(I)nimism LLO
Identity anchor	Persistent REPL state and tool registries	object_id established via image recognition and embedding matching
Memory substrate	Global vars, registries, logs in a live Common Lisp runtime	Mem0.ai episodic memory plus embedding database
Primary mode	Symbolic programming and metaprogramming	Object-centered ritual conversation
Environment	Persistent Common Lisp REPL, e.g. SBCL	Physical portal with camera, audio, LED, and cloud APIs
Core objective	Tool creation, evolution, and reflective programming	Persona continuity, empathy, wonder, and reflection

The shared terminology does not imply a single ontology of "object." One paper uses "object" to denote a persistent symbolic agent in a live runtime; the other uses it for a persistent, embodied object-persona attached to a specific physical thing. This suggests a common emphasis on persistence, identity, and accumulated state rather than a single implementation template.

2. Persistent symbolic runtime and metaprogramming loop

In the Lisp architecture, the LLM core policy and planning module produces natural language and specialized code actions by interleaving prose with <lisp>...</lisp> blocks. A stream-aware middleware monitors model output, pauses generation when such a block is detected, extracts the code, evaluates it, captures the result, and resumes generation with the result inlined. The execution substrate is a long-lived Common Lisp REPL, such as SBCL, which retains definitions, global variables, and registries across turns. Because the REPL holds state and definitions across turns and supports introspection and dynamic redefinition, the model can construct and evolve a tool ecosystem over time (Torre, 8 Jun 2025).

This architecture treats tools as first-class functions, macros, and DSLs rather than as fixed APIs. External, stateful memory structures and registries store tool name, code, metadata, versions, and usage stats. These registries support discovery, auditing, and evolution, and can themselves be reflected upon by the agent. Reflective programming mechanisms are supplied by Common Lisp facilities including fboundp, symbol-function, describe, disassemble, macroexpand, defun, and defmacro, so the agent can inspect function bindings, macro expansions, source structures, and control abstractions rather than merely calling opaque services.

The middleware parsing and interception pipeline is specified in stages. The model encloses executable code in <lisp>...</lisp>. The proxy tokenizes output and detects these tags. It then extracts s-expressions, checks them against an allowlist or denylist of packages, symbols, and system calls, and may macroexpand them for inspection before execution. Safe evaluation occurs in a restricted REPL context with timeouts, memory quotas, and side-effect guards, including bans on run-program, sb-ext:run-program, or file I/O unless explicitly permitted. Result capture includes primary value, printed output, warnings, and structured metadata such as time and tool usage. For errors, the middleware attaches the condition type and message, and the next prompt serializes the observation and registry updates so that subsequent planning can incorporate them.

The same architecture includes safety and recovery provisions. The paper emphasizes sandboxed containers, restricted packages and functions, and monitoring. Common Lisp’s condition system, especially handler-case and restart-case, is presented as a mechanism for robust error handling. Content filters and capability negotiation are also part of the design: the middleware can strip or refuse disallowed forms, while the LLO can request capabilities explicitly and the middleware can grant or deny them and record permissions.

3. Formal model, tool lifecycle, and symbolic reasoning

The Lisp paper formalizes the LLO as an interaction between dialogue state, external memory, tool registry, and environment. At step $t$, the state is defined as $S_t = (c_t, h_t, r_t)$, where $c_t$ is the current control context, $h_t$ is conversation history, and $r_t$ summarizes recent execution results. External memory is $M_t$, the tool set is $T_t$, and the persistent REPL, sandbox policies, and middleware I/O define $E$. Code emissions within <lisp> tags are modeled as actions $a_t$, selected by the policy

$$\pi(a_t \mid S_t, M_t, T_t, E) = P_{LLM}(a_t \mid prompt(S_t, M_t, T_t, E)).$$

Execution is handled by

$S_t = (c_t, h_t, r_t)$0

where $S_t = (c_t, h_t, r_t)$1 parses, validates, evaluates, and returns an observation containing value, printed output, errors or warnings, and side-effect summaries (Torre, 8 Jun 2025).

State, memory, and tools are then updated by

$S_t = (c_t, h_t, r_t)$2

If a new tool $S_t = (c_t, h_t, r_t)$3 is defined, then $S_t = (c_t, h_t, r_t)$4. If it is redefined, versioning applies through $S_t = (c_t, h_t, r_t)$5 with version $S_t = (c_t, h_t, r_t)$6. If it is retired, then $S_t = (c_t, h_t, r_t)$7. Tool creation and refinement are further governed by the net-value objective

$S_t = (c_t, h_t, r_t)$8

with creation or refinement recommended when $S_t = (c_t, h_t, r_t)$9. The paper also defines a meta-decision variable $c_t$0, with $c_t$1.

The paper supplies concrete Common Lisp examples to instantiate this lifecycle. A generated block defines *tool-registry*, register-tool, and sum-list, then registers sum-list with docstring and version metadata. Invocation through the registry yields the observation 10 on the input '(1 2 3 4). Error handling is demonstrated with handler-case, where invoking sum-list on "not-a-list" returns "Type error: ..." rather than an unhandled condition. The function is then evolved to support sequences, add a type check via typep, and process vectors by coercing to a vector and summing with a loop, after which (sum-list #(1 2 3 4)) again yields 10. Tool retirement is represented by (fmakunbound 'sum-list) together with (remhash 'sum-list *tool-registry*), returning T.

Reflective operations are equally central. The example utility fn-source uses function-lambda-expression to recover a lambda form when available, and a call-graph analyzer computes referenced symbols from source stored in the registry. The paper also uses macros to raise the reasoning level, defining a plan macro that prints plan steps and returns values. This is the basis for the paper’s central move from tool calling to symbolic thinking: tool use is relocated from a static function-calling API into a persistent, introspectable symbolic environment. The model can therefore plan over code, not just actions; manipulate symbolic structures as data and executable code; introduce reusable metaprogramming patterns and DSLs; and use reflective feedback loops to update implementations in response to performance and error signals.

4. Embodied object-personas and the portal architecture

The A(I)nimism paper defines an LLO as a composite entity bound to a physical object and formalizes it as

$c_t$2

where id is an object identifier established via image recognition and embedding matching; $c_t$3 denotes sensory inputs such as image and audio keyword detection; $c_t$4 denotes actuation channels such as LED light patterns and synthesized voice; $c_t$5 is a memory subsystem storing episodic conversational history and recognition metadata; $c_t$6 is a persona model derived from vision description and updated with memories; $c_t$7 is a two-tier conversational policy with inner thoughts and public response; and $c_t$8 is a ritual policy with triggers and states (Mykhaylychenko et al., 29 Sep 2025).

The embodied interface is a split circular portal with a central opening, whose two halves symbolize bridging worlds. One half is CNC-milled cherry wood, associated in the paper with warmth, tradition, nature, and craft. The other half is powder-printed plastic, associated with modernity and precision manufacturing. A resin-printed connector houses LEDs and acts as a transparent conduit for light and electricity linking natural and artificial materials. The symbolism is explicitly tied to Torii gates, described as Shinto thresholds between the mundane and the sacred, and to James Turrell’s light installations, associated with awe and contemplation.

The hardware stack consists of a Raspberry Pi Camera Module 3 for image capture at interaction start, an Adafruit Voice Bonnet providing a stereo mic array and speakers, a single diffused LED for visual feedback patterns, and a Raspberry Pi Zero chosen for compactness and for being adequate for image capture, keyword detection, and cloud API communication. The user physically holds or positions the portal to frame an object and then speaks ritual keywords. Audio provides the persona’s voice, and light patterns signal phases of the interaction.

The software stack centers on vision, recognition, memory, and dialogue orchestration. GPT-4 with Vision produces a natural-language description of the captured object image. The image is converted to a CLIP embedding, and similarity search over stored embeddings determines whether the object matches a known object; if not, a new object_id and embedding are stored. Mem0.ai maintains episodic conversational histories as semantic vectors and supports chronological recall and relevance-based retrieval. The keyword detector listens for “awaken” to start the request phase and “goodbye” to end the session and return the system to idle. Response generation uses two-tier prompting: inner thoughts provide a covert reasoning stream enabling proactive engagement, while public response yields outward persona speech conditioned on description, memories, and social context. Voice synthesis uses ElevenLabs eleven_turbo_v2_5, with voices tuned for warmth, familiarity, or playfulness.

The overall system is orchestrated as an event-driven loop or state machine coordinating capture, recognition, memory retrieval, persona generation, dialog, TTS, logging, and LED modes. Data stores include an embedding database for re-recognition, Mem0.ai for episodic memories, and logs containing timestamps, images, embeddings, and utterances.

5. Ritual interaction, memory continuity, and animistic framing

The interaction is organized as a ritual in three phases: request, conversation, and transformation. In the textual state diagram, the portal begins in Idle with LED off. On detecting the keyword “awaken,” it enters Request, sets the LED to bright continuous, captures an image, generates a GPT-4 Vision description, computes a CLIP embedding, and performs similarity search. If the object is matched, the system loads its object_id and profile; otherwise it creates a new object_id, generates an initial persona, and stores the embedding and description. The system then enters Conversation, marked by a soft breathing LED pattern, during which it may retrieve relevant memories from Mem0 by recency and semantic relevance, generate inner thoughts about engagement, produce a public response via TTS, and append the interaction to memory. On “goodbye,” it enters Transformation, stores a session summary, fades the LED to off, prompts reflection, and returns to Idle (Mykhaylychenko et al., 29 Sep 2025).

This ritualization is not an auxiliary interface choice; it is the paper’s primary framing device. LLOs are contrasted with general-purpose conversational endpoints, task-oriented agents, and typical IoT devices. In place of control surfaces and telemetry, the portal foregrounds a conversational, animistic persona with memory and ritual, using opacity and multi-sensory cues to invite meaning-making rather than transparency for control. The interaction is explicitly framed as sacred or special rather than utilitarian.

Object-persona persistence is anchored by recognition and memory. Persona creation for new objects is guided by GPT-4 Vision descriptions, while persistence over time is anchored to object_id and enabled by embedding-based re-recognition. Episodic records include timestamped images, embeddings, prior utterances, and session metadata, and retrieval occurs either chronologically or by semantic relevance. The paper renders these operations in concise algorithmic form:

$c_t$9

$h_t$0

$h_t$1

The paper’s examples include a figurine positioned within the portal and a plush fox whose software description is “a small plush fox with a red scarf and worn fabric on the ears.” Personas are derived from such descriptions: the worn ears may suggest age or experience, and the red scarf may suggest style or gift-history. Dialogues then explore “needs, perspectives, and relationships,” with the object speaking in the first person. The representative transcript included in the paper is explicitly illustrative and constructed from the described flow: after “awaken,” the portal initializes or retrieves the persona, and the object may say, “Hello… I am the little fox with the red scarf. I remember you from last time when you placed me under the warm lamp. What draws you here today?” This use of memory references and perspective-taking is designed to evoke empathy, wonder, and reflection.

The broader theoretical framing is animist and spiritual-HCI oriented. The paper describes animism as a relational ontology recognizing persons in non-humans, discusses Shinto cosmology in which kami inhabit natural phenomena and man-made objects, and argues that AI’s opacity invites animistic interpretation. In this framing, LLOs intentionally leverage the interpretive gap of AI to position the system as a mediator of animistic relationships with objects. A plausible implication is that the system treats agency less as a property internal to the model than as something relationally produced through ritual, memory, and embodied interaction.

6. Relation to adjacent paradigms, evaluation, and limitations

The Lisp formulation positions LLOs against several adjacent paradigms. Standard tool calling offers predefined capabilities but is static; agents cannot author their own tools or alter semantics at runtime. ReAct-style agent loops combine reasoning and acting but typically operate over external tools without persistent code-level state. Program synthesis systems synthesize code but often in batch or ephemeral contexts. Code interpreters execute code in sandboxes but usually without persistent identity or reflective registries. Agent frameworks such as LangChain and AutoGPT orchestrate calls and prompts but rely on static tools. The LLO model extends these settings by maintaining persistent definitions, versioning, reflective programming, and higher-level DSL construction (Torre, 8 Jun 2025).

The A(I)nimism formulation also defines itself by contrast. It distinguishes LLOs from general LLMs, from tool-using agents and “Large Action Models,” from typical embodied AI or IoT systems, and from chatbots or voice assistants. Here the emphasis is not task optimization or instrumentality, but object-personhood, relational and affective engagement, and persona continuity. The system is tied to one specific physical object, recognized visually, with a unique persona and memory that evolve across encounters (Mykhaylychenko et al., 29 Sep 2025).

Evaluation differs sharply between the two papers. The Lisp paper proposes evaluation considerations rather than reporting empirical benchmarks. These include reliability and correctness measured by pass rates on unit tests that the LLO generates and maintains for its tools, error rates per tool, and mean time-to-repair; sample efficiency measured through token savings and performance improvement over sessions; iterative improvement through tool versions, deltas, and regression tests; tool quality and reuse metrics grounded in $h_t$2, $h_t$3, and $h_t$4; ablations on persistence and reflectivity; and latency and throughput comparisons against standard tool-calling pipelines. By contrast, the A(I)nimism work is presented as a prototype or installation, and no formal user study, participant demographics, quantitative measures, effect sizes, p-values, formal thematic analysis, or participant quotes are reported. Its reported outcomes are design aims and qualitative goals: empathy, awe, consensual exchange, an ethic of care toward objects, blurred animate/inanimate boundaries, and reflection on life, consciousness, and the sacred.

The limitations and risks are also different. In the Lisp setting, executable generations increase attack surface, so the paper highlights security and prompt injection via code, the need for rigorous sandboxing, package isolation, capability negotiation, and auditing, and suggests static analysis and runtime guards for code blocks. Persistent environments may leak resources or accumulate unbounded state, motivating quotas, GC-aware registries, and tool retirement policies. Reflection is incomplete because not all source is recoverable post-compilation, which is why the paper recommends storing canonical s-expressions in registries and using macroexpand and structural hashes to track provenance. The paper also identifies open questions in scaling to multi-agent LLOs, including concurrency, consistency, conflict resolution, CRDTs, version control for code, and permissioned namespaces, as well as future integration of contracts, lightweight type checks, theorem provers, and static analyzers for macros and DSLs.

In the A(I)nimism setting, the authors discuss ethical concerns around anthropomorphism, attachment, quasi-spiritual relationships, idolatry, blurred symbolic versus literal belief, agency, responsibility, privacy of stored conversations, data governance, and cultural or religious sensitivities. The paper proposes safeguards including transparency about simulation and memory retention, explicit opt-in and opt-out rituals with visible closure through “goodbye,” cultural sensitivity where animistic framing could be contentious, and secure storage with minimal retention aligned with user consent. The current prototype supports single-object ritual, while future work is envisioned for multi-object and object-to-object communication.

Taken together, the two 2025 uses of the term identify a common research move: embedding language-model behavior in a persistent substrate that can accumulate history, sustain identity, and alter future interaction. One substrate is a live symbolic runtime that enables reflective metaprogramming and dynamic tool evolution; the other is a ritualized embodied interface that enables object-centered persona continuity and animistic meaning-making. This suggests that the concept of the LLO is best understood not as a single architecture, but as a family of persistent, stateful, and situated language-model systems.