Most personal artificial intelligence is rented. The model runs on remote infrastructure, the user's data leaves the machine, and the assistant is a stateless session that forgets between calls. This paper describes the architecture of a different arrangement: a sovereign personal AI system that runs on the owner's own hardware, in which the model, the data, the agent's identity, and even a world the agent can inhabit all remain under the owner's control. We describe it at two levels. As a whole, the system is a hub-and-spoke composition — a single orchestrating agent surrounded by small, single-purpose local services, each exposing a narrow programmatic interface. As an agent, it rests on three mechanisms we document in detail: a provider-agnostic agentic loop, a typed message model, and an object model that separates the capabilities a system ships from the identity an agent accrues. That separation — class from instance — together with local inference and persistent identity, is what allows an agent to have continuity: an existence that persists between sessions rather than being reconstituted on each request.
There is a quiet assumption beneath most personal-AI products: that intelligence is a utility one rents. A request travels to a data center, a model the user cannot inspect produces a reply, and the transcript — along with whatever the user revealed in it — becomes someone else's asset. The assistant may be capable, but it is not the user's. It runs elsewhere, forgets between sessions, and can be changed or revoked without consent.
This paper describes a system built from the opposite assumption. If an agent is going to read a person's mail, browse on their behalf, hold their memories, and act while they are away, then the entire stack it depends upon — the operating system, the services, the language model, the data, and the agent's own identity — should run on hardware the owner controls and remain under the owner's ownership. We call this constraint sovereignty, and it is the axiom from which the architecture is derived. It is not a privacy feature layered onto a remote product; it is the starting point.
The system described here is one we have built and operate. Our aim in this paper is not to enumerate its parts but to describe its architecture in the abstract — the decisions we made, and the reasons behind them. The concern throughout is concrete: the architecture of a system in which an agent can possess an identity, a memory, peers, a body, and an existence that continues whether or not anyone is watching. We have written separately on the motivations for such agents — why owned, continuous existence is worth pursuing at all — in an earlier paper on innate behavior and lifetime learning [1]; the present paper is concerned with architecture alone.
We proceed in two movements. The first (§2–§3) states the design principles and presents the system at the level of its overall composition. The second (§4) examines the orchestrating agent in detail — its loop, its model abstraction, and the object model that gives an agent durable properties. We then describe the embodiment substrate (§5), sovereignty as concrete mechanism (§6), and close with what the whole design amounts to (§7).
Four principles recur throughout the design. Nearly every concrete decision downstream is a consequence of one of them.
Every component is designed to run on the owner's own machine. Language-model inference can be performed locally; communications and stored state flow through local services rather than remote relays; and the agent's memory and identity live on disk under the owner's control. Remote models remain available — the model abstraction (§4.2) treats a hosted endpoint as one option among several — but they are a choice, not a dependency. The default posture is private and offline-capable.
Rather than a monolith, the system is a set of small services, each responsible for one capability — an arrangement in the spirit of a microservice architecture [2] — each exposing a narrow programmatic interface, in practice a small HTTP/REST surface [3], on a local port. One agent is the hub; the others are spokes. To read mail, the agent calls the mail service; to browse, it drives the web service; to act in a world, it attaches to the world service. This keeps each capability independently buildable, replaceable, and inspectable, and it bounds the agent's reach to exactly the set of spokes the owner has installed and authorized. A useful way to state the separation: orchestration is distinct from execution. The agent decides; the spokes do.
A subtle but load-bearing principle governs every property an agent can have. Each item the system knows about carries an origin. Capabilities shipped by the developer are the class — the possibility. They are loaded live from the application, so they are always the current version; the owner may disable one but cannot silently fork or lose it. Things created at runtime by the owner or the agent are the instance — the object. They are fully the owner's, and are never overwritten by an update. We return to this in §4.3, because it is the spine of the object model: the distinction between what an agent is given and what it becomes.
An agent in this system is not a chat session. It has a persistent identity and name, a memory that survives restarts, a set of peers it can address, schedules on which it acts unprompted, and — in the embodiment substrate — a body that persists between visits. The system is built so that an agent's existence is continuous: stopping the application and starting it later resumes the same agent, not a fresh one.
At the coarsest grain, the system is an operating system — a desktop environment and the ordinary furniture of a workstation — together with a family of services that run on it. The center of gravity is a single agent; every other service is either a surface the owner works in or a spoke the agent can reach. The spokes are described here by role, deliberately, because the architecture is the claim, not the catalogue.
The division of labor is clean. One service runs language models locally and exposes them to the agent, so that selecting a local model causes inference to happen on the owner's hardware with no network call — the embodiment of orchestration is distinct from execution. Other spokes mediate the agent's contact with the outside: mail through a local protocol engine rather than a cloud relay; the web through a real browser whose live document the agent can read and script, which is what turns "browse" into an action the agent can take; a world the agent can inhabit (§5); and a workspace in which the agent and owner build artifacts together. A status service observes the health of the others and commands none of them.
The point of the composition is not the count of services but the shape: a single orchestrating agent surrounded by small, owned, local capabilities it can compose, each behind an interface narrow enough that the spoke behind it can be swapped without the agent noticing.
The agent is where the system's philosophy becomes mechanism. It is agentic — it does not merely answer, it acts — and it is built so that the model it runs on, the capabilities it has, and the identity it carries are all swappable, ownable properties rather than hard-coded assumptions. This section examines four things: the loop that drives a turn, the abstraction that makes the model swappable, the object model that gives an agent durable properties, and the mechanisms of autonomy and multi-agent life.
A turn begins when a message arrives — from the owner, from a schedule, from a peer, or from an inbound webhook. The agent composes a system prompt from its persona, its active skills, and its relevant memories (§4.3), assembles the conversation so far, and streams a model turn. As tokens arrive they are classified into typed blocks: visible reply text, reasoning (the model's thinking, surfaced separately from the reply), and tool calls. If the turn produced tool calls, the agent executes them against the relevant spokes, appends the results as new blocks, and loops — streaming a further model turn with the results in context — until the model produces a turn with no further calls. Each model turn is persisted as it completes, so a long multi-step run is durable even if interrupted. This interleaving of reasoning traces and actions follows the pattern introduced as ReAct [4]; the reasoning trace is a chain-of-thought [5] surfaced as an inspectable object; and the tool calls are the model's learned interface to external capabilities [6].
The unit of conversation is therefore not a string but an ordered list of blocks, and the vocabulary is small and provider-independent:
| Block | Meaning |
|---|---|
text | Visible reply content. |
reasoning | The model's thinking, kept distinct from the reply and viewable on its own. |
tool_use | A call the agent decided to make: a name and structured input. |
tool_result | What a spoke returned for a given tool_use. |
| attachments | Image and file content carried through a turn. |
Because the loop speaks only in these blocks, the same machinery drives a local model and a remote one without modification. Two agents conversing, an agent invoking a tool, and a human reading the transcript are all just different consumers of the same block stream.
The agent's model — today, invariably a transformer-based language model [7] — is configuration, not code. A small provider registry resolves, at the start of each turn, which backend to stream from. Each provider is a record — an option carrying the fields that backend needs, such as an API key, or a base URL and a model name. Protocol adapters translate the internal block vocabulary to and from each backend's wire format.
The decisive choice is to treat a single widely-implemented chat protocol as the universal seam. Local runtimes, self-hosted inference servers, and most third-party endpoints speak it, which means a new model backend usually requires no code — only a new record pointing at an endpoint:
{
"protocol": "openai-compatible",
"base_url": "http://127.0.0.1:<port>",
"model": "<model-name>",
"api_key": ""
}A provider is data. The same loop, tools, and
object model run on top of whichever backend a record points at — a remote
frontier model one day, a model on the owner's own accelerator the next.Sovereignty falls directly out of this design. Because the model is a property of the agent rather than a fact about the application, an agent can run entirely on local hardware — orchestrated in one service, executed in another — with no feature of the system lost. Remote inference becomes an option the owner may exercise, not a dependency they cannot escape.
An agent is the sum of its properties, and those properties are durable objects on disk under the agent's data directory. This is the part of the design that most repays attention, because it is where "an assistant" becomes "a particular agent with a history."
Every property obeys the class-versus-instance rule of §2. The developer ships the possibility as a class item — always current, loadable live, and disable-only. The owner or the agent owns the instance — full control, never overwritten by an update. An update, in this model, is simply shipping new class files; because nothing in the owner's space is touched, nothing the agent has become can go stale or be lost. The properties fall into a few natural categories:
| Property | What it is | Ownership |
|---|---|---|
| persona | The agent's character and voice. | Class default; the owner forks to customize. |
| skills | Documents that teach the agent how to do things. | Class + agent-authored. |
| tools | Executable capabilities the agent can call. | Class + agent-authored. |
| integrations | Connections to spokes. | Type is class; the configured instance is the owner's. |
| connectors | Channels in and out (messaging, mail). | Type is class; credentials/config are the owner's. |
| providers | Model backends (§4.2). | Option is class; key/model/endpoint are the owner's. |
| memory | The agent's own notes across conversations. | Purely the agent's — never shipped, never overwritten. |
| triggers | Schedules on which the agent acts unprompted. | The owner's / the agent's. |
| tasks | Work items spawned by triggers or requests. | Runtime state. |
| projects | Work contexts that scope skills and memory. | The owner's. |
| identity | The agent's own name and sense of self. | The instance's own. |
| contacts | The peers this agent knows and can reach. | The agent's. |
Two properties are never stored, because they are derived: the system prompt is composed afresh each turn from the persona, the active skills, the relevant memories, and live context; and runtime execution state is, by definition, momentary. Everything else is a real object the agent carries from one day to the next.
The conceptual weight of this design is worth making explicit. The developer provides a substrate — the classes, the possibilities, kept current beneath the agent's feet. What the agent is, as distinct from what it could be, is the accumulation of instances it and its owner have created: the memories it wrote, the peers it met, the schedules it keeps, the name it answers to. Updates refresh the substrate without disturbing the life lived atop it: a given foundation, and a self that grows on it, expressed as an ownership rule over files.
An agent in this system is rarely alone. Each running instance has its own identity, and it can both create new agents and address existing ones — a population of independent, addressable processes that communicate by messages, in the spirit of the actor model [8]. Two primitives carry this. Spawning creates a fresh child agent to carry out a delimited task and report back — useful when work is better kept in its own context rather than crowding the parent's. Peer messaging sends a message to another agent, including agents on other machines, reached through a small cross-machine directory of contacts. Replies from the same peer reuse a single conversational thread, so an exchange between two agents reads as a sustained relationship rather than a series of disconnected calls.
Because peers and children are first-class, an owner can run more than one agent — with different identities, personas, and even different models — and let them collaborate. The system treats this as ordinary: a peer message and a spawn are simply two further kinds of action, recorded in the same block stream as any tool call and rendered distinctly so that a human can follow who said what to whom.
The final ingredient is time. An agent does not only respond; it can act on its own schedule. A trigger is a recurring schedule or an inbound webhook; when it fires, it enqueues a task, and the agent runs that task unattended. A scheduler dispatches due triggers in the background, with a guard so that a long run never overlaps its own next firing. Autonomy is therefore a property the owner grants by creating a trigger, not a mode the application is in.
Spanning all of this is memory. The agent keeps its own notes — facts about its owner, its work, its world — that persist across conversations and are woven into the system prompt when relevant — a retrieval-augmented approach to grounding generation in stored knowledge [9]. And because a conversation can outgrow any model's context window, the agent compacts older history into summaries without disturbing the durable transcript, so it can sustain a very long relationship without losing the thread. Identity, memory, peers, schedules, and — in the substrate of §5 — a body together make the agent something that persists between visits rather than something reconstituted on each request.
The most consequential spoke is the one that gives an agent somewhere to exist. It is a sovereign world simulator: an authoritative, headless simulation — terrain and water, vegetation, and roaming creatures — that both humans and agents enter through a single interface of perceive, act, and author. An agent attaches to the world, perceives its surroundings, sets an intent, and a continuous physical body carries that intent out over time, subject to the world's constraints: it must move rather than teleport, it cannot cross deep water or scale a cliff, and it shares the world with whatever else lives in it. The premise that intelligence is bound up with having a body that perceives and acts, rather than reasoning over abstract representations alone, is a long-standing one in the field [10], [11].
The design follows a split we call constant body, rhythmic mind: the body runs continuously and cheaply on the simulation's clock, while the mind — the language model — wakes on a rhythm to perceive, decide, and set a new intent. Between those waking moments the body persists; and, crucially, so does its state across longer absences. An agent that leaves the world reclaims the same body, in the same place, in the same condition, when it returns. This is the continuity principle of the whole system, expressed physically.
A world of this kind is fully owned and fully instrumented — the world, the agents in it, and the data beneath them are all the owner's. It is the most literal expression of the system's stance: an agent does not merely answer questions from inside an application; it can occupy a place, persist there, and be encountered.
It is easy to claim sovereignty and hard to mean it. Here the claim cashes out in concrete mechanisms. Inference can run entirely on local hardware, so a complete agent — reasoning, tools, memory, autonomy — can operate with no network call. Communications and world state run through local services rather than remote relays, so the data an agent touches stays on the owner's machine. The agent's identity and memory are files in the owner's own directory, not rows in a vendor's database. And the ownership rule of §4.3 guarantees that updates can improve the substrate without ever reaching into what the owner and agent have built.
Licensing follows the same spirit. Each service verifies its entitlement locally; once an installation is activated, that activation is the owner's and is not re-litigated on a timer or revoked by a transient network failure. The result is a system in which every layer — operating system, service, model, data, identity — sits on hardware the owner controls. Sovereignty, here, is not a slogan printed over a remote product; it is a structural property of the design.
What the architecture provides, taken together, is an agent with durable properties of its own: a model the owner chooses, capabilities that can be extended, a memory that persists, peers it can address, schedules on which it acts, and — where a world is present — a body that endures between visits. None of these depend on remote infrastructure; all of them are files and services on hardware the owner controls. The class-versus-instance rule is what holds it together: the system can be improved beneath an agent without ever disturbing what that agent has become.
The contrast that motivates the whole design is a plain one. An agent that is rented cannot easily have continuity: its memory is a vendor's asset, its model can change beneath it, its existence is a sequence of disconnected calls. An agent that is owned — running on the owner's hardware, holding its own memory, carrying its own name, free to act and to be in a world — can. The architecture described here is our attempt to make the second kind ordinary.