Workers

A Worker is a scoped, audited identity you hand an AI agent instead of your own keys. It can read your infrastructure and propose changes you approve - and it can never delete resources or read your secrets. You give a Worker an objective and orkestr runs the agent for you - on demand, on a schedule, or in reaction to an event - driven by your own model. Every action is recorded.

The idea

Handing an agent your API key means handing it the power to delete everything and read every secret. A Worker is the safe version of that handoff: a named identity with a role, an approval gate, and a complete audit trail.

What a Worker can and cannot do

Every tool an agent might call falls into one of four tiers:

Read - projects, logs, metrics, deployment history, and the project's source code (read-only). Allowed freely. The git credential stays server-side - a Worker reads the code, never your token.
Reversible - working in an isolated environment. Allowed for roles that permit it.
Gated - irreversible actions like a deploy, a rollback, or opening a pull request. These are never run directly; they are queued for your approval. A worker proposes the change (for a PR, it reads the code and submits the edits); orkestr only commits and opens the PR after you approve, using your git credential in the control plane - never in the runtime.
Never - destructive or secret-revealing actions (deleting a project, reading environment variables, rotating keys). Permanently unreachable for a Worker, regardless of role or configuration.

Roles

A Worker carries exactly one role. Two presets ship today:

Observer - reads non-secret state, and nothing else. Best for investigation and monitoring.
Maintainer - reads, works in isolated environments, and can propose a deploy or rollback. Proposals are queued for your approval; it still cannot delete anything or read a secret.

Create a Worker

In the console, open Workers and choose New worker. Give it a name, pick a role, and optionally add standing instructions. A Worker runs on orkestr's hosted runtime. When it calls a gated tool it gets back a pending result and waits for your approval, rather than acting.

Run a Worker

Give a Worker an objective and orkestr runs the agent loop for you in an isolated environment, driven by your own model.

Add a model key once under Workers (bring your own - it is stored encrypted and used only to drive your runs).
Press Run on a Worker, describe the objective, and it works on its own: inspecting your infrastructure, reasoning, and proposing changes.
If it proposes a gated action, the run pauses at pending approval until you decide.

Skills

A Skill is a named playbook you attach to a Worker: a short description plus a markdown body telling it how to approach a kind of job. The worker sees the descriptions of all its skills at all times and loads a body only when the objective calls for it, so a large playbook does not inflate every step of every run. Mention one explicitly by typing /its-slug in the objective.

A skill is instructions, never permission. It shapes how a worker works and can never widen what it may do - the role and the approval gate apply exactly the same whatever a playbook says.

Presets

You do not have to start from a blank page. A curated catalog ships with the platform and installs in one click:

Deploy triage - finds the failing pipeline step, reads the right log, and reports a probable cause with the evidence for it
Security reviewer - image CVEs, non-production environments reachable on a public domain, secrets committed to the repo, containers running as root
Cost optimizer - idle environments, oversized containers, stale images, add-ons and functions nobody uses
Post-deploy smoke check - confirms a deploy that reported success is actually serving, and compares the error rate against the window before it
Docs writer - finds where the README disagrees with the code and opens a pull request fixing only that

Installing one copies it into a skill you own. Edit it, rewrite it, or delete it - it is yours from that point, and it does not silently change under a worker that is running it if we later revise the preset.

Memory

A worker remembers things between runs. It writes its own notes - short, keyed facts it decided were worth carrying forward - and reads them back automatically at the start of every run. Without this a worker's hundredth run begins exactly as ignorant as its first.

It writes them itself; you do not. What you can do is read every one and delete any of them, from the worker's page. That is deliberate: these are the worker's beliefs, and a belief you cannot inspect is one you cannot trust. If you want to tell a worker something, use its instructions or a skill - those are yours to write.

Keyed, so it can correct itself. Re-using a key revises that memory rather than adding a second, contradicting one.
Capped at 25 entries of 400 characters. Everything it remembers is included in every step of every run, and you pay for those tokens on your own model key. At the limit it must forget something before it can keep something new - it will not silently discard the oldest.
Never expands what it may do. A memory is a note, not an instruction and not a permission. The role and the approval gate apply exactly the same whatever is written there.

A worker can be told things by the code it reads

A worker reads pull requests, files and logs, and it decides for itself what to remember from them. So content it reads can end up in its memory. That can make it believe something wrong; it can never make it do something new, because permissions come from the role and never from a memory. If a memory looks wrong or you do not recognise where it came from, delete it - the worker's page shows every one.

Approvals

Gated actions queue in the console under Pending approvals, showing the tool and its arguments. Approve and the action runs; deny and it never does. The approval card shows the structured request, not free-form agent text, so the decision is always yours to make on the facts.

An approval is an object, not just a dialog: you can list them, read one, and approve or deny over the API as well as in the console, and a decided approval keeps its record of who decided it and what the action returned. See Approvals for the lifecycle and the endpoints.

An approved action is recorded as the worker's action, not yours - your decision is recorded separately, on the approval. So the activity log shows which worker did something and the policy role it acted under, and "a worker deployed this, a human allowed it" stays two distinct facts.

Run history

Every unattended run is recorded with its full transcript - the model's reasoning, every tool call, every result, and the outcome. The Run history table on the Workers page is your complete, reviewable record of what your agents did. Audit is not an add-on; it is the point.

The security model

Workers assume the agent can be manipulated by the data it reads (logs, tickets, repositories). The boundary does not depend on the agent behaving:

Destructive and secret-revealing tools are unreachable, enforced before any policy lookup.
Irreversible actions always require a human decision.
Unattended runs execute in isolated, EU-hosted environments with a per-run, short-lived token.
Personal API tokens and browser sessions are unaffected - only Worker tokens are gated.

See the Workers overview for the product tour, or the MCP server docs for the full tool surface.

Reading with an agent? This page is also plain markdown at /docs/workers.md, and the full docs index lives at /docs/llms.txt.