Hi everyone,

I’m building Aethrion, an early alpha Elixir runtime for persistent AI characters.

Repo: GitHub - simulacre7/aethrion: A shared social layer for persistent AI characters. · GitHub

Aethrion is an experiment in modeling AI characters as deterministic social simulation entities rather than prompt-only chatbots. The target use case is a social simulation layer for narrative agents, such as games, TRPG assistants, visual-novel-like character systems, or long-running AI companion apps.

The core design principle is:

LLMs can describe what happens, but deterministic rules decide what actually changes.

For example, a character should not gain trust, store a memory, send a proactive message, or die because an LLM improvised it. Those changes should come from explicit rules over inspectable state.

A simple example:

• If the user gives Mina a flower, Mina’s affinity toward the user increases.
• Mina stores a memory about the gift.
• If Yuna observes the gift, Yuna’s jealousy and tension increase.
• If time passes and the threshold is crossed, Yuna can proactively message the user.
• If the user apologizes, Yuna can store a reconciliation memory and regain trust.

The same idea could apply to other narrative rules too, such as “if health reaches zero, the character dies” or “if trust drops below a threshold, the character refuses a request.”

The current core loop is:

event -> deterministic rules -> updated state -> structured outputs

Most runtime events do not call an LLM. Aethrion can update state, evaluate rules, create memories, emit structured outputs, and schedule future events without model inference.

LLMs are deliberately kept outside the authoritative state path. They are used only as an optional expression layer, for example when a host application wants to render a structured output into natural language.

In a real deployment, that optional expression step could communicate with an external LLM provider or model server over HTTP JSON, an OpenAI-compatible API, gRPC, or another network boundary.

That means Aethrion is not trying to make LLM inference faster. The LLM provider or model server will often be the slowest part of the system. The role of BEAM/OTP here is to coordinate long-running agents, state transitions, scheduled behavior, failures, and external LLM calls reliably.

The fake LLM adapter in the current alpha exists to prove that the runtime works without a real model.

Current features:

• Aethrion.Runtime.dispatch/2
• structured runtime errors
• scripted CLI demo: mix demo.drama
• interactive CLI demo: mix demo.interactive
• branched scenario demo: mix demo.branches
• JSON persistence
• supervised GenServer runtime and scheduler
• fake LLM adapter
• ExUnit tests
• GitHub Actions CI
• English/Korean README

Try it:

git clone https://github.com/simulacre7/aethrion.git
cd aethrion

mix deps.get
mix test
mix demo.drama
mix demo.interactive
mix demo.branches

Demo assets are included in the README:

https://github.com/simulacre7/aethrion

This is not production-ready yet. I’m sharing it as an early alpha and would appreciate feedback on:

• the runtime API shape
• the event/rule/output model
• the external LLM boundary
• how far this should lean into OTP processes
• whether this framing makes sense for Elixir developers
• what would make the demo more convincing