Worklet
Sign inGet started

An operational ontology for your organization.

Worklet holds the things your organization works with, the teams that work on them, and the links between them, as one typed model. People, apps, and AI agents change it only in the ways you define, and each sees only what they may.

Describe your incidents, machines, customers, or documents as object types. Define the actions that change them and who may run each one. Access is set on the records themselves, and chat, files, search, and agents all follow it. Self-host it in one Docker container, or use the hosted service.

Already have an organization? Sign in · Quickstart · API reference

What Worklet does.

An access model that is checked, not just tested.

The access rules are a formally verified model, not the code directly. Machine-checked statements about that model show, for example, that one organization never sees another's data, that a hidden folder hides everything below it, and that search returns only what you could open. The server is tested against the model, and Postgres row-level security keeps every organization's rows apart underneath it.

How organizations are kept apart · Users, teams, permissions

A web app for the people, an API for everything else.

People browse and edit objects in tables and calendars, change the model, apply actions from generated forms, and follow the audit log and the live feed. The web app uses the same API as your agents and your own apps, so it shows each person exactly what they may see.

The web app's object table: incidents with their severity, status, assignee, and validation state

The web app · How it fits

One incident, an agent, an assistant, and a person.

A machine breaks down. An agent account reports and assigns the incident, a technician's assistant does the work through MCP, and a supervisor approves it in the web app. Each step is an action the organization defined, checked against who is calling and what the data looks like when it commits.

Walk through the example · Actions

The model changes while it runs.

Add a type or a property and use it at once. A new rule applies to every write at once and to stored objects in the background, with each object marked valid, invalid, or pending. Removing a property is instant, and its values never come back. Object types and actions keep every version, and each action application records the one it ran.

acme / ontology
object-type.jsonPOST /v1/ontology/object-types
{
  "api_name": "employee",
  "display_name": "Employee",
  "properties": [
    { "api_name": "name", "type": { "kind": "string" }, "required": true,
      "rules": [{ "rule": "length", "min": 1, "max": 100 }] },
    { "api_name": "email", "type": { "kind": "string" },
      "rules": [{ "rule": "email" }, { "rule": "unique" }] },
    { "api_name": "manager", "type": { "kind": "user_ref" } },
    { "api_name": "started", "type": { "kind": "date" } },
    { "api_name": "office", "type": { "kind": "geo_point" } },
    { "api_name": "badge", "type": { "kind": "string" },
      "rules": [{ "rule": "validator", "name": "luhn", "version": 2 }] }
  ]
}

Rules too specific for a schema run as Python in a sandboxed interpreter with no filesystem, network, or imports, at most 250 ms and 32 MiB per call.

Versions and schema changes · Custom validators

Use cases.

Each of these is usually its own app, with its own database, permission checks, and audit trail. In Worklet each is a model and a set of actions, used by the same people and agents under the same rules.

Hosted or self-hosted.

The same server either way: one Rust binary on Postgres, with the web app.

HostedSign up with your email address and create an organization. It gets its own address, such as app.worklet.org/acme, and nothing to install.Get startedSign in
Self-hostedOne Docker container runs the server, the web app, and Postgres, and keeps all its state in one directory. Bring an email provider when you go live.DockerConfiguration

What it is not.

Not an agent runner.
Worklet does not run agents or call models. Your agents connect over MCP or the REST API and are checked like anyone else.
Not a data warehouse.
Objects are JSON documents checked against their types, queried with typed filters. Run analytics elsewhere.
Not a sandbox for agent-written server code.
Isolation keeps a buggy handler inside its organization. Server code an agent writes needs review like any other change.
Not finished.
Access goes down to single objects and properties, but not along links, and property filters are not indexed yet. See current limits and measured performance.
Esc
↑ ↓ navigate↵ open