Automations

An automation is a job you describe once and run again whenever you need it, on your own agent: a dependency sweep, a style audit, a branch clean-up. You write what you want done in plain words, say how you'll know it worked, and choose how much the agent is allowed to change. Each run is recorded with its outcome, so you can see what your agents did every time.

Open Build → Automations in the project sidebar. Your agent does the work, so you need Pi, Claude Code or Antigravity CLI connected to DevSpec; see Connect your agent.

Create an automation

On the Automations page, choose New automation and fill in:

• What do you want done? (required): the instruction, up to 20,000 characters. Write it the way you'd explain it to a person, and describe the outcome rather than exact folders, so it works on any of your machines. For example: "Check my repos for out-of-date dependencies, update the safe ones, and tell me which need a closer look."
• Name (optional): leave it blank and DevSpec names it from what you wrote. Each automation in a project needs its own name.
• Tags (optional), up to ten.
• How will you know it worked? (optional): short checks, one per line (Add a line), up to 20. After each run, every line is checked separately, so keep them short and separate, like "every repo builds".
• Who can run this (optional): tick the coding tools (Pi, Claude Code, Antigravity CLI) allowed to take it, and optionally a model for each. Leave every box unticked to let any agent take it.
• What it's allowed to do: see the next section. It starts on Read and report only.
• Who is it for?: The project (the default) or Each person. See Who an automation is for.
• Let my agents run this: on an automation for the project, shown when you give it a schedule or a trigger, and ticked. Leave it ticked so it can go to your agents when it starts by itself. See Choose who it goes to.

Press Save automation. Saving never starts a run.

You can also ask for one in words. In a session, ask Dev to create an automation; Dev confirms with you before it saves. Or ask your agent in its terminal, and it creates it through its DevSpec connection.

Every automation belongs to the project. Everyone on it sees every automation, every run and every result, so two people never end up running the same job without knowing. Contributors and Maintainers can create automations, press Run and switch themselves on; Reviewed Contributors and Viewers can see them and discuss them, but can't create, run or switch on. A run gives an agent access to the project's code, so choose its permissions before running it. An automation's creator, or a Maintainer, can edit, pause, archive or restore it. Search (Search automations…) covers the names, instructions and tags of every automation in the project.

On an automation for the project, one run goes at a time: while a run is queued, waiting or running, pressing Run again says it's already going. On an automation for each person, that holds for each person's own runs: your run and a teammate's can go at once.

Who an automation is for

Every automation is for one of two things, chosen under Who is it for?:

• The project: one run covers everyone, on whichever agent is switched on for it. Use it for work about the project, such as investigating a failed deploy or tidying merged branches: it only needs doing once, whoever does it.
• Each person: everyone runs it for themselves, on their own agents and their own schedule. Use it for work about each person's machine, such as cleaning up worktrees or updating tools: your run does nothing for a teammate's computer.

The card says which under For. An automation for each person can't start when a deploy fails, and has no shared schedule: each person sets their own. See Automations for each person.

An automation's creator, or a Maintainer, can change who it's for in Edit. The form says what the change does before you save:

• To each person: everyone switched on for it gets their own copy of its schedule, on their own agents. If it starts when a deploy fails, or its schedule waits for a condition, remove that first; saving is refused until you do, and nothing else in the form is saved.
• To the project: everyone's own schedule ends, and each of them gets an "Automation now for the project" notification. It then has one shared run, and you're switched on for it.

Choose what an automation is allowed to do

Every automation has one of three levels under What it's allowed to do:

The level is part of the instruction your agent receives, and DevSpec checks each run's report against it: a run whose report shows the agent went further than allowed is marked Failed, with the reason. DevSpec doesn't sandbox your machine, so choose the lowest level the job needs, and use an agent whose own permission settings you trust.

Changes to DevSpec's agreed records still follow the project's approval rules. Memories and documents created by an automation, and changes that overrule agreed content, are saved as proposals rather than becoming agreed knowledge automatically. See Review.

Run an automation

Choose Run on the automation's card. DevSpec asks Which of your agents runs it? and offers:

• your agents that are connected now, including agents busy in another session;
• Wait for an agent, which reserves the run for the next of your agents that's free.

When you pick an agent, the run is sent to it and it starts in a moment. If none of your agents are online, choose Wait for an agent and start one; the run begins when it connects. A run nobody takes stays waiting until you cancel it.

While a run is queued, waiting or running, Run turns into Cancel. Canceling a run that has already started doesn't stop your agent mid-task; stop it in its terminal if you need to.

You can also ask Dev in a session to run an automation. Dev doesn't do the work itself: it reserves the run for one of your agents, the same as Wait for an agent.

Your agent only works on a run someone pressed Run for, asked Dev to start, or scheduled (see below).

Run an automation on a schedule

This section is about automations for the project. On an automation for each person, everyone sets their own schedule instead: see Automations for each person.

A project Maintainer can give an automation a schedule. On its card, choose On a schedule and set:

• How often: Every 15 minutes, Every hour, Every day or Every week.
• At: the time, for daily and weekly schedules (09:00 unless you change it).
• On: the day, for weekly schedules (Monday unless you change it).
• Time zone: filled in from your browser. To change it, type a time zone name such as Europe/London or America/New_York.
• Only run when: Every time: no condition, or Only when work is built but unconfirmed, which runs when the project first has implemented work waiting to be verified rather than on every tick.
• If no agent is free, wait for the next one instead of skipping.

The card then shows the schedule, when it runs Next, and Recent checks: each time the schedule came round, whether it ran or why it didn't.

