# 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.

**See:** [thinking/primitives](./primitives.md), [thinking/thesis](./thesis.md), [thinking/layers](./layers.md).