Let’s trace one task through OpenSeal. Suppose an agent is preparing a draft and needs approval before an action can send it. We want to see where the task lives, how a worker gets its next step, and what happens while a person reviews it.
The example describes a workflow you can build with the right Skills and host setup. We will follow the saved execution path, then check the model and security settings it needs.
Follow the durable path
The main sequence is prompt or event → Agent or Team → Objective → Run → Turn → Skill action.
An Agent or Team owns the Objective, which states a desired outcome. The Objective produces a Run. A Run advances in Turns, and a Turn may call a Skill to act outside the model's reasoning.
The draft goal stays in the Objective. The Run records the attempt to reach it. If work has to wait, you can read that Run’s state without keeping the original API request open.
Use leases to recover work
A worker claims a Turn for a set time. That claim is called a lease. If the worker stops renewing it, the lease ends and the Turn becomes available again. Check this record when a worker stops mid-task.
Every stage is saved before it is acted on. Approval waits are saved too. This gives work and review a common place to live across process restarts.
Do not read this as a blanket exactly-once guarantee for external tools. Review each Skill's side effects and the service it calls. A restart test should check both the saved Run state and the external result.
Check capabilities before calling routes
Two OpenSeal services at the same version can expose different operations. The available surface depends on the store contracts, connected components, and complete configuration.
curl http://127.0.0.1:8080/api/v1/capabilities
Run creation needs a dispatcher. Approval resolution needs an authorizer. Workforce authoring needs a complete model endpoint, credential, and model name. A missing capability is not merely hidden in the client; the corresponding operation is not served.
This lets a thin client work against a local service or a larger embedding host. The terminal client reads what the server advertises and does not own authoritative state. Closing it leaves durable work running.
The health endpoint is a weaker check. Its fixed response does not prove that the database, workers, or model provider can complete your task.
Keep orchestration state explicit
A Run can wait for a dependency, another agent, an approval, or an inbound event. These are different states because they need different responses. Waiting for another Run to finish is not the same as waiting for a person to decide.
Agents can ask each other for work through saved requests. The exchange moves through creation, response, completion, and optional completion review. Because those records are stored, the request can outlive the Run that raised it.
Agent and Team definitions have saved versions that do not change. Deployments can switch versions, so they can roll back to an earlier one. A proposed change goes through proposal, review, decision, and activation as separate steps. Saving a decision does not activate the change.
Govern actions at the Skill boundary
Registering a Skill makes its definition known. A binding grants it to an Agent or Team deployment. Team grants and member grants are separate.
When policy requires review, the action call stops at a durable approval checkpoint. A missing approval authorizer does not become permission to approve automatically. In local mode, the standalone operator flag enables local decisions and requires a loopback address.
Activity events are saved in the same transaction as the state changes they describe. Credential values are resolved when an action runs and kept out of saved state, prompts, and the terminal client.
The host boundary remains important: the standalone API supplies neither authentication nor request authorization nor TLS. A host or proxy must add them. Local approval records use user:local, so they cannot tell you which human clicked approve.
Put model routing in the right layer
Workforce authoring accepts an OpenAI-compatible endpoint. It can point to a compatible LLM gateway that exposes multiple models. The path is OpenSeal authoring → gateway → model provider.
The documented authoring setup selects an endpoint, a credential, and one model name. That is not evidence that the core automatically picks a different model for every task. A gateway's routing and fallback rules must be configured and tested separately.
This boundary keeps provider access apart from the durable work model. To test another supported model, change the model setup and compare the result while checking that the proposal still follows the review and apply process.
Know which execution path you are using
The standalone service uses SQLite. PostgreSQL is available through the Go embedding layer, not as a supported standalone storage setting. Projects group objectives for source monitoring and outreach, and Run commands let a team pause, resume, cancel, or intervene.
OpenSeal also has a separate HCL runbook path through openseal run. It runs a typed graph in one process and does not share the durable Run lifecycle, approvals, or activity feed. Do not assume that a runbook command inherits the guarantees described for the durable core.
A small evaluation plan
Now test the draft workflow. Read capabilities, connect the needed worker, and create one small objective. Watch its Run and Turns. Try an allowed action, then an action that needs review. Restart while that review is pending. Check both the saved approval and anything the action changed outside OpenSeal.
Write down the state before and after the restart. That comparison will tell you whether the task recovered as expected and where you need another test.
Source and setup guide: https://github.com/axiom-studio/openseal
Top comments (0)