Skip to content

Companion runtime

“Companion” is not marketing language in this project. It is a technical commitment that changes which parts of the system get to be load-bearing.

A companion is a runtime that owns a single persistent character and the relationship that character holds with each user it talks to. The character has inner state — affect, bias, continuity cues — that evolves as conversations accumulate. Output is how that inner state surfaces, not how it is computed.

A chatbot owns a single turn. It may have a scripted personality, but there is no state the next message needs to reconcile with.

An assistant owns a task. It is judged on whether the task ends correctly; the relationship does not carry forward.

An agent owns a plan. It is judged on whether the plan executes within a tool budget; the character is instrumental.

AsteronIris behaves like a companion end-to-end. The other shapes (task assistance, agentic tool use) are available inside the runtime, but they are not the product center.

What changes when the runtime is companion-shaped

Section titled “What changes when the runtime is companion-shaped”

Four parts of the system get promoted to primary:

  • Memory, because a companion must remember who it is talking to across sessions. Relationship memory, episodic memory, and semantic graphs all feed every turn, not just explicit recall commands.
  • Persona, because a companion must remain recognizably the same entity even as it adapts to different rooms, users, and moments. Persona state is durable, not re-prompted.
  • Affect, because a companion’s tone is the visible edge of an internal state topology. Affect is detected, routed through character-specific latent bias, and projected — not applied as a last-mile style filter.
  • Pre-send verification, because a companion is judged on every turn it sends. A bad turn does not just fail a task; it damages a relationship. The pre-send gate exists to protect that asymmetry.

The things many AI products put in the center, AsteronIris deliberately puts at the periphery:

  • Multi-step approval-gated plans are a tool, not the product stage.
  • Voice is a surface, not the core modality.
  • The desktop console is an operator surface, not the main way users meet the companion.
  • Tool use is governed and audited, but it is a means of keeping a conversation grounded, not a demo of agency.

The trade is honest: AsteronIris gives up “look how much this agent can do in one run” in exchange for “look how this character has stayed consistent over a month of conversation”. If the second thing does not matter to a given use case, AsteronIris is the wrong runtime.