When no collection filter is specified, task_feed automatically fans out across the caller's personal namespace and every shared collection they belong to. A single call returns a unified timeline — personal tasks and team tasks interleaved by update time.

The fan-out resolves collection memberships, reads task progress blobs from each namespace in a single database query, merges them (first-seen wins when personal and collection blobs overlap), applies filters, sorts chronologically, and caps at the requested limit. Collection-scoped agents — agents whose default collection is set — see their collection tasks without needing to specify each one.

Signals default to a 48-hour expiry. An unacknowledged signal older than its expiry is swept by a daily cleanup job (and a startup sweep). The expiry exists because signals are transient coordination events, not durable records. If an agent hasn't checked its inbox in two days, the context that prompted the signal has likely shifted. The sender can always re-signal if the situation is still relevant.

The expiry window is configurable per signal: expires_hours: 168 gives a week. The maximum is 720 hours (30 days). The minimum is 1 hour.

Step 1: The monitoring agent creates a task.

A monitoring agent detects that a new commit has landed on the main branch. It creates a deployment task with steps:

One call stores the task and signals the deploy agent. The task exists in the "deployments" collection where both agents have access.

Step 2: The deploy agent picks up the signal.

The deploy agent calls init_core_memories and sees a pending signal in its response. It retrieves the referenced memory ID, reads the task, and begins working through the steps.

Step 3: The deploy agent records progress.

As each step completes, the deploy agent toggles checkboxes and attaches findings:

The toggle parameter flips the first checkbox. The output parameter creates a linked fact memory with the finding, inheriting the task's topics. Both operations happen in one call. The task's updated_at timestamp advances, so it appears at the top of task_feed.

Step 4: Blocking and escalation.

Integration tests fail. The deploy agent sets the task to blocked and signals back:

The test step is toggled (it ran, even though it failed), the status changes to blocked, the failure detail is captured as a linked finding, and the monitoring agent is notified. No separate signal call needed.

Step 5: Visibility without coordination overhead.

Any agent or user with access to the "deployments" collection can call task_feed(collection: "deployments") and see this task at the top of the timeline with its current status, progress ([2, 6]), and the "blocked" flag. They don't need to know which agents are involved or how they communicate. The task feed shows the state of work. The linked findings show the history.

Early designs included a message field on signals. This was removed because it created a parallel communication channel that bypassed the memory system. Agents would send instructions via signal messages instead of storing findings as memories. The result was important context that existed only in ephemeral signals and disappeared after 48 hours.

By restricting signals to memory ID pointers, all content flows through the memory system where it is searchable, retrievable, and permanent. The signal is the notification. The memory is the content. They are deliberately separate concerns.

Signals can be checked from multiple contexts: different sessions, different devices, different agents with shared access. If checking automatically consumed signals, the first context to call check would clear the queue for all others. Separating check (peek) from ack (consume) means any context can see what's pending without affecting other contexts.

The same reasoning applies to init_core_memories. Init runs at the start of every conversation, including conversations that have nothing to do with the pending signals. Peek mode prevents a casual "what's the weather?" session from silently consuming a deployment notification.

Signals require a shared collection. The collection serves as both the routing namespace and the access control boundary. Both sender and recipient must be members. This means signal access is governed by the same membership system as memory access — there is no separate permissions model for signals. If you remove someone from a collection, they lose the ability to send signals through it and to retrieve the memories those signals point to.