Overview

OpenMAIC's Pro workbench turns course creation into a server-backed session that outlives the browser request. A database owns the session identity, lease, attempt, event history, cancellation, and pending follow-ups while workers execute model and tool turns. Separate model history and client event logs support reasoning and replay; delivery cursors, recovery repair, and explicit terminal states prevent duplicate or falsely settled work. This continuity requires a database, an explicit provider-prefixed model route, worker coordination, and recovery rules.

Learning outcomes

A Pro session's durable database record, not the browser or worker process, owns lease, attempt, event, and cancellation state.
Separate entry history and event logs let resumed models recover context while clients replay committed lifecycle events.
Leases, delivery markers, and recovery repair make interruption explicit, but they cannot make an external provider call transactional.

Keywords

OpenMAICworkbenchsessionsleaseseventsrecovery

From One Request to a Durable Building Session

The Pro workbench changes the unit of work in OpenMAIC. A classic generation request can return after it has produced a classroom; a durable building session must remain coherent while a worker claims it, a model calls tools, a user sends follow-up instructions, and a process may restart. This chapter traces that lifecycle so the reader can judge what persistence enables, why leases and event history are user-facing features, and which database and model-routing conditions the workbench requires.

A session outlives the browser request

A request-scoped generator is usually organized around a caller waiting for a result. The caller submits requirements, the application performs model work, and the response returns a classroom or an error. If the connection disappears at the wrong moment, the request may be lost or left ambiguous. That is an acceptable shape for a one-shot operation only when the result can be retried without confusing a new attempt with the old one.

The Pro workbench treats course building as a durable session. A session is created in a server-backed store, placed in a queued state, and then claimed by a background worker. The worker's process is not the session's identity. The database holds the authority for who owns the current lease, which attempt is running, which events have been written, and whether cancellation or follow-up work is waiting. The browser can disconnect while the worker continues, and the worker can stop while the session remains available for recovery.

sequenceDiagram participant U as User and browser participant A as Control plane participant D as PostgreSQL store participant W as Worker participant W2 as Recovery worker participant M as Model participant E as Event stream U->>A: Create a course building session A->>D: Persist queued session and opening message D-->>A: Return durable session identity A-->>U: Return control response W->>D: Claim queued session D-->>W: Grant lease and attempt W->>M: Run prompt and tool turn M-->>W: Return text and tool events W->>D: Append ordered history and events D-->>E: Notify durable event E-->>U: Stream or replay event history W->>D: Heartbeat while work continues U->>A: Post follow-up or request cancellation A->>D: Persist message or cancel request D-->>W: Wake worker or await fallback poll W->>D: Settle, requeue, or park session W2->>D: Claim expired or parked work D-->>W2: Return transcript and new lease

The lease is a time-limited claim, not a permanent ownership transfer. A worker claims a session with an attempt identity and sends heartbeats while it is running. If the worker disappears, another worker can eventually claim the work according to the store's rules. The attempt number helps distinguish a new run from stale writes produced by an earlier one. A late event from a worker that no longer owns the lease must not become the current truth merely because it arrived after a restart.

This is why leases and heartbeats belong in the product explanation. They decide whether a user sees a session resume, fail, or remain queued. They also protect the course document from competing workers.

Published by DeepMox

FAQ

How does OpenMAIC keep a building session alive after the browser disconnects?

OpenMAIC stores the session in a server-backed database and lets a background worker claim it under a time-limited lease; the browser can reconnect to durable events later. A polling backstop helps recover work even if a wakeup notification is lost.

Why does OpenMAIC keep model history separate from the event log?

OpenMAIC keeps model history for resumed reasoning and tool context, while the event log gives the client a replayable lifecycle record. The separation supports recovery without putting every mutable model object into the user-facing timeline.

What happens when an OpenMAIC worker stops during a model or tool turn?

OpenMAIC preserves the known durable state, repairs incomplete model-history suffixes as needed, and lets a new attempt claim the session; it does not pretend an uncommitted provider result succeeded. The session may instead be requeued, parked, failed, or cancelled according to its state.

Previous9 minOpenMAIC: Four Kinds of Course State

Next9 minOpenMAIC: Typed Tools for Course Editing

OpenMAIC: Durable Building Sessions

From One Request to a Durable Building Session

A session outlives the browser request

FAQ