Automations

An automation is a defined agent job that runs manually, once at a chosen time, or on a recurring schedule. Use one when the instructions and trigger are stable enough that each occurrence can be reviewed as the same kind of work.

Creating an automation without selecting a project gives it an unlisted project. Selecting a listed project lets the run use that project's instructions, memory, files, skills, and connector access. Workspace connectors are available to either kind of project by default; turn off any connector the automation should not use. You can change the project for future runs; historical run sessions remain in the project where they executed.

An automation defines

• the job instructions;
• an optional description that explains the operational purpose;
• the project context and capabilities used by future runs;
• model and reasoning settings;
• a manual-only, one-time, daily, weekly, or other supported recurring schedule;
• enabled or paused state;
• optional execution guardrails such as maximum steps and runs per day;
• run history, last result, and next due time.

Every fire creates an independent automation session. Alongside the selected project context, a run receives one bounded excerpt of the latest eligible run's final result and a source reference. Previous instructions, tool transcripts, and subsequent review conversations are not replayed. Assigning a coworker never imports its persistent conversation, private memory, or credentials.

People and result handovers

Select Manage team to see the current members. Use Add people or agents… to search for someone to add; unselected directory entries stay in the picker. Remove members with the remove button on their row. The dialog keeps Cancel and Save changes visible while the member list scrolls. Open Contact settings to choose an optional person for questions and failures. An unassigned routine is valid. Assignment records responsibility and result recipients; it grants no project access and does not change the creator used for execution credentials and billing.

Each new run snapshots its assignments. Its first completed outcome produces a short handover without another summarizer model call and immediately queues one internal notification per subscribed agent, including successful, failed and canceled runs. The agent does not need a new human message to pick it up. Keep informed, the default, asks for a brief acknowledgement unless you have already given the agent a standing instruction to follow up on those results. Act on findings asks the agent to assess actionable results and follow up under existing permissions and approval rules. Pickup normally starts on the next scheduler check, within about 30 seconds; paused agents, active work, access restrictions or budget limits can delay it. The notification supplies a bounded result excerpt and exact run reference for optional deeper inspection.

When a run has assigned coworkers, it is told who will receive its result automatically. It returns its findings and leaves follow-up to those coworkers; it cannot discover or message another agent directly.

The automation does its independent job; the receiving agent carries out your authorized follow-up using its own context and tools, such as its email tools. For example, ask the agent to email you a summary whenever a particular automation finishes. The agent can save your standing instruction in its own project instructions, scoped to that agent and automation, and choose Act on findings for future handovers. The automation does not need to be rewritten to use the agent's mailbox. An existing standing instruction can also authorize follow-up while the subscription remains Keep informed. Receiving a result or a wakeup alone never grants permission to send messages, publish, or take other external actions; existing approval requirements still apply.

An agent can follow an accessible automation, choose Keep informed or Act on findings for itself, and stop following. These changes affect only its own notifications. People can manage the same settings in Manage team. Stopping notifications suppresses pending automatic pickups and attention wakeups; it does not erase already received results or stop work already running. Following again does not replay canceled notifications.

Older reminders saved as ordinary agent wakeups need to be canceled separately in the agent's scheduled wakeups.

A completion notification delivers a small batch of authorized result excerpts in the agent's internal conversation. Ordinary attended turns can also pick up pending excerpts. Any persistent agent with the automation tool and appropriate conversation access can inspect completed run results on demand, whether attached or not. Use the automation tool to search definitions, list runs, and read bounded result pages. The agent’s Automations panel, below Memory, shows its routines and recent findings. Confirmed handovers are recorded once in the receiving conversation as a small activity entry with an Open run link; result details stay in the run. The entry remains in retained conversation history if the agent later leaves the automation team. These display entries do not add result details to the agent’s context. Attended workspace turns receive a small authorized roster without run histories. External channel turns and delegated turns do not receive these handovers. Automatic excerpts are shared only when the coworker conversation's readers can also access the source result. Otherwise the result remains available in its original run.

