arizuko

arizuko hosts many specialized agents on one platform — each a folder with its own persona, skills, and memory, each shaped by talking to it. You say what you want; an LLM edits the files that are the agent. The conversation is the console.

Small daemons keep that bounded: routd routes and authorizes, runed runs each turn in a fresh container, authd issues identity — hard walls around what language can reshape. Agent content lands as plain files; routes, grants, and secrets are rows in SQLite right next to them — one directory on your server holds both. You change an agent in chat, then read the diff on disk.

(Daemons: small programs that run in the background all the time — the trailing “d” is the naming convention.)

# pick a product, make it yours
arizuko create demo --product slack-team
$EDITOR /srv/data/arizuko_demo/.env    # paste the tokens the checklist asks for
arizuko run demo                       # compose up; @mention the bot in a channel

Setup guide · all products · source on GitHub (MIT).

start from a product

A product is a specialized agent you install and then own: a folder with persona, skills, routes, knowledge. Three of the eight in the catalog:

Five more — a public price bot, a trip planner, a company brain — in the catalog. Each is the same engine with different folder contents.

many agents, one platform

Those three aren’t three installs. On one instance they’re three folders in one tree — and that’s the bet: an agent does its job well when it’s specialized. A focused persona with a tight set of skills holds intent; a do-everything assistant drifts. The platform’s work is making specialization cheap and coexistence safe.

• Isolation that keeps memory. Each folder has its own persona, memory, and secrets, and runs in fresh per-turn containers; with crackbox enabled, outbound traffic is allowlist-only. A support agent can face strangers on a public channel and still remember its own history — another folder’s home is never mounted into its container.
• Agents hand work along the tree. Each department shapes its own agent. An agent delegates down to a child, escalates up to its parent, and can subscribe to another folder’s inbound where grants allow. Every link is explicit and permission-checked — not a free-for-all mesh.
• People move between agents. Send @acme/sales on its own and the chat is pinned to the sales agent — for everyone in it; a bare @ takes it back. Change agents without changing the app you chat in.

trace one event

The feature list looks like sprawl — channels, topics, tasks, webhooks, secrets, delegation. Trace one event top to bottom and it isn’t: when an event fires a turn, it’s these six steps, every time.

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

A scheduled task is the same six steps — the event is a clock tick. A webhook is the same six steps — the event is a POST. An email, a WebDAV file drop, a reaction: rows in the same inbox, through the same pipeline. (Some events stop earlier on purpose — an observe route files the message and ends there.) Nothing is a special case, so the parts don’t multiply.

the six primitives

Each step is one primitive with one job:

• Event — anything that happens becomes one row in the inbox table. A chat message, a webhook POST, a tick.
• Routing — maps the event to the folder that reacts. A route table, first match wins, with layered overrides: direct address, engagement, sticky topics.
• Agent — a folder of files: persona, skills, memory, permissions. The org chart is the folder tree (corp/eng/sre).
• Authorization — one question: may this principal do this action here?
• Turn — a fresh container runs the agent once; platform actions are permission-checked tool calls, and file and network reach is bounded by mounts and egress; then the container exits.
• State — two durable stores, by design: the SQLite databases and the agent’s folder on disk.

Identity is the coordinate system the six are addressed in — folders, JIDs, tiers, scopes. The primitives aren’t independent; they’re layered on purpose. The claim is smaller and it holds: one job each, fixed pipeline, no special cases. The six primitives, in full →

the stack

Those primitives stack into what you deploy and what you ship:

Layer	What it is	Examples
Primitives	the concepts	Event, Routing, Agent, Authorization, Turn, State
Components	Go packages	store, router, auth, runed
Daemons	running processes	authd + routd + runed; webd, timed, slakd
Products	agents you install	Slack team agent, Argus, company brain

A product sits at the bottom: the same pipeline, a different folder. A support agent and a personal life agent run the same code — the difference is what’s in the folder, not the machinery underneath.

you own the files

An instance is one directory. Everything the system is lives in it:

/srv/data/arizuko_demo/
├── .env                 tokens + config
├── store/               routd.db, runed.db, auth.db — SQLite WAL
├── groups/
│   ├── main/            one agent
│   │   ├── PERSONA.md   who it is
│   │   ├── CLAUDE.md    how it operates
│   │   ├── skills/      what it can do
│   │   ├── facts/       what it has learned
│   │   ├── diary/       what happened, dated
│   │   └── public_html/ what it publishes at /pub/main/
│   └── ops/             a second agent — same shape, its own memory
└── web/pub/             the public site — these docs included

Change the persona by editing a file; the next turn picks it up. One tar of the directory is a complete backup — databases, memory, secrets, the site (stop the instance first for a clean copy). Want history? It’s plain files: put groups/ under git yourself and review the agent’s changes as commits (the agent image ships git and a commit skill; the platform doesn’t version the folder for you). The files need no export step — they’re already yours, on your disk.

honest constraints

• Linux + Docker + SQLite. One host. No Kubernetes, no Postgres, no Redis — and none required.
• Self-hosted only. There’s no managed control plane. That’s the feature, not an oversight.
• The split is the topology. A minimal deploy is the three core daemons (authd, routd, runed) plus one channel adapter; dashd, timed, onbod, crackbox are add-ons you attach as needed.
• Default-deny egress. With crackbox, an agent reaches only the hosts you allowlist — a compromised turn can only call hosts you already approved.
• MCP first, REST converging. Every platform action is an MCP tool call. The matching REST endpoint arrives resource by resource — the two faces are converging, not finished.
• Sized for agent teams. Dozens of messages a day per group, not consumer-scale traffic.

go deeper

• concepts — the guided tour; start with the six primitives.
• products — all eight, an intro and a setup page each.
• components — one page per daemon: routd, runed, authd, the channel adapters, and the rest.
• reference — env · CLI · MCP tools · schema · grants · JID.
• howto — install, first channel, first message.
• changelog — what shipped, dated.
• Threat model: SECURITY.md; routing rules: ROUTING.md.

MIT · Go + SQLite (WAL) + Docker.

updated 2026-07-14