Architecture

Curia is built around a central message bus that connects five layers. Four domain layers — Channel, Dispatch, Agent, and Execution — have hard security boundaries enforced at registration time. A fifth System layer provides trusted cross-cutting infrastructure (audit logger, memory engine, scheduler). All communication between layers flows through typed events on the bus, backed by Postgres for persistence.

​

The five layers

​

Bus security enforcement

The bus validates publisher authorization at registration time. A module registered as layer: "channel" can only publish event types in the channel allowlist (inbound.message, inbound.event). Attempting to publish skill.invoke throws an error. This is a hard security boundary — it’s architectural, not policy. A compromised channel adapter cannot invoke skills, write to memory, or modify agent state. It can only publish inbound messages, which are then subject to the full dispatch policy pipeline before reaching any agent. The System layer is the exception — it has full publish and subscribe access to all event types. This is reserved for trusted infrastructure components that need cross-cutting access to operate.

​

Message flow

A complete round-trip for an inbound message:

​

Inter-agent communication

Agents can communicate with each other through the Bullpen — a structured, threaded discussion space. An agent publishes an agent.discuss event addressed to another agent, which responds in the same thread. All Bullpen messages flow through the bus with the same security model and are written to the audit log with full causal tracing. You can observe, intervene in, or start Bullpen threads from any channel.

​

Outbound context bridge

When Curia sends a message it often expects a reply that needs to come back to a specific agent with specific context. The outbound context bridge is a small registry that records every outbound message — channel, originating agent, content preview, expected-reply hint, delegation hint, TTL — so that when an inbound reply arrives, the dispatcher can prepend a [ACTIVE OUTBOUND CONTEXT] block to the coordinator’s task. The coordinator reads that block and decides whether to delegate the reply back to the originating specialist. The bridge is what lets the meeting-debrief agent claim threads for replies to its own outbound prompts, the research-analyst hold a multi-turn conversation with the CEO, and the coordinator route a Signal reply about an urgent email back to the CEO Inbox agent — all without coupling the routing logic to message bodies. Every send skill auto-registers an entry on success; callers can attach delegation metadata via an optional context_bridge input. Entries expire on a TTL (6 hours for auto-registered, 24 hours for explicit) and are released either by the coordinator (when it detects the conversation has ended) or by a periodic cleanup job.

​

Event type registry

All event types are defined as a TypeScript discriminated union — no untyped payloads or string-typed event names. Each event carries:

• id — UUID
• timestamp — when the event was created
• type — the discriminant (e.g. inbound.message, skill.invoke)
• source_layer — which layer published it
• source_id — which component published it
• parent_event_id — causal chain linking (optional)
• payload — typed per event type

​

Write-ahead audit logging

The audit logger writes events to Postgres before delivering them to other subscribers. If the process crashes after the audit write but before subscriber delivery, the event is logged but unprocessed. This gives at-least-once delivery for all events and exactly-once audit recording.

​

Design principles

1. Hard security boundaries — layers are physically prevented from unauthorized actions, not just organizationally separated
2. Everything is auditable — every event, decision, and inter-agent exchange is logged and traceable
3. Memory-first — sophisticated knowledge graph with temporal awareness, not just conversation logs
4. Extensible by design — new channels, skills, and agents added without touching core code
5. Restart-safe — all state lives in Postgres; no in-process state that dies with the process
6. Single-tenant simplicity — no multi-tenant complexity; deploy multiple instances for multiple users

​

Tech stack