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 (Postgres for structure, durable streams for content) 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.
Frontier ideas that extend the system without adding new primitives — each is a new content field, record type, or activation path: scope-level instructions (rooms / houses carry instructions all agents in scope inherit, layered under each agent’s own prompt — “respond in Danish”, “this is a code review room”); LLM key cascade (keys at bot / room / house, resolved bot → room → house → global; users bring their own keys without sharing a single worker secret); streaming replies (token-by-token via a transient stream separate from the room’s durable stream, full message posted to durable on complete — the room stops going silent for seconds; UX, not capability); inbound webhooks (a stable URL per agent so external services like GitHub or Linear can trigger activation directly without posting through the app API).
The substrate test for any addition: does this keep the primitives general, or does it bake in assumptions about what agents are and how they work? A feature that requires a new table, a new auth path, or a special-case permission rule is a signal the primitives might be incomplete — or that the feature is being designed at the wrong layer. The best additions feel inevitable once you see the primitives clearly.