Adding someone applies to future runs; old runs retain their original recipients. Removing an agent also stops its pending automatic notifications. Runs created before result handovers were available have no recipient snapshot.

Agents and other workspace runs can discover and inspect an accessible automation. With edit permission, they can update its name, description, instructions, enabled state, or schedule. An agent that only has permission to view it can inspect its results and manage its own subscription. Editing changes the definition for future runs; it does not start a run or rewrite historical sessions.

Receipt and run outcome are separate

An automation can complete successfully while its handover is still waiting for an agent. A receipt confirms that the agent worker started with the compact handover in its input; it does not confirm that the agent reviewed the result, understood it, or acted on it. Each assigned agent has a separate receipt. Dispatch alone remains unconfirmed, including older deliveries without confirmation evidence. Delivery does not rerun the automation or change its original outcome. Reading a result on demand is separate from automatic handover delivery.

The detail page shows one Latest run with its execution status and a short result excerpt. The recipient's avatar and linked name identify who receives the result. Waiting for Clay to pick it up means Clay is assigned but has not received the handover yet. Received includes the confirmation time. Each recipient has its own state, and an older dispatch without confirmation remains Unconfirmed. A run with no agent shows No agent assigned and remains available to people with access.

Open a run to see its recipients directly beneath the result. Select Nudge Clay to request one pickup of that specific run, even when newer runs exist. Nudge sent means the request was accepted; Waiting for Clay to pick it up remains until receipt is confirmed. The nudge starts or queues one agent turn and uses that agent's model budget. Repeated clicks reuse the same request. It does not rerun the automation, change the schedule, or change the agent's subscription. Paused agents must be resumed first, and current access and budget rules still apply.

If the pickup is canceled or can no longer proceed, Nudge stopped replaces the waiting message. The result remains available for the agent's next eligible turn; selecting the nudge again does not start another turn. Received always means the agent has confirmed pickup, even if that turn later stops.

The agent receives a compact excerpt with a link to inspect the result more deeply. The automation runs independently of the agent's conversation context. Viewing recipients never wakes an agent, and a nudge does not authorize external messages or publication.

Latest run and history

Latest run follows the newest execution, including work still running. History lists earlier executions without repeating their reports. Each entry shows its run outcome and agent handovers. Select Open run or Open to inspect the full result in that run's conversation. Loading more history does not change which run is featured.

A running execution shows Result pending until its own result is available. An older run with no recipient snapshot shows No handover recorded. If handover details cannot be loaded, use Retry; the run can still be opened.

Create and test an automation

You can ask an agent to propose an automation while chatting with it in d5s. Review the instructions and schedule in its suggestion, then select Create. The confirmation is shared with teammates: reopening the conversation or confirming the same suggestion again opens the same automation. The originating agent follows it with Keep informed and receives a short creation reference. The automation still runs with its own instructions and project context.

An older suggestion without a shared confirmation record may ask you to request a new suggestion. This avoids creating a duplicate when an earlier confirmation was stored only in someone's browser. You can still dismiss the old card for everyone.

Write instructions that make one occurrence self-contained: identify the inputs to inspect, the decision or artifact to produce, the destination, and what should happen when there is nothing to report. Review the inherited workspace connectors and turn off those the project does not need.

Start with Manual and use Run now while refining the definition. After the output is reliable, add a one-time or recurring schedule. The manual run uses the same definition and execution path as a scheduled run, so it is a meaningful test.

Each accepted automation run invokes the configured model.

Prefer an agent when responsibility is ongoing

Automations optimize for a repeatable job with independent run records. Agents optimize for a persistent role and conversation. If the work should notice context, decide what responsibility is due, and continue a relationship across check-ins, staff an agent instead. If the only useful result is a maintained view, consider a dashboard.