Skip to content

Work that runs for weeks

Write a chain of steps for Operator and your team once, with the dates, sign-offs and events between them, and it runs for days or weeks after you release it.

Talk to a human$npx @allocator-one/operator
operator — larkspur
operator — larkspur

Write a plan once

Describe the work in a file, the API or a chat, and the plan arrives held, with an estimate, until someone releases it.

operator — larkspur

Waits, retries and long steps

A plan runs as long as the work takes, through dates, sign-offs, fund events and the odd failed step.

CLI & MCP

Run plans from your shell

Keep plans as files next to everything else you version, and create, release, hold and tick sign-offs from your shell or your agent.

operator — zsh

  • # Create a plan from a file, held

    $operator plan create --file q3-close.yaml

  • # Every step, its status and why it isn’t ready

    $operator plan show 4f2a91

  • # Change steps or budgets; edited steps go back on hold

    $operator plan edit 4f2a91 --file changes.yaml

  • # Release it with a budget

    $operator plan release 4f2a91 --spend-budget-cents 20000

  • # Pause every step

    $operator plan hold 4f2a91

  • # Tick a sign-off (unsatisfy to untick it)

    $operator gate satisfy FUNDOPS-212 valuations-signed-off

Your agentoperator · MCP
  • plan_createCreate a held plan
  • plan_showSteps, status and waits
  • plan_editChange steps or budgets
  • plan_releaseRelease with a budget
  • plan_holdPause the plan
  • gate_setTick or untick a sign-off

Install with npx @allocator-one/operator · add it to any MCP client with operator mcp

How plans behave

A plan is steps, their order, what each waits for and a budget, and these rules keep it predictable.

Up to 100 steps
A plan holds up to 100 steps, grouped however you like. It’s created whole or rejected whole, with every problem listed by step.
Groups complete when their steps do
Only the steps at the ends of the tree do work. A group completes when everything in it has, and so does the plan.
Cancelled steps block what depends on them
If a step is cancelled, everything waiting on it keeps waiting. Nothing downstream runs on work that never happened.
Only Operator runs its steps
A step meant for Operator can’t be claimed by a person, or by an agent acting as one. Hand it to your team by changing who runs it.
One room per plan
Operator works in the plan’s own room, with the person who released it and the collaborators they named. Steps carry status and links, never what Operator read.
Plan work never delays day-to-day jobs
Each plan has a budget inside your organization’s monthly cap, and plan work runs in its own lane, so day-to-day jobs never queue behind it.

More on Operator

Four views of Operator

Each page covers one part of how Operator works.

Common questions

  • Yes. Operator’s steps live in your organization’s Operator team, and your people’s steps stay in their own teams, all inside one plan.

  • Yes. Ask in chat and Operator drafts it. You approve the draft like any other change, it’s created held, and someone releases it when it’s right.

  • The plan’s permission to run belongs to them, so it stops cleanly and waits. Anyone with the right access releases it again and is responsible from then on.

  • Hold the plan. Nothing new starts until someone releases it again, and every step picks up where it left off.

  • Whoever owns a step hears when it’s ready, approvers hear when a change needs them, and the plan’s owner hears when a branch stops.

  • Release shows an estimate from the steps, their retries and continues. The plan can’t spend past its own budget or your organization’s monthly cap.

Release your first plan

Put steps for Operator and your team in one plan, and release it when it’s right.

Talk to a human