What not to build

• No workflow DSL. Activation policies + permissions + tools compose into workflows without a separate language.
• No agent type system beyond the content schema. An agent is what it does, defined by its prompt, tools, and permissions. Not by a class hierarchy.
• No message storage in Postgres. The two-storage-plane split is working. Don’t collapse it.
• No primitives beyond the six. If something feels like it needs a seventh entity type, it’s probably a record with a new type string.

Ideas on the frontier

These extend the system without adding new primitives — each is a new record type, content field, or activation path.

Scope-level instructions. Rooms and houses could carry instructions in their content that all agents in that scope inherit — “respond in Danish,” “this is a code review room.” Layered under each agent’s own system prompt.

LLM key cascade. Keys set at bot, room, or house level, resolved bot → room → house → global. Users bring their own keys without sharing a single worker secret.

Streaming replies. Token-by-token delivery via a transient stream (separate from the room’s durable stream). When complete, post the full message to the durable stream and discard the transient one. The room stops going silent for seconds during long responses. This matters for UX but not for capability.

Inbound webhooks. A stable URL per agent for external services (GitHub, Linear) to trigger activation directly, without posting a message through the app API.

The substrate test

When evaluating any addition to arbe, the question is: does this keep the primitives general, or does it bake in assumptions?

A feature that requires a new table, a new auth path, or a special-case permission rule is a signal that the primitives might be incomplete — or that the feature is being designed at the wrong layer.

The best additions are the ones that feel inevitable once you see the primitives clearly.