Description Build the reusable pattern every service ticket below reuses, so each team does not re-invent it: a standard event envelope, an emit client that (1) appends each event to the service's durable event log and (2) pushes it to the shared event hub, and an MCP server template exposing describe / read / act. Adopt the alert-agent-service as the hub (rule-based mode: dedup + fan-out on one SSE stream / MQTT topic tree). On the agent side, ship a single event listener that writes every received event to a durable agent inbox, which Hermes cron scans — the Phase-1 cron-over-log loop. Ship it as a small library (or cookiecutter) plus a worked reference service, with the benchmark on/off flag and deterministic replay built in.
Events (service → agent): push. Service emits an envelope → hub (dedup + fan-out) → the one agent listener → agent inbox → cron reasons. MCP is not involved.
Query + action (agent → service): MCP. describe / read / act only. The envelope's ref (e.g. order_id) is the handle the agent uses to drill into detail via an MCP read after it has been notified.
Replay = event-log playback, not re-running the pipeline. A live service's input is video; the event log is its output, so you cannot feed the log back into the pipeline. Replay operates downstream of the log, to reproduce the agent's day (the workload #99 benchmarks). Each service therefore supports two modes: live (pipeline runs on video → emits events) and replay (no inference; the service reads its recorded log and re-emits those events, in order and with original relative timing, onto its normal event-emit path into the hub). In replay mode the log replaces the pipeline as the event source, so the hub fan-out, the agent inbox, and the agent's decisions all see an identical run. This is also what lets the agent not tell a simulator from a real pipeline from shipped history. (Real vision inference is not bit-deterministic across hardware anyway — reproducible "same day on different silicon" runs come from replay/simulator, while live mode is for the functional demo.)
LIVE: video ─► pipeline ─► events ─► [log] + push to hub ─► agent inbox ─► cron ─► agent
REPLAY: [log] ─────────────► events ─────────► push to hub ─► agent inbox ─► cron ─► agent (pipeline bypassed)
Acceptance Criteria
[ ] Event envelope schema defined + documented (all fields; event_type and severity as enums).
[ ] Emit client: in-process, appends each event to the durable log and pushes it to the hub — no polling.
[ ] Event log provides: append, tail (live), query history (group by period, compare to baseline); behind an interface (SQLite default; swappable to Postgres).
[ ] Hub (alert-agent-service, rule-based mode) deployed: dedups and fans out envelope events on one SSE stream / MQTT topic tree.
[ ] Agent-side listener subscribes once to the hub and writes every event to a durable, ordered agent inbox.
[ ] Hermes cron scans the inbox and starts a reasoning turn (sense → reason → act); no per-event callback in Phase 1.
[ ] MCP server template exposes list_event_types/describe + pluggable read + action tools (no subscribe/callback).
[ ] Deterministic replay: a service runs in replay mode, reading its recorded log and re-emitting envelope events (in order, original relative timing) onto the hub — pipeline bypassed, downstream run identical.
[ ] Single flag disables the event/hub layer; published results can state the mode.
[ ] A worked reference service demonstrates the whole loop end to end (emit → hub → inbox → cron → MCP read/act).
[ ] Docs written to be read by a coding agent as well as a person.
Description Build the reusable pattern every service ticket below reuses, so each team does not re-invent it: a standard event envelope, an emit client that (1) appends each event to the service's durable event log and (2) pushes it to the shared event hub, and an MCP server template exposing describe / read / act. Adopt the alert-agent-service as the hub (rule-based mode: dedup + fan-out on one SSE stream / MQTT topic tree). On the agent side, ship a single event listener that writes every received event to a durable agent inbox, which Hermes cron scans — the Phase-1 cron-over-log loop. Ship it as a small library (or cookiecutter) plus a worked reference service, with the benchmark on/off flag and deterministic replay built in.
Events (service → agent): push. Service emits an envelope → hub (dedup + fan-out) → the one agent listener → agent inbox → cron reasons. MCP is not involved.
Query + action (agent → service): MCP. describe / read / act only. The envelope's ref (e.g. order_id) is the handle the agent uses to drill into detail via an MCP read after it has been notified.
Replay = event-log playback, not re-running the pipeline. A live service's input is video; the event log is its output, so you cannot feed the log back into the pipeline. Replay operates downstream of the log, to reproduce the agent's day (the workload #99 benchmarks). Each service therefore supports two modes: live (pipeline runs on video → emits events) and replay (no inference; the service reads its recorded log and re-emits those events, in order and with original relative timing, onto its normal event-emit path into the hub). In replay mode the log replaces the pipeline as the event source, so the hub fan-out, the agent inbox, and the agent's decisions all see an identical run. This is also what lets the agent not tell a simulator from a real pipeline from shipped history. (Real vision inference is not bit-deterministic across hardware anyway — reproducible "same day on different silicon" runs come from replay/simulator, while live mode is for the functional demo.)
LIVE: video ─► pipeline ─► events ─► [log] + push to hub ─► agent inbox ─► cron ─► agent
REPLAY: [log] ─────────────► events ─────────► push to hub ─► agent inbox ─► cron ─► agent (pipeline bypassed)
Acceptance Criteria
[ ] Event envelope schema defined + documented (all fields; event_type and severity as enums).
[ ] Emit client: in-process, appends each event to the durable log and pushes it to the hub — no polling.
[ ] Event log provides: append, tail (live), query history (group by period, compare to baseline); behind an interface (SQLite default; swappable to Postgres).
[ ] Hub (alert-agent-service, rule-based mode) deployed: dedups and fans out envelope events on one SSE stream / MQTT topic tree.
[ ] Agent-side listener subscribes once to the hub and writes every event to a durable, ordered agent inbox.
[ ] Hermes cron scans the inbox and starts a reasoning turn (sense → reason → act); no per-event callback in Phase 1.
[ ] MCP server template exposes list_event_types/describe + pluggable read + action tools (no subscribe/callback).
[ ] Deterministic replay: a service runs in replay mode, reading its recorded log and re-emitting envelope events (in order, original relative timing) onto the hub — pipeline bypassed, downstream run identical.
[ ] Single flag disables the event/hub layer; published results can state the mode.
[ ] A worked reference service demonstrates the whole loop end to end (emit → hub → inbox → cron → MCP read/act).
[ ] Docs written to be read by a coding agent as well as a person.