arizuko › products › Company brain

Company brain

A network of per-team agents, each with its own inbox and memory, reading intake from Slack, email, and webhooks — writing briefs, escalating issues, coordinating across folders on schedule.

what it is and what it isn't

The company brain is the action layer over org knowledge. Agents read intake, write daily briefs, escalate issues to the right team, and coordinate across the folder tree. That’s what this product does.

It is not a search engine. It is not a connector pipeline that syncs Confluence to a vector store. If you need semantic search over a 10,000-document corpus, pair this with Onyx or a retrieval skill — company brain handles the action on top of whatever retrieval you bring. More on this in honest constraints.

This is the complex-org end of the product spectrum. The other end is the supermarket price agent — one folder, one route, no hierarchy. Every primitive present here is also present there; they’re just at their minimal setting.

system shape

• Folder tree = org chart. Each team gets its own arizuko group folder. corp/eng/sre is the SRE team; corp/pm is product management; corp/intake is the shared inbound triage desk. Arbitrary depth; the folder hierarchy is your design call.
• Per-team memory. Each folder holds a PERSONA.md (that team’s agent behavior), a facts/ knowledge base (runbooks, decisions, reference docs), and a diary. Context doesn’t leak across teams unless an agent explicitly delegates or escalates.
• Scheduled briefs via timed. A timed task fires a Turn on a schedule — daily standup summary, weekly digest, on-call handoff. Agents write the brief to facts/ and send it to the configured channel. No cron on the host; the scheduler is part of the stack.
• Multi-source ingest. Slack messages, inbound email (emaid), webhook POSTs (GitHub, Sentry, Linear, PagerDuty), and WebDAV file drops all become Events that land in a team inbox. Route rules map the source JID to the right folder.
• Escalate and delegate. The SRE agent can escalate_group to corp/eng; a triage agent can delegate_group to the responsible team. These are normal MCP tool calls, not special wiring.
• Observe-mode ingest. A Slack channel can route to corp/eng#observe so the agent builds context without replying to every message. Observed channels are searchable via find_messages; the agent surfaces relevant content when a task or question arrives.
• Per-folder ACL. What each team’s agent may do — which MCP tools, which external hosts — is controlled by the acl table on that folder. Operator-managed from /dash/ or the CLI.

example: Sentry alert to Slack reply

[Sentry webhook fires]
  POST /hook/<token>
  X-Sentry-Hook-Signature: …
  {"issue": "OOM in billing-worker", "level": "error", …}

  ↓ Event lands in corp/eng/sre/oncall

  ↓ Agent reads alert + facts/runbooks/billing-worker-oom.md
  ↓ Checks find_messages for recent occurrences (last 7 days)
  ↓ Drafts a reply: root cause, recommended action, prior incidents

  ↓ Sends to #eng-oncall Slack channel
  sre-bot   OOM in billing-worker — seen 3x this week.
             Last fix (2026-05-30): heap limit too low post-deploy,
             fix was rolling restart + config bump. Runbook:
             /dav/corp/eng/sre/facts/runbooks/billing-worker-oom.md
             Action: restart billing-worker pod + check HEAP_MAX.

  ↓ Creates task: "Raise HEAP_MAX cap — billing-worker"
  ↓ Logs to diary: alert handled, task created

The agent read the alert, found the runbook, surfaced past incidents, drafted a reply, created a task — all in one Turn, no human routing required.

folder layout

corp/
  intake/           # triage inbox — all unrouted inbound lands here first
  eng/
    sre/
      oncall/       # on-call rotation folder; per-shift diary
    review/         # code review requests from webhook
  pm/               # product management briefs, roadmap context
  sales/            # deal summaries, CRM webhook ingest
  finance/          # budget alerts, expense webhook

Route table shape (excerpt):

