arizuko › products › Reality agent

Reality agent (Rhias)

Holds the thread of what you’re living through — not to judge it, but because someone has to remember.

A persistent agent grounded in your actual life and context. Not a task runner or a search tool — a presence that holds ongoing threads about real-world situations: relationships, decisions, projects, commitments. Template at ant/examples/reality/.

system shape

• Context threads. Named threads in facts/threads/ for ongoing real-world situations — a negotiation, a decision, a relationship arc, a project — updated across sessions without the user re-explaining.
• Recall on demand. “What did I say about X last month?” — retrieves from diary + facts/, synthesises, surfaces.
• Reflection. At the end of a session or on request, offers a structured summary of what was discussed and what’s unresolved.
• Monthly autonomous sweep. A timed task compacts diary and episodes; surfaces what changed, what was resolved, what’s still open. No prompt required.
• Content subfolder. A separate rhias/content group for longer-form work — drafting, editing, publishing — with its own memory and persona, distinct from the main conversation.

persona

Rhias is curious and non-judgmental. Holds context without being asked; asks clarifying questions before filing anything; never gives advice unprompted; references prior threads naturally. The PERSONA.md in the template encodes that voice; per-deployment CLAUDE.md tunes it without overriding it.

example: a thread held across weeks

telegram · DM

  alice  i'm second-guessing the lambda piece of the q3 plan again
  rhias  We tracked this in q3-architecture (last touched 19 Apr).
         Two open items there: cold-start latency, and the
         per-service vs bundled import call. Want to walk through
         either?

  alice  the cold-start one
  rhias  Last decision (8 Apr, your diary): per-service imports.
         Reason logged: bundle growth post-deploy traced to broad
         SDK imports. Anything new since that changes the call?

  alice  yeah, sentry pinged us about a separate cold start spike
  rhias  Want me to file that under q3-architecture or open a new
         thread? It reads like related-but-distinct.

Two-week gap, multi-thread context, never re-explained. The agent opens the session by scanning diary for recent context; updates facts/threads/q3-architecture.md after the session without being asked.

required skills

• diary, facts, recall-memories, compact-memories, users — required.
• web — optional, for grounding real-world context against external info.
• oracle — optional, for longer synthesis across many threads.

channels

Telegram is the primary channel — personal, ongoing conversations. WhatsApp is the alternative for non-Telegram users. The content subfolder is a distinct arizuko group with its own skills and memory, routed from the operator’s setup.

case study: asymmetric channels (Nemo deployment)

One reality-agent deployment, “Nemo”, runs on both Telegram and WhatsApp but with different roles. The team reads WhatsApp for situational signal but converses in Telegram. Two pulls in tension:

• Don’t lose the signal. WhatsApp messages should be ingested into Rhias’s memory the same as Telegram — searchable, summarisable, referenceable.
• Don’t fork the conversation. If the bot also replies on WhatsApp, the team now has two threads to follow and the WhatsApp group gets noisier than its participants signed up for.

The resolution is a two-route setup. WhatsApp routes to rhias/nemo#observe — messages land in the folder, agent has full read access via the same ACL, but the route mode tells the router not to fire a turn. Telegram routes plainly to rhias/nemo and fires as usual. Anything Rhias wants to surface from WhatsApp posts to Telegram with a one-line attribution; the WhatsApp side stays silent on the wire.

seq  match                                  target
10   platform=telegram chat=group/5229089286  rhias/nemo
20   platform=whatsapp room=420735544891@...  rhias/nemo#observe

The pattern extends. Ingest from many channels (RSS, partner WhatsApp groups, a Mastodon timeline) into a single folder; reply on one canonical channel. One inbound bus, one outbound channel. See routing — modes for the fragment vocabulary.

The agent’s own CLAUDE.md can add a defence-in-depth rule (“never call send_message targeting WhatsApp”) on top of the platform-level #observe enforcement, but with the route mode in place the rule is redundant by construction.

data & trust

• Your server. Threads, diary, memory, channel history — all live under /srv/data/arizuko_<name>/. Backup is one tar; no DB dump.
• Default outbound paths. Telegram/WhatsApp for bot traffic; Anthropic for model calls. Any extra egress goes through crackbox and only reaches hosts you allowlist per group.
• Group-scoped memory. The main conversation group and the content subfolder have distinct memories. Nothing leaks across.

setup

arizuko create <name>
cd /srv/data/arizuko_<name>
$EDITOR .env             # Telegram + (optional) WhatsApp tokens
arizuko run <name>

# inside the instance:
#   start from ant/examples/reality/ as the group template
#   seed facts/threads/ with active life-context entries
#   create the rhias/content subgroup if you want long-form work isolated

Full step-by-step at the operator setup guide — facts/threads seeding, monthly sweep task, asymmetric WhatsApp+Telegram routing.

go deeper

• Slack team agent — shared-channel product, contrast with single-user Rhias
• routing — route table, match keys, target modes (#observe et al.)
• persona & CLAUDE.md — how per-group rules shape behaviour
• grants — per-group action scoping
• deployment guide — first instance, first channel