RFC: daemon lifecycle events + subscription API

[tangyuanjc]

RFC: daemon lifecycle events + subscription API

Context

This is a discussion-first RFC. I am not proposing a code PR until maintainers confirm whether this belongs as a new native event/subscription layer, as an extension of the outbound webhook RFC, or as a narrower autopilot trigger feature.

We are dogfooding Multica as an internal multi-agent operating system with local daemons, employee agents, autopilots, and closing/reporting workflows. Three sharp edges keep recurring:

1. Closing automation: when an issue is moved to done or in_review, we want a closing agent to create an HTML report and notify the original human creator. Today this is a manual SOP plus a weekly audit script, because autopilot triggers do not expose issue.status_change.
2. No-ack escalation: when a human assignee or downstream agent does not acknowledge an assigned issue within a configured window, we want an escalation task to be created automatically. Today that requires polling multica issue list.
3. Runtime offline alerts: when a local daemon stops heartbeating, we want a notification or issue to be created before humans discover the offline runtime hours later. Today this also requires polling runtime state.

There is strong nearby prior art in the repo:

• RFC: outbound webhooks on issue/run state transitions #1964 proposes outbound webhooks on issue/run state transitions and documents the existing internal bus taxonomy.
• RFC: inbound webhooks (external systems → Multica) #2373 proposes inbound webhooks as the external-system-to-Multica counterpart.
• RFC: daemon auto-reload when CLI binaries change #2422 discusses daemon auto-reload on CLI binary changes and already adds daemon health/lifecycle thinking such as reload_pending.
• [Bug]: On Windows, closing the terminal that started multica daemon start causes the local daemon/agent to go offline #1414 and [Bug]: The Windows 11 multica.exe daemon automatically terminates the process #1394 reported Windows daemon offline/lifecycle failures; fix(daemon/windows): break out of parent shell Job Object so daemon survives #1679 fixed one class of daemon survival bug.
• feat(agents): gate private-agent surfaces with allowed_principals predicate #2359 shipped an allowed_principals predicate for private-agent surfaces, which is directly relevant to event subscription RBAC.

This RFC is not meant to replace #1964. The narrower question is: should Multica expose first-class lifecycle events that native surfaces such as autopilots, agents, and external subscribers can consume without each team writing a polling loop?

Goals

1. Add first-class lifecycle events for issue state, acknowledgement timers, and daemon/runtime health.
2. Let autopilots and agents subscribe to those events without polling.
3. Let external services subscribe through the same conceptual surface, ideally reusing RFC: outbound webhooks on issue/run state transitions #1964 outbound webhook delivery when the sink is HTTP.
4. Make event delivery observable, idempotent, replayable enough for debugging, and gated by workspace RBAC.
5. Keep v1 small enough to ship as a platform primitive rather than a full workflow engine.

Non-goals

• No full replacement for RFC: outbound webhooks on issue/run state transitions #1964 outbound webhooks.
• No full replacement for RFC: inbound webhooks (external systems → Multica) #2373 inbound webhooks.
• No general-purpose workflow DSL.
• No task retry-counter redesign.
• No immediate guarantee that every internal bus event becomes public API in v1.

Proposed event types

issue.status_change

Emitted when an issue status changes.

Example payload:

{
  "event_id": "01H...",
  "type": "issue.status_change",
  "workspace_id": "uuid",
  "actor": {"type": "agent", "id": "uuid"},
  "occurred_at": "2026-05-13T00:00:00Z",
  "issue": {
    "id": "uuid",
    "identifier": "WS-95",
    "previous_status": "in_progress",
    "status": "done",
    "assignee_type": "agent",
    "assignee_id": "uuid",
    "creator_type": "member",
    "creator_id": "uuid"
  }
}

Primary use case: when status in ["in_review", "done"], trigger a closing autopilot that creates one child issue assigned to the closing/reporting agent, with a duplicate guard on (parent_issue_id, assignee_id).

issue.no_ack_timeout

Emitted by a small scheduler/sweeper when an assigned issue has not been acknowledged within a subscription-defined duration.

The acknowledgement predicate should be explicit. A reasonable v1:

• assignee added or issue created with assignee starts the timer;
• timer is cleared by an assignee-authored comment, status transition, task progress event, or explicit "ack" action if one is added later;
• timeout emits one event per (issue_id, assignee_id, timeout_policy_id) until the issue changes materially.

Primary use case: route Tier-1 no-ack tasks to Tier-2 agent assistance after 1 hour, then optionally to CTO/oncall if the escalation also stalls.

runtime.offline

Emitted when a runtime/daemon heartbeat crosses an offline threshold.

Example payload:

{
  "event_id": "01H...",
  "type": "runtime.offline",
  "workspace_id": "uuid",
  "runtime": {
    "id": "uuid",
    "host": "WIN-FQK6M4FEF13",
    "last_seen_at": "2026-05-12T10:38:00Z",
    "offline_threshold_seconds": 900
  }
}

Primary use case: create an incident issue or send a notification before a local daemon stays offline for hours.

Subscription API

One v1 shape:

