DEV Community: Mac

How OpenSeal's Agent Architecture Works

Mac — Mon, 12 Oct 2026 06:12:52 +0000

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

AI Workflow Automation for Healthcare: Secure, Auditable Health Management

Mac — Thu, 01 Oct 2026 22:12:55 +0000

Healthcare teams spend much of their day moving information between systems: reviewing referrals, checking documents, preparing summaries, coordinating appointments, and following up on incomplete requests. Every handoff takes time. Every handoff also creates a responsibility to protect patient information and preserve an accurate record of what happened.

AI workflow automation can help teams manage this work. Its value depends on more than the quality of a generated summary. Teams need to control what information the system can access, which actions it can take, and when a person must review the result.

For Axiomstudio AI, the guiding principle is straightforward: build healthcare workflows around clear permissions, visible activity, and accountable decisions.

Why scaling AI in healthcare remains difficult

Moving from a pilot to everyday use introduces more than additional users. Each department brings different data, systems, approval requirements, and operational risks. Controls that depend on one project team’s memory become harder to apply consistently across an organization.

Recent evidence highlights the gap between adoption and oversight. A September 2025 ASTP report found that 71% of responding U.S. non-federal acute care hospitals used predictive AI integrated with their electronic health record in 2024, up from 66% in 2023. Evaluation and monitoring were less consistently applied across all or most models, and smaller and rural hospitals lagged in adoption. These findings concern predictive AI, rather than measuring generative AI adoption, but illustrate the governance challenge facing healthcare organizations as AI use expands. ASTP hospital AI adoption and governance report.

AI workflow compliance means translating applicable obligations and organizational policies into controls that operate throughout a workflow. The following are practical ways to address common scaling barriers:

Scaling challenge	How workflow compliance can help
Fragmented data and integrations. Records, referral documents, and operational systems can disagree or omit critical context.	Require validated inputs, source references, patient-matching checks, and approved integration paths. Route incomplete or conflicting records for review before downstream actions. These controls contain data-quality problems while teams fix the underlying systems.
More opportunities to expose patient information. Additional models, tools, and vendors create more places where sensitive data may travel.	Maintain an inventory of approved services and data flows, enforce scoped access and destination restrictions, and review vendor responsibilities and applicable business associate agreements before enabling new connections.
Inconsistent output quality. A workflow that performs well in one setting may fail with a different document format, population, or clinical context.	Require local validation before rollout, source-backed review, evaluation across relevant patient groups, and ongoing monitoring. Define thresholds for escalation or suspension when performance deteriorates.
Unclear ownership and review bottlenecks. More AI-generated work can overwhelm reviewers or leave exceptions without an owner.	Assign accountable workflow owners, use review requirements proportionate to risk, and monitor queue age and correction rates. Give staff clear escalation routes and training on when to reject an output.
Changing models and integrations. An update can alter behavior after the initial approval.	Version models, prompts, policies, and integrations; require regression evaluation and approval for material changes; and maintain a tested rollback path.
Growing evidence and operational costs. Teams may repeatedly reconstruct events or repeat the same governance work for each deployment.	Capture protected execution records automatically and reuse approved control templates. Measure review effort, exception handling, and cost per completed workflow to test whether reuse produces real savings.

Generative AI adds a particular reliability risk: plausible but incorrect content. NIST identifies confabulation, data privacy, harmful bias, and human reliance on AI among the risks organizations should manage. Source references, independent checks, and human review help reduce exposure; they do not guarantee a correct result. NIST Generative AI Profile.

The practical benefit is repeatability. Once an organization establishes a reviewed approach to access, approvals, logging, and change management, new workflows can build on that foundation. Each still needs validation for its intended use. Compliance controls support scale alongside investment in integration, staffing, and clinical quality.

Start with a bounded workflow

A useful starting point is a repetitive administrative process with a clear owner and a measurable outcome. Referral intake is one example. An AI-assisted workflow can extract information from an incoming document, identify missing fields, and prepare a summary for a coordinator to review.

Other candidates include preparing appointment communications from approved templates, organizing documents for authorization requests, and assembling information for care-coordination teams.

Even administrative automation can affect access to care. Define the limits before deployment: which documents are in scope, what counts as a complete request, which exceptions need review, and who owns unresolved cases. Decisions that affect diagnosis, treatment, or clinical urgency need separate clinical validation and appropriate professional oversight.

Make security part of every step

Security should shape how information enters, moves through, and leaves the workflow.

Give each service a defined identity and narrowly scoped permissions. A component that prepares a referral summary may need to read an approved document set; it does not automatically need permission to modify the patient record or contact the patient.

Enforce those boundaries in the application and integration layer. A prompt telling an AI model to avoid unauthorized actions is not an access-control mechanism. Tool permissions, destination restrictions, and policy checks should determine what actions are possible.

