OpenSeal: An Open-Source AI Agent Platform

Mahendra Navale — Fri, 25 Sep 2026 20:08:11 +0000

You can now use OpenSeal under the Apache License 2.0. It handles the work that grows around an AI agent: saving progress, waiting for a person to review an action, and picking up after a process stops.

You can start with one Go binary. It runs a background service, an HTTP API, and a terminal client. If you already have an app, you can use the core as a Go library inside it.

Less code around the agent
Say you want an agent to draft a release note. Calling a model gets you part of the way. You still need to store the draft, track the task, and hold any sending step for review. Building those pieces again for the next agent adds work.
OpenSeal gives these tasks a shared structure. An Agent or Team owns an Objective, such as preparing a draft. A Run tracks the work toward that result. The Run moves in short steps called Turns. A Turn can call a Skill, which is an action the agent has been allowed to use.
The main flow is: prompt or event → Agent or Team → Objective → Run → Turn → Skill action.
Each stage is saved before the system acts on it. Workers claim Turns for a limited time. If a worker stops, its claim can expire and the work becomes available again. An approval is also a saved record, so waiting for a person does not depend on keeping one process alive.

A small local setup with clear boundaries
The standalone service uses SQLite for state and a local folder for artifact content. The terminal client reads from the API and holds no authoritative state. Closing the client does not stop work in the background.
Clients can ask GET /api/v1/capabilities what the running service supports. Features depend on the storage, workers, and other components that have been connected. This lets the client show what is actually available. For larger deployments, a Go host can embed the core and use the PostgreSQL store. PostgreSQL is not a setting that can be switched on in the standalone service.

Using multiple LLMs through a gateway
An LLM gateway gives an app a shared path to model providers. A team can use that layer to manage access to multiple large language models without putting each provider connection into the app itself.
OpenSeal documents an OpenAI-compatible endpoint for workforce authoring, which turns a prompt into a proposal for agents, teams, and their skills. That endpoint can point to a compatible LLM gateway. The model path is then: OpenSeal workforce authoring → compatible gateway → model provider.
The setup needs an endpoint, a credential reference, and a model name. A gateway can make multiple models available behind that endpoint, subject to its own support and setup. The documented OpenSeal configuration selects one authoring model; it does not describe automatic model choice for each task. Routing and fallback should be checked in the gateway you use.
You can try another supported model through the gateway while keeping the same task records and review steps. Check the gateway rules when you make the change.

Built-in governance supports compliance work
Governance means setting rules for what the agent may do and how decisions are reviewed. In OpenSeal, registering a Skill does not give every agent permission to use it. A binding grants that Skill to a specific Agent or Team deployment.
If policy requires approval, the action stops at a saved checkpoint. State changes and their activity events are written in the same transaction. This keeps the activity feed in step with the work it reports. Credentials are resolved for an action when it runs; secret values are kept out of saved state and prompts.
These are useful building blocks for compliance work. They are not a complete compliance system. The standalone API has no built-in login, request authorization, or TLS. A host or fronting proxy must supply those controls. Local approvals all record user:local, so a deployment that needs to identify each reviewer needs a host that authenticates people.

Project management tied to the work
OpenSeal includes projects, objective portfolios, and run controls. Projects group objectives and connect them to source monitoring and governed outreach. Run states show why work has stopped, such as waiting for approval, an event, or another agent.
Teams can pause, resume, cancel, or intervene in a Run. That gives developers a way to manage agent work within the same system that runs it. Pausing an Objective stops new Runs; it does not cancel work already in progress.
In the release-note example, a project could hold the draft objective and the sources it watches. A sending action could wait for review. You would still need to connect the right Skills and host controls to build that workflow.

Inspect the code and start small
The source is open so you can read how these parts work before you depend on them. You can also change the code under the project license.
Start with the repository setup guide and one local objective. Inspect the advertised capabilities, connect the needed model service, and test a small workflow before adding more work. If you use the separate HCL runbook command, note that it does not share the durable Run lifecycle, approvals, or activity feed described above.
Source code and setup guide: https://github.com/axiom-studio/openseal

DEV Community: Mahendra Navale

OpenSeal: An Open-Source AI Agent Platform