Why synchronous agent execution is fragile
Model-driven workflows have variable latency. Context selection, inference, tool I/O, sandbox startup, human approvals, retries, verification, and evidence capture can dominate the request. A long-lived HTTP connection is not a durable lifecycle model.
Execution boundary
- The user-facing API should capture intent and create a run.
- The runtime should execute longer workflows through durable state and events.
- Long-running approval or recovery should not live only in an open HTTP connection.
Durable execution systems and cloud architecture guidance preserve workflow progress outside the original process so work can resume after interruption. MIR still needs its own policy, evidence, and authority semantics above that mechanism. Source: Durable execution documentation Source: Cloud design patterns
Event sequence
The event vocabulary should describe facts, not vague log messages. A minimal flow can be represented as an ordered strip:
run.createdIntent accepted; run identity and initial contract persisted.context.selectedAllowed context and provenance recorded.policy.evaluatedAuthority decision recorded before action.model.requestedAdapter, route, budget, and request contract fixed.model.candidate_returnedCandidate captured without treating it as an authorized command.tool.action_proposedCandidate translated into a typed action envelope.tool.action_validatedSchema, policy, risk, and state checks completed.approval.requestedEmitted when policy requires a human or service decision.checkpoint.createdRecoverable state captured before consequential execution.tool.executedBounded connector performed the authorized action.evidence.artifact_recordedDiff, result, receipt, or test output linked to the run.recovery.startedEmitted when validation, execution, or verification fails.run.completed·run.failed·run.terminatedOne explicit terminal state closes the lifecycle.
Not every event requires a public message broker. The requirement is durable, typed, ordered state with defined delivery and replay semantics.
Control loop
Observe
Capture intent, context provenance, model candidates, tool results, state changes, and operational signals.
Constrain
Evaluate and decide through policy, schema, risk, budget, identity, and lifecycle checks.
Recover
Use checkpoints, safe retry, route fallback, compensation, suspension, or operator intervention.
Prove
Record typed events and artifacts so the run can be reviewed after execution.
Human-in-the-loop is a runtime state
Human review is not a vague pause in chat. It is a first-class state with an explicit transition into and out of awaiting_approval.
- Queue
- Named approval queue with ownership and escalation.
- Review object
- Readable diff, action envelope, artifact, or proposed outcome.
- Risk
- Risk class and required approval reason.
- Timing
- Expiration, timeout, and safe behavior when no decision arrives.
- Identity
- Approver identity and decision timestamp in UTC.
- Evidence
- Typed approval or denial event linked to the resulting transition.
Implementation guidance
Compatible implementation styles include durable workflow engines, message queues, background workers, event stores, transactional outbox delivery, idempotency keys, replayable evidence ledgers, OpenTelemetry traces, dead-letter queues, and compensating actions. These mechanisms are complementary rather than interchangeable.
Required questions
- Which state is authoritative after a worker or host restarts?
- Which events are facts, commands, notifications, or projections?
- How are duplicate deliveries detected?
- Which actions are safe to retry, and under what key?
- How are poison messages quarantined and reviewed?
- How are trace spans correlated with evidence without treating telemetry as the evidence ledger?
- How does a terminal state prevent late work from continuing?
OpenTelemetry provides evolving semantic conventions for generative-AI operations; a MIR can use them for interoperability while retaining domain-specific evidence records. Source: OpenTelemetry GenAI conventions
Durable state, idempotency, transactional outbox, circuit breaking, dead-letter handling, and compensation are production practices. Agent-specific event vocabularies and replayable evidence semantics are emerging practices.
Source record
References
- Cloud Design Patterns Primary source
Microsoft. Azure Architecture Center. Published Current documentation; last reviewed 2026-06-23 UTC. Official architecture guidance.
- Temporal Platform Documentation Primary source
Temporal Technologies. Temporal. Published Current documentation; last reviewed 2026-06-23 UTC. Official vendor documentation.
OpenTelemetry project. Cloud Native Computing Foundation. Published Current specification repository; last reviewed 2026-06-24 UTC. Official specification.