How should developers represent overdue work across connected tools?

A useful integration model separates the obligation from the events that describe activity around it. An obligation record can carry `obligation_id`, `obligation_type`, `subject_ref`, `due_at`, `owner_role` and `completion_rule_ref`. Events can carry `event_id`, `obligation_id`, `event_type`, `occurred_at` and `source_system`.

This distinction matters when an agent works across email, a task queue and a case system. A reply event does not necessarily fulfil a request. A status change does not necessarily prove that the requested evidence was received. Each event needs interpretation against the obligation's completion rule.

MirrorFirm could generate JSONL event streams alongside a table of obligations. A task could ask the agent to reconstruct the current position, identify what remains outstanding and select the next permitted tool action.

The integration should preserve both source references and normalised event types. Removing the source meaning too early can collapse an automated receipt and a substantive response into the same category. Keeping those distinctions gives the agent enough information to reason about actual progress across connected processes.