OpenSeal

OpenSeal's main sequence chain is: prompt or event → Agent or Team → Objective → Run → Turn → Skill action.

OpenSeal uses a persistent execution model in which tasks exist independently of the lifecycle of the original API request connection, and the Run status can be read at any time during an approval wait.

OpenSeal uses a lease mechanism to resume interrupted work: a worker claims a Turn within a set period of time, and if it stops renewing the lease, the lease expires and the Turn becomes claimable again.

OpenSeal does not provide exactly-once guarantees for external tools; leases can only ensure a task will be retried and cannot roll back side effects that have already occurred, so irreversible operations require the business layer to implement its own idempotency checks.

Two OpenSeal services with the same version number may expose entirely different sets of operations; the available API surface depends on the storage contract, connected components, and configuration, and operations corresponding to missing capabilities are simply not served.

In OpenSeal, creating a Run requires a dispatcher, resolving approvals requires an authorizer, and authoring a Workforce requires a complete model endpoint, credentials, and model name.

OpenSeal distinguishes waiting states into waiting for dependencies, waiting for another agent, waiting for approval, waiting for inbound events, and other distinct states, because they require different responses.

In OpenSeal, Agent and Team definitions have immutable saved versions, versions can be switched at deployment time with rollback support; change proposals go through independent steps of propose, review, decide, and activate, and saving a decision is not equivalent to activating the change.

In OpenSeal, a missing approval authorizer does not degrade into auto-approve permissions; in local mode, the standalone operator flag is required to enable local decisions, and a loopback address is mandatory.

OpenSeal saves active events and the state changes they describe within the same transaction, credential values are resolved only at action runtime, and are excluded from saved state, prompts, and end-client interfaces.

OpenSeal's standalone API does not itself provide authentication, request authorization, or TLS, which must be supplied by the host or proxy; local approval records use user:local and cannot distinguish which specific person approved.

OpenSeal's Workforce authoring accepts one OpenAI-compatible endpoint, with the path being OpenSeal authoring → gateway → model provider; the core does not automatically select a different model for each task, and the gateway's routing and fallback rules must be configured and tested separately.

OpenSeal's standalone service uses SQLite; PostgreSQL requires a Go embedding layer and is not a storage option supported by standalone.

OpenSeal has a separate HCL runbook path, executed via openseal run, which runs a typed graph within a single process and does not share persistent Run lifecycle, approvals, or activity streams.

OpenSeal's health endpoint returns a fixed response and cannot prove that the database, worker, or model provider can actually complete tasks, making it a weaker means than a capabilities check.