seq  match                                        target
-10  chat_jid=hook:corp/eng/sre/oncall/sentry     corp/eng/sre/oncall
-5   room=T-acme/channel/C0ONCALL                 corp/eng/sre/oncall
0    room=T-acme/channel/C0ENG                    corp/eng#observe
5    chat_jid=hook:corp/eng/github                corp/eng/review
10   (empty match — catches everything)           corp/intake

arizuko group add writes the Slack rows for you; hooks and the catch-all are one arizuko route corp add <match> <target> --seq N each (see setup). Lower seq wins.

Timed tasks (examples — schedule these in the dashd tasks admin or by asking the agent to schedule a recurring task):

honest constraints

Before deploying, know what this product does not do:

• No connector sync pipeline. facts/ is populated manually, via WebDAV mounts, or by webhook-triggered agents that write to it. There is no OAuth crawler for Confluence, Notion, or Google Drive. If your knowledge base lives in those systems, someone (or a connector skill) must curate the relevant pieces into facts/ markdown files. The product works well for hundreds of documents; it breaks for enterprise-scale corpora without a connector.
• No embedding or vector search. Retrieval is grep + FTS5 (find_messages) over the local DB and facts/ files. For hundreds of well-structured markdown documents that’s fast and reliable. For tens of thousands of documents, pair with Onyx or a retrieval skill — the agent calls the retrieval backend via MCP, gets ranked results, and acts on them.
• No permission inheritance from source systems. The ACL is operator-managed at the folder level. arizuko doesn’t mirror Jira roles, Salesforce profiles, or Confluence space permissions. If a user has read access to a Jira board but not the arizuko folder for that team, they won’t reach the agent. The two permission graphs are separate; the operator manages both.

data & trust

• Your server. All team inboxes, knowledge bases, briefs, and agent state live under /srv/data/arizuko_<name>/. One tar is a full backup.
• Default outbound paths. The configured channel adapters (Slack, email) for bot replies; Anthropic for model calls. Any additional egress (webhooks, external APIs) goes through crackbox per folder.
• Folder isolation. Each team’s memory, facts, and diary are inaccessible to other teams unless an agent explicitly delegates or the operator grants cross-folder read. The SRE agent doesn’t see sales context; sales doesn’t see SRE runbooks.

setup

arizuko create corp
cd /srv/data/arizuko_corp
$EDITOR .env             # SLACK_BOT_TOKEN, SLACK_SIGNING_SECRET, ANTHROPIC_API_KEY

# create team folders (jid first, then folder; route written for you)
arizuko group corp add 'slack:T-acme/channel/C0ONCALL' corp/eng/sre/oncall

# webhook intake: mint a hook token, route its JID
arizuko token corp issue webhook corp/eng/sre/oncall sentry
arizuko route corp add 'chat_jid=hook:corp/eng/sre/oncall/sentry' corp/eng/sre/oncall --seq -10

# seed each team's knowledge base
$EDITOR groups/corp/eng/sre/oncall/facts/runbooks/*.md
arizuko run corp

# schedule briefs in dashd tasks admin (/dash/) or ask the agent:
# "schedule a task: every weekday at 09:00, write a daily standup summary"

Full step-by-step is in the operator setup guide — folder tree design, route table, timed tasks, WebDAV mounts, and ingest from Slack, email, and webhooks.

go deeper

• primitives — this product uses all six: Event (multi-source ingest), Routing (folder-tree dispatch), Agent (per-team persona + facts), Authorization (per-folder ACL), Turn (scheduled + event-triggered), State (team memory + shared DB)
• routing — route table, match keys, observe mode, delegation
• grants — per-folder action scoping; cross-team read grants
• timed — scheduled tasks; cron syntax; how timed fires a Turn
• davd — WebDAV workspace for populating facts/
• webhooks — hook tokens, Sentry/GitHub/Linear ingest recipe
• crackbox — per-folder egress isolation
• supermarket price agent — the other end of the spectrum: one folder, no hierarchy, no scheduled tasks