arizuko › concepts › primitives

primitives

arizuko is an event→reaction engine: something happens, and an agent reacts. The system is six parts in a fixed order, plus one coordinate system that addresses all six. Channels, tasks, webhooks, secrets, delegation and workflows are combinations of these six parts, not new machinery.

One Slack mention passes through all six steps

The figure follows one Slack mention from its arrival to the reply in the thread:

Slack @mention in #eng
  → Event          one inbox row (routd.messages)
  → Routing        → corp/eng/oncall
  → Agent          folder loaded: persona, skills, memory
  → Authorization  may it read / send / delegate here?
  → Turn           one ephemeral KVM guest run, then it exits
  → State          rows written, files edited
  → reply in the Slack thread

Every event takes the same six steps.

Each primitive does one job

Event: The one inbox. A chat message, a webhook POST, an inbound email, a scheduled tick and a reaction each land as one row in messages. The channel adapters, emaid, the webhooks and timed are event sources that write rows.
Routing: Event to folder. One route table, where the first match wins, with layers on top: direct address, engagement, sticky topics and observe. Engagement keeps the agent listening after a mention. Observe stores the message and sends no reply. Delegation and escalation are routes to a child or a parent folder. See routing.
Agent: Who reacts, and with what knowledge. An agent is a folder: PERSONA.md, skills/, MEMORY.md, a diary and an ACL. The folder tree, such as corp/eng/sre, is the org chart, at any depth. See the ant.
Authorization: One question: may this principal do this action here? Every answer comes from rows in the acl table. Nothing comes from the folder path. See grants and scopes.
Turn: The bounded reaction. One ephemeral KVM guest runs the agent loop for one turn and then powers off. Every side effect is one tool call through the auth gate. A call that changes state writes one audit row, and a denied or failed call writes one too. A successful read writes none. See audit trail. Tasks, autocalls and interjections are turns that a different event starts.
State: What persists. State has two stores by design. The shared database holds events, routes, grants, the ACL and sessions. The folder on disk holds the persona, skills, memory and diary. The folder is not a cache: the guest’s own filesystem keeps nothing, and each turn gets the folder mounted again. A tar of the stopped data directory is a full backup, because the store data lives under store/ there. See secrets.

Identity addresses the steps but is not a step

Identity is the coordinate system for the six steps: subs, JIDs, folders, roles and scopes. Routing resolves to a folder. Authorization keys on a principal. A turn runs as agent:<folder>. State is partitioned by folder. Every primitive refers to identity, but no step in the pipeline belongs to it. See auth and addressing.

A workflow is a discipline, not a primitive

arizuko has no workflow engine. A folder can hold a plan file and a ## Session opening section in its CLAUDE.md, and the agent follows them. The platform does not enforce the section. A workflow is Turn, State and the session lifecycle, used with a convention. See workflows.

Every feature maps to the six primitives

The table maps each part that looks like a feature to the primitives it uses.

What looks like a feature	What it is	Primitive
Channel adapters	event sources that write rows	Event
Webhooks, email	more event sources	Event
Scheduled tasks	events on a clock tick that start a turn	Event and Turn
Topics	a field on the event and a routing layer	Event and Routing
Engagement, observe	routing overrides	Routing
Delegation, escalation	routes to a child or a parent folder	Routing and Agent
Personas, skills, memory	folder contents	Agent
Workflows	a CLAUDE.md section and a plan file that the agent follows	Turn and State
Grants, scopes	views over the one authorization question	Authorization
Secrets, egress allowlist	folder state that a turn resolves	State and Turn
A product	a folder with a persona, skills and routes	Agent

Primitives become components, daemons and products

The same set of concepts stacks into the parts you deploy and ship: primitives become packages, packages become processes, and processes become products.

Layer	What it is	Examples
Primitives	concepts that do not change	Event, Routing, Agent, Authorization, Turn, State, and Identity as the coordinate system
Components	Go packages	`store`, `router`, `auth`, `ipc`, `runed`, `groupfolder`
Daemons	deployable processes	the core `authd`, `routd` and `runed`, and others such as `webd`, `timed` and `slakd`
Products	installable agents	Slack team agent, reality agent, company brain

A product is the same pipeline with a different folder. For this reason, a support agent and a personal life agent run the same code. You deploy daemons, not packages, so the site shows three layers. The components section lists the daemons, and the [README] names the package layer.

The primitives touch at named seams. They are not independent. Routing reads the shape of the event, and engagement overrides routing. Authorization is several gates, not one switch. A turn needs its grants and egress resolved before the guest starts. The claim is one job each, a fixed pipeline and no special cases.