At each scheduled time, DevSpec sends the run to an eligible agent that's free, meaning not in a conversation. Eligible agents belong to people who switched the automation on (see the next section), limited to the tools ticked under Who can run this. If none is free, that time is skipped, or, with waiting turned on, the run waits for the next free agent. A run that's still waiting when the schedule has come round twice more is dropped, so it doesn't hold up the next one. If the agent the run was sent to hasn't started within 15 minutes, DevSpec offers it to the next eligible agent.

A scheduled time that comes round while an earlier run of the same automation is still waiting joins that run rather than adding another.

Choose who it goes to when it starts by itself

When an automation for the project has a schedule or starts when a deploy fails, its card has a Runs by itself block:

• Runs by itself: on or off. Its creator and Maintainers have the switch; everyone else sees whether it's on. Off pauses it for everyone: schedules and failed deploys start nothing, runs that started by themselves and are still waiting are canceled, and Run still works. A Paused label shows next to its name while it's off.
• Let my agents run this: your own switch. A run that starts by itself goes only to the agents of people who switched it on, and only to agents ticked under Who can run this. The person who creates an automation starts switched on, and can switch off like anyone else.
• Goes to: everyone switched on, by name. If nobody is, the card says it won't go to anyone, and a run that starts by itself is recorded as not sent to anyone.

When a deploy fails, the agent whose change broke it is asked first, as long as its owner switched the automation on; otherwise it goes to someone else who did.

If someone raises what an automation is allowed to do, for example from Edit files and commit to Edit, commit and push, everyone else is switched off and gets a notification, because they agreed to less. The person who raised it stays on. Other edits leave everyone's switches alone.

This only covers runs that start on their own. Anyone who can press Run can still send an automation to their own agent.

Automations for each person

On an automation for each person, your schedule is how you switch on: there is no Let my agents run this. Its card has:

• Runs by itself: the same switch as on a project automation, held by its creator and Maintainers. Off pauses everyone's schedule at once, and Run still works.
• Your schedule: Set your schedule to have it run for you on your own agents: how often, at what time, on which day and in which time zone, as for a project schedule. Change or Remove it whenever you like; with no schedule, it runs for you only when you press Run. Contributors and Maintainers can set one; Reviewed Contributors and Viewers can't.
• Everyone else: each teammate who has a schedule or has run it, with their schedule (or Run only) and their last result, most recently active first, so you can see who it's failing for.

The state next to the name, the checks' marks and Cancel are about your own runs. A run started by your schedule goes only to your own agents, limited to the tools ticked under Who can run this.

If someone raises what it's allowed to do, everyone else's schedule is switched off and they get a notification. Each schedule is kept: its owner chooses Switch back on to agree to the new access.

Starters

When a project has a repository, the Automations page offers ready-made starters. A project Maintainer adds one with Add this automation, and is switched on for it. Adding it never starts a run, and each starter can be added once per project.

• Tidy up merged branches: deletes remote branches whose work is already merged, and leaves anything unmerged alone. Allowed to Edit, commit and push. Runs weekly on Monday at 09:00, once for the project, on one eligible agent.
• Clean up finished worktrees: removes worktrees on the machine it runs on whose work is already committed and pushed; anything unfinished stays. Allowed to Edit files and commit. It's for each person: the person who adds it gets their own schedule, weekly on Monday at 09:00, which tidies their machine. Everyone else sets their own schedule on its card, or presses Run to tidy theirs.

Each starter comes with its instruction and checks written out. The person who added it, or a Maintainer, can edit it like any other automation, and a Maintainer can change the schedule of a starter for the project.

See what an automation's runs did

Each automation's card shows its latest state (on an automation for each person, your own), such as Running now, Waiting for an agent, Ran (with when), Last run failed or Never run. Choose Runs to see its history, up to the last 50 runs.

The history shows every run of the automation, whoever started it. Each run shows its status (Succeeded, Failed, Running, Queued, Waiting for an agent, Blocked or Canceled), which agent ran it and whose it is, or that it never reached an agent, and Show details for:

• the agent's summary of what it did, or why it failed;
• each line of How will you know it worked? marked passed or failed, with the evidence;
• the output it captured;
• what it produced, such as commits, tasks, memories, documents or sessions, each linked.

When a run fails, the person whose agent ran it gets an "Automation failed" notification. When someone raises what an automation is allowed to do, everyone it switched off gets an "Automation given more access" notification. When an automation for each person is changed to one for the project, everyone whose own schedule ended gets an "Automation now for the project" notification. Discuss on the card opens a session about the automation, where you can bring in Dev or talk it over with your team without calling anyone.

Edit, archive and restore an automation

The ⋯ menu on an automation's card is there for its creator and Maintainers. Choose Edit to change any field, or Archive to stop using it. To stop it starting by itself for a while without archiving it, switch Runs by itself off instead. Archiving takes it off the page and stops it running; runs still waiting for an agent are canceled, while one already running is left to finish. Its run history is kept.

Archived automations appear under the Archived tab, which shows once you've archived something. Choose Restore there to put one back. Nothing deletes an automation.

What automations cost

Running an automation doesn't draw on your DevSpec balance: the work is done by your own agent, and its model usage is billed by its provider, as with anything else you ask it to do.

DevSpec charges your organization's balance only for:

• naming an automation you left unnamed, a small charge that appears on Settings → Billing → Transactions as Running your project;
• asking Dev to create or run one, which is an ordinary Dev reply in a session;
• Discuss with Dev (opening the room without calling anyone is free).

See Billing, usage and limits.