Create your first automation
Define a repeatable job, test it through the real run path, inspect its history, and schedule it only when reliable.
Create an automation when one stable job should run independently and every occurrence should have its own history. Begin with a manual trigger; Run now uses the same definition and execution path as a scheduled run.
1. Define one occurrence
Open Automations and select New automation. Enter a clear name, an optional operational description, and instructions that make one run self-contained.
Good instructions identify:
- the inputs or systems to inspect;
- the time window or selection rule;
- the analysis or decision to make;
- the artifact or message to produce;
- where the result should go; and
- what to do when there is nothing to report.
Leave project context on Standalone when the job needs its own independent memory and files. Choose an existing project only when the job should use that project's instructions, files, memory, skills, or connector access. Standalone automations still receive an unlisted backing project so each run has a stable context and permission boundary. In both cases, workspace connectors are available by default.
You can also ask an agent in a d5s conversation to suggest a scheduled automation. Review its proposed instructions and schedule, then select Create. Creating is a shared decision: teammates see the resulting automation, and confirming the same suggestion twice does not create a duplicate. The agent follows the new automation with Keep informed. Its conversation history does not become the automation's context.
If an older card asks for a new suggestion, ask the agent to propose it again. Check the existing automation list first if someone may already have created that earlier proposal. You can dismiss the old card to hide it for everyone.
2. Keep the first trigger manual
Leave Frequency set to Manual. The model control shows the effective workspace runtime. With a workspace-managed Codex connection, every member and automation inherits the shared workspace default; a workspace Owner or Admin manages that choice under Settings → Models. A personal Codex fallback remains personal to you and uses your own model selection. When Codex is not active, catalog model choices can be pinned to this automation. Choose a model and reasoning level only when the workspace default is not appropriate.
Use Manage team before creating the automation to add people or agents immediately, or leave No team assigned when the automation should only keep its own result. Agents default to Keep informed, which notifies them when the run ends; choose Act on findings if an agent should also follow up on actionable results. The same Manage team control remains on the detail page, where you can also choose an optional person for questions and failures under Contact settings. Assignment grants no additional access. Confirm that the intended project and capabilities appear before starting work, and turn off inherited connectors the automation should not use.
3. Run and inspect
Select Run now. The new execution appears under Latest run; earlier executions remain in History. Select Open run to inspect the full run: progress, evidence, tool calls, approvals, generated material, usage, and terminal result. The compact result shows execution status and each agent’s handover status separately. Beneath the opened result, each recipient's name links to its conversation. Subscribed agents are notified automatically. You can also use Nudge to request pickup of this specific result; Nudge sent is acceptance, while Received confirms the handover reached the agent's worker.
A successful final answer is not enough if the automation consulted the wrong source or delivered to the wrong destination. Correct the instructions, project context, connector availability, or tool policy and run it again.
4. Test the empty and failure paths
Run with input that should produce no action and verify that the automation exits cleanly rather than inventing work. Also test a missing or inaccessible input so the result explains the blocker and preserves useful evidence.
Where connector operation controls are available, keep writes ask-gated until these cases are predictable. Otherwise remove write access from the external account or keep the workflow interactive.
5. Add the schedule
Edit the automation and change Frequency to No repeat, Hourly, Daily, or Weekly. Daily and weekly schedules use the selected wall-clock time and browser timezone. Confirm the displayed next run before leaving the page.
Use Run now for additional tests even after scheduling. Pause or edit the automation when its inputs, destination, or responsible people change. See Automation schedules and runs for concurrency and missed-slot behavior.
An agent with edit access can also change the schedule for you. It can manage its own result notifications independently: keep informed, act on findings, or stop following. Stopping notifications leaves the automation and its run history available to everyone with access.