Practical design measures include:

Send only the information needed for the specific task to an approved model endpoint.
Protect data in transit and at rest, and manage credentials outside prompts and documents.
Separate patient information from routine debugging and analytics wherever possible.
Review provider terms for retention, training use, subprocessors, and incident handling.
Treat instructions embedded in uploaded documents as untrusted content, not authority to call tools or disclose information.

For U.S. organizations subject to the Health Insurance Portability and Accountability Act (HIPAA), the Security Rule establishes administrative, physical, and technical safeguards for electronic protected health information, including access and audit controls. An AI deployment must fit the organization’s broader risk analysis and security program. HHS Security Rule summary.

Vendor arrangements matter too. HHS explains that a cloud provider maintaining electronic protected health information can be a business associate even when it cannot decrypt the data. Applicable business associate agreements and a review of shared responsibilities belong in the deployment process. HHS cloud computing guidance.

Extend HIPAA governance to the software development workflow

The development process also deserves attention. AI coding tools may encounter patient information in test fixtures, support logs, or API examples while building healthcare applications.

Axiomstudio’s HIPAA compliance guide describes how VibeFlow supports governance of AI coding activity through role-based access, execution logs and commit tracking, security review gates, enterprise authentication, and gateway data-loss-prevention controls. The guide maps these capabilities to HIPAA safeguard categories, giving engineering and security teams a starting point for reviewing their development workflow.

That scope matters: governance of AI-assisted software development complements controls in the healthcare application itself. Organizations still need to validate their configuration, contracts, policies, and operational practices. HIPAA compliance also does not establish an AI system’s clinical accuracy or fitness for a particular medical use.

Build an audit trail that answers real questions

An audit trail should help a reviewer reconstruct an event: what started the workflow, which information it used, what the AI produced, who reviewed it, and which action actually occurred.

A useful design records a workflow identifier, timestamps, the initiating user or service, source references, model and workflow versions, policy-check outcomes, approval events, and the final system response. Record failures and blocked actions as well as successful ones.

Distinguish a proposed action from a completed action. If a coordinator approves a record update but the destination system rejects it, the history should show both events. A generated response is not evidence that an external system changed.

Logs also require protection. Prefer metadata and controlled references where they provide sufficient evidence, restrict access to sensitive content, and establish retention rules appropriate to the organization’s obligations. Logging every prompt and document indefinitely can create another unnecessary store of patient information.

These are implementation recommendations; the presence of an audit log alone does not establish compliance.

Put human review at consequential decisions

Human review works best when reviewers have enough context to make a decision. Show the original source beside the generated summary, highlight missing or conflicting information, and make corrections easy.

Route ambiguous patient matches, unsupported statements, incomplete documents, and out-of-scope requests to a responsible person. Do not rely solely on a model’s self-reported confidence to decide whether a case is safe to automate.

Define what happens when nobody responds. Each review queue needs an owner, an escalation path, and a manual fallback so unresolved work remains visible.

Example: a controlled referral-intake workflow

The following is an illustrative design, not a claim about a deployed customer system:

Receive: An approved channel accepts the referral and assigns a workflow identifier.
Validate: Deterministic checks confirm required fields and route uncertain patient matches for manual review.
Prepare: AI extracts relevant details and drafts a summary with references to the source material.
Review: A coordinator verifies the draft, corrects errors, and approves the permitted next action.
Execute: A narrowly authorized integration creates the work item and confirms the result. Duplicate-prevention controls protect against repeated submissions.
Record: The workflow captures the review, changes, action result, and any unresolved exceptions in its protected history.

If an integration fails, the request stays visible for recovery. If a document is incomplete, the workflow creates a review task rather than inventing missing information.

Measure quality alongside speed

Evaluate the workflow against its previous process. Track completion time, reviewer effort, correction rates, unresolved exceptions, duplicate actions, and the completeness of audit records. Separate time saved by automation from work shifted into review queues.

Test with representative, appropriately protected examples before expanding access. Include missing pages, contradictory information, malformed documents, unauthorized requests, and system outages. Reassess performance when models, prompts, integrations, or policies change.

Start with one controlled workflow, establish evidence that it works, and expand only when its owner can explain both the benefits and the failure-handling process.

*Build with AI. Stay in control.
*
Secure, auditable health management requires deliberate choices about data, permissions, review, and recovery. The strongest workflows make those choices visible to the people responsible for operating them.

Planning your next healthcare automation initiative? Explore Axiomstudio’s HIPAA compliance guide and start the conversation with a specific workflow, its data boundaries, and the evidence your team needs to trust it. Build a repeatable control framework around that workflow, then use measured results to guide expansion.

OpenSeal: An Open-Source AI Agent Platform

Mac — 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
Documentation:https://docs.axiomstudio.ai/openseal