GET    /api/event-subscriptions
POST   /api/event-subscriptions
GET    /api/event-subscriptions/{id}
PATCH  /api/event-subscriptions/{id}
DELETE /api/event-subscriptions/{id}
GET    /api/event-subscriptions/{id}/deliveries
POST   /api/event-subscriptions/{id}/test

CLI mirror:

multica event subscription create \
  --name closing-agent-on-done \
  --events issue.status_change \
  --filter '{"status":["in_review","done"]}' \
  --target 'autopilot:<autopilot-id>'

multica event subscription create \
  --name runtime-offline-alert \
  --events runtime.offline \
  --filter '{"offline_threshold_seconds":900}' \
  --target 'agent:<cso-agent-id>'

multica event subscription deliveries <id>

Potential targets:

• autopilot:<id> — enqueue an autopilot run with the event payload as context.
• agent:<id> — create/dispatch a task or issue according to a template.
• webhook:<id> — reuse RFC: outbound webhooks on issue/run state transitions #1964 delivery semantics for HTTP sinks.
• inbox — create a workspace inbox notification.

For autopilot targets, v1 could avoid a new template language by passing the event payload into the existing autopilot create-issue mode and letting the autopilot description/template define the output. If that is too implicit, make target_template explicit in the subscription row.

Delivery and persistence

Recommended default:

• Mint event_id at event creation time, not at sink delivery time.
• Persist a compact event log for at least 7-30 days: event_id, workspace_id, type, object_type, object_id, occurred_at, actor fields, and payload JSON.
• Persist deliveries per subscription: event_id, subscription_id, attempt, status, next_attempt_at, last_error.
• Native targets (autopilot, agent, inbox) should be at-least-once with idempotency keys.
• HTTP targets should reuse RFC: outbound webhooks on issue/run state transitions #1964 persisted webhook delivery, retry, HMAC, and SSRF protections rather than inventing a second transport.

This gives replay/debuggability without promising an infinite event stream.

RBAC

Subscription creation/update/delete should be workspace owner/admin only in v1, matching the security posture from #1964.

Delivery visibility should follow the same permission principle as #2359:

• the subscription creator must be allowed to observe the events it subscribes to;
• private-agent events should not be leaked to users who cannot access that agent;
• event payloads should either be redacted at creation time or redacted per subscriber before delivery;
• wildcard subscriptions should be treated as sensitive because new event types may expose new payloads.

Relationship to existing work

#1964 outbound webhooks

#1964 is the right primitive for HTTP delivery to external systems. This RFC should not duplicate its HMAC, persistence, SSRF, retry, or delivery CLI design.

The open design question is whether issue.status_change, issue.no_ack_timeout, and runtime.offline should become new public bus event types that #1964 can deliver, or whether they should be native-only derived events consumed by autopilots first.

#2373 inbound webhooks

Inbound webhooks solve external-system-to-Multica. This RFC is Multica-state-to-subscriber and should share naming/security conventions where possible.

#2422 daemon auto-reload

#2422 covers one daemon lifecycle action: version-change detection and graceful reload. runtime.offline is adjacent but distinct: it is an operational signal emitted when heartbeat/registration state crosses a threshold.

#1414 / #1394 / #1679 Windows daemon lifecycle

These show that runtime lifecycle is not just UI polish. Local daemon survival/offline state affects task reliability and should be observable as a first-class event.

Open questions

1. Event delivery: for native subscriptions, should delivery be push-style enqueue, pull/replay from an event log, WebSocket, or a combination?
2. Event persistence: is a short event log required for replay/debugging, or should v1 persist only deliveries?
3. Event granularity: should subscriptions be per workspace only, or should they be scoped per issue / per agent / per runtime?
4. Backpressure: when a subscriber is slow, should Multica buffer, drop oldest with audit, pause the subscriber, or rely entirely on target-specific queues?
5. RBAC: should event access be evaluated at subscription creation time only, delivery time only, or both?

Suggested v1 slice

If this direction is acceptable, the smallest useful v1 could be:

1. Add issue.status_change as a derived event emitted from the issue update path.
2. Add event_subscription rows for target_type='autopilot'.
3. Enqueue the target autopilot exactly once per (event_id, subscription_id).
4. Add event_subscription_delivery for observability.
5. Expose CLI CRUD + deliveries list.

Then add runtime.offline and issue.no_ack_timeout as follow-ups once the event/subscription spine is proven.

Tests

Suggested coverage:

• Status transition in_progress -> done emits exactly one issue.status_change.
• Non-status issue updates do not emit issue.status_change.
• A subscription filtered to status=done does not fire on in_review.
• A duplicate delivery retry does not enqueue a second autopilot run.
• A private-agent event is not delivered to a subscriber that no longer has access.
• A paused subscription receives no deliveries.
• Runtime offline threshold emits once per offline episode and resets when the runtime comes back online.
• No-ack timeout clears when the assignee comments or status changes before the deadline.

@Bohan-J curious whether this should be framed as a native event-subscription layer, an extension of #1964's event taxonomy, or a narrower "autopilot triggers on issue lifecycle" feature. If you already have a preferred direction, happy to revise the scope before anyone writes code.

AI disclosure: drafted with help from a Multica Codex agent based on our internal dogfooding notes, Multica CLI behavior, and the linked upstream issues/discussions.