Deputies

Set up a job once and let Marshal do it again and again. A deputy is a standing definition that you, a team or the organization owns: a manifest, its own memory, and saved missions with what starts them. A deputy does not do the work itself. Every time one of its missions fires, it starts a run, so you can open, follow, message, take over and continue that work like any other run.

Available when your administrator enables deputies.

What you can do with it

Release notes every Friday. A mission on a weekly schedule reads the merged pull requests, drafts the notes, and asks the team lead to approve them before it posts.
Triage every new incident. A mission fires on each alert webhook, gathers logs and recent deploys, and sends the on-call engineer a heads-up with its summary.
A shared helper for the team. The Platform team owns a “Bump dependencies” deputy. Any team member launches it from the deputy page and gets a pull request back.

See it end to end: Nightly dependency upgrades and Triage alerts from your tools.

How it fits

Manifest. The deputy’s manifest is the environment every one of its runs gets. A deputy cannot run until one is attached. The manifest is the deputy’s whole reach: give it a manifest with exactly the access the job needs.
Missions. A mission is a named job with a saved prompt, inputs and a time budget. Each edit creates a new numbered version, and every run records the version that started it.
Triggers. A mission starts by hand, on a schedule, or when an event arrives from an installed package. See Schedules and triggers.
Owner. A person, a team or the organization. See Owners, teams and scope.
Memory. A deputy has its own context and memory documents. Its runs read and write those, not yours. See Memory.

Run or deputy?

	Plain run	Deputy
Best for	A one-off task you start yourself	Work that repeats or reacts, or needs a standing owner and memory
Started by	You: the web (“Ad-hoc run”), the CLI, an AI client through MCP, or the API	A person, a schedule, or an event, from a saved mission
Prompt	Typed each time	Saved and versioned as a mission, with inputs
Memory	Your personal context and memory	The deputy’s own context and memory
Owner	You	You, a team or the organization

Start with a plain run. When you find yourself repeating it, save it as a mission on a deputy.

Whose access a run uses

The trigger only decides when a run starts. It never adds access. The credentials always come from the manifest.

A trigger is a person, a schedule or an event.

The manifest’s owner decides which credentials a run gets. A team manifest uses the team’s credentials. An organization manifest uses the organization’s. A personal manifest uses that person’s.
A deputy binds a manifest at its own level or above. A personal deputy can use your own manifests, your teams’ manifests and the organization’s. A team deputy can use that team’s or the organization’s. An organization deputy uses only the organization’s. A team deputy can never run on one member’s personal credentials.
Marshal checks again at every launch. If a manifest moves to a different owner, a deputy that may no longer use it stops launching until someone binds a new one.
The same rule holds for every run and space. Whoever starts it, a manifest runs on its owner’s credentials. When those credentials reach the owner through a share, the person or deputy running it needs use of them too.

Who gets the questions

When a run needs a decision, the agent asks. The agent never chooses who is asked. Marshal picks the first match:

The people the mission names.
The person who launched the run.
The deputy’s owner. For a team or organization deputy, that is the person who created the deputy.

If the mission names someone who has left, nobody else gets the question. Questions appear on Home, on the run page, and in Slack when Slack is linked.

Lifecycle

State	What it means
Active	The deputy starts runs.
Suspended	The deputy starts no runs. Its schedules and triggers stay, but do not fire.
Archived	The deputy is hidden and stopped. Its missions and runs are kept, and you can restore it.

A draft mission can be tested with a dry run, which shows the exact prompt and creates no run. Activate the mission before a schedule or an event can fire it.

When a team is archived, its deputies are suspended. Restoring the team leaves them suspended, so you decide when each one starts again.

Deleting a deputy is permanent and is allowed only after you archive it. It erases the missions and every run, including transcripts.

Start from a playbook

A playbook is a ready-made deputy blueprint with its missions, suggested schedules and triggers, and the apps it needs. Browse them on the Deputies page, copy any mission, or set one up to get a working deputy in one step. The manifest you choose is the only access the deputy gets. See Deputy playbooks.

Deputies in depth: every setting, who can do what, and the CLI.
Deputy playbooks: start from a ready-made deputy.
Create a deputy and a mission.
Run a mission on a schedule or event.
Runs: what each firing gives you.
Use cases: ready-made deputy recipes.