Aethrion - early alpha Elixir runtime for deterministic social agents

News RFCs
, , , ,
1

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:

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
4 Likes
2

Small follow-up question:

For people who have built actor/process-based systems in Elixir, would you model persistent characters as separate supervised processes, or keep characters as data inside a world/session process?

I’m currently leaning toward keeping the deterministic simulation core process-free, then adding OTP around runtime boundaries such as sessions, schedulers, and external LLM calls.

3

Always data! Using processes for simulation will make it harder to scale, depending on how much message passing you do between processes, and you’ll have bottlenecks for sure (To spawn, or not to spawn? remains a solid reference for this; the TLRD is: use processes to model runtime behavior). Here’s a great resource on the simulation part specifically: https://www.youtube.com/watch?v=RNCaINCFqhw (I also learned it kinda the hard way, check this out: Processing millions of events with elixir).

3 Likes
4

Thanks, that makes a lot of sense.

I’m leaning in that direction too: keep the simulation core as plain data + deterministic functions, and use OTP to model runtime behavior around it rather than making each character a process by default.

So characters, relationships, memories, and rules stay as data. Processes would be used for sessions, schedulers, external LLM calls, persistence, supervision, etc. I’d only consider per-character processes if there is a concrete runtime reason for that boundary.

I’ll read those references. The message-passing bottleneck warning is especially helpful before overfitting the design toward “one character = one process” just because BEAM makes that easy.