Agentic Workers

.Worker v1

Define an agentic worker in one file

A .Worker file says what a worker does, which accounts it uses, what it’s allowed to touch, when it runs and who answers for it. You can read it, review it, version it and hand it to a client.

Open the viewer
weekly-pipeline.Worker
apiVersion: agenticworkers.com/v1
kind: Worker
id: weekly-pipeline
name: Weekly Pipeline Summary
 
job:
  summary: Summarize last week's closed deals every Monday.
  done_when: The summary is posted to team chat.
 
connections:
  - id: crm
    provider: hubspot
    via: composio
    auth: oauth
    required: true
    tools: { allow: [HUBSPOT_LIST_DEALS, HUBSPOT_GET_DEAL] }
 
policy:
  default: deny
  rules:
    - allow: [crm.HUBSPOT_LIST_DEALS, crm.HUBSPOT_GET_DEAL]
 
triggers:
  - id: monday-summary
    cron: "0 8 * * 1"
    run: { skill: crm-weekly-summary }
    deliver: chat

Why one file matters

An agent that works in a demo fails in production for ordinary reasons: an account was never connected, a token expired, a schedule was edited by hand, or it was allowed to do more than anyone intended. A .Worker file makes each of those visible and checkable.

The whole worker in one file

Job, model, instructions, skills, connected accounts, permissions, schedules and machine size. Today these live in a dashboard, a config file, a secret store and a scheduler, and nothing tells you when one of them changes.

Built for work you do for clients

Write a worker once. Each client gets an Assignment with their own accounts, their own approver and their own budget. The worker itself never changes between clients.

Checked before it runs

Secrets are vault references, never values. Tools are allow-listed per account. Risky actions need approval. A worker whose required accounts aren’t connected doesn’t start.

Reviewed like code

It’s plain YAML, so it lives in git. Every change is a diff someone can review, and the linter catches mistakes before anything is deployed.

One worker, every client

If you run agents for other companies, the hard part isn’t the agent. It’s keeping each client’s accounts, approvals and costs separate.

An Assignment deploys a worker for one client. The client connects their own HubSpot through an invite link, without an Agentic Workers login. Their operations lead approves risky actions. Spend stops at their daily budget. The next client gets their own Assignment, and the worker stays the same file.

How assignments work
acme.Worker
apiVersion: agenticworkers.com/v1
kind: Assignment
id: weekly-pipeline-acme
worker: agenticworkers/weekly-pipeline:2.1.0
team: acme-client
 
identity: { sponsor: ops@acme.com, billing: provider }
 
bind:
  crm: { owner: client, invite: { email: ops@acme.com, expires: 7d } }
 
budget: { usd_per_day: 15, on_exceed: pause }

How it works

  1. 1

    Write

    Start from an example or an existing worker. Any editor works; the format is YAML.

  2. 2

    Check

    Paste it into the viewer. It colors the file, formats it, and runs 27 checks on connections, permissions, schedules, secrets and machine size.

  3. 3In development

    Run

    Apply it to your Super Agent box. The platform confirms every required account is connected, then deploys only what changed.

Try it on a real worker

Open the viewer with the file for the agent that builds and ships this platform’s own code.

Open the example