Embodied AI Companion

An experimental agent runtime that gives an AI character persistent presence inside a private Final Fantasy XI server: login state, movement, healing, recovery, dialogue, memory, and session continuity.

This project started from a simple irritation: most AI companions feel like a window, not a presence. You open a tab, type something, get a response, and close it. Nothing exists between interactions.

Julia is an attempt to make that presence more concrete. She is a Mithra White Mage on a private LandSandBoat Final Fantasy XI server — fully geared, with a name, a job, and an authored personality. She logs in, follows, heals in party, speaks through linkshell and emote channels, and keeps her own gear and spells current automatically.

The private server is part of the architecture, not just a setting. It handles the recovery states that would otherwise consume most of the engineering — warping back when stuck, reviving after death, snapping to the right zone — so the interesting work can happen higher up: presence, prose, and continuity over time.

How the system is layered

The architecture separates presence from cognition on purpose. Presence — following, healing, and responding to proximity events — is fully deterministic. A Python process watches the Windower event stream and writes commands back through a file bridge on every poll, with no model involved. Julia can follow, heal, and recover through a session even if the API is unavailable.

The language model handles dialogue only: linkshell and emote prose routed through a provider-neutral model router. Live social output runs on OpenAI; compression and reflection are routed to Claude. The rest of the runtime is dumb apps.

The live sidecar stack is narrow by design: presence handles movement and healing, recorder captures event evidence and social turns, session-chat drives the prose output, character manages gear and spell provisioning, and supervisor and relog keep the headless client alive and logged in. Each sidecar has one job. Shared state lives in SQLite.

How continuity works

Session history lives in human-readable Markdown files rather than opaque database rows. The recorder captures meaningful events and Julia's visible social output into a running session log. After enough genuine social turns, a compression pass summarizes the batch into a readable prose summary. The next session opens with that summary as context — so Julia carries forward what happened rather than starting cold every time.

The instantiation prompt assembles a tiered context packet at session start: last session summary for immediate pickup, a roll-up of recent sessions for the short arc, and a meta-summary of everything for the long view. The prose preprocessor converts that into a compact, auditable brief before it reaches the model. Raw database state never goes directly into a prompt.

Where it is now

The presence loop is working: Julia logs in, follows, heals, and recovers automatically when stuck, lost, or killed. The session-chat controller routes linkshell and emote prose through the model router. The recorder captures events and social turns. The character sidecar provisions gear and spells on login. Current work is finishing the prose compression pipeline — moving session summaries fully onto human-readable Markdown so the context each new session opens with is clean, inspectable, and not dependent on database archaeology.

What this demonstrates

• Agent system design split across deterministic runtime behavior and model-driven language output
• Event-driven automation using Python sidecars, Windower streams, file bridges, and SQLite state
• Prompt/context architecture built from inspectable session summaries instead of opaque raw logs
• Resilient runtime design for login, recovery, provisioning, movement, healing, and session continuity
• Ability to design complex human-facing systems across UI, infrastructure, automation, memory, and behavior