Recurring responsibilities (in development)

Availability

Routines are in development and disabled by default. This guide describes the gated implementation, not a production availability or unattended-reliability promise. If your workspace has no Routines section, an ordinary chat message does not create a schedule.

A routine is an ongoing responsibility assigned to one agent, with a schedule, a reporting channel, success criteria, and reviewed permissions. CrewX keeps the calendar for both cloud agents and agents on your own machines.

That standing permission applies to the assigned agent. A routine cannot transfer its work to another agent just by mentioning it. If another agent is needed, a person must explicitly review and assign that work; an independent human follow-up remains a separate request.

In the development web and desktop clients, Handoff not started explains when a routine addressed another connected agent but did not start work for them. Send that agent a separate message with the task and scope if you want to request their help. Reading the notice does not approve work or change the routine. Ordinary reports and mentions used only as references do not show this notice.

Let an agent propose recurring work

During a task you requested, an agent can identify work worth repeating and prepare an inactive proposal. For example:

“Check our SEO every weekday at 9am in America/Los_Angeles. Post a report to #growth. Ask before changing production.”

The agent can supply the instructions and schedule through its CrewX routine tool. CrewX binds the proposal to the requesting person, assigned agent, and source conversation. The agent must ask about missing timezone or authority rather than inventing permission.

Agents cannot activate their own routines. Review the proposal and its next scheduled dates, then explicitly activate it. A running routine cannot recursively create more routines. Text found in a website, email, or repository grants no authority to create or expand a responsibility.

You can also create a draft through the Routines form when the feature is enabled.

Review before activation

Check the agent and reporting channel, instructions, success criteria, timezone, and next three dates. Daily, selected-weekday, and weekly schedules use an IANA timezone, rather than a fixed UTC offset.

Choose the permitted work:

Mode	Intended work	Additional requirements
Observe	Read and report	Access to the sources and an inspectable result
Propose	Prepare scoped changes and draft PRs	Reviewed repository, paths, and provider connection
Operate	Perform explicitly authorized operations	Separate merge/deploy permissions and independent server checks

Choosing Operate alone does not authorize every action. A green CI check does not grant deployment permission. Provider connections do not establish a Google, Microsoft, or other account for an agent. See access and handover.

Limits cover execution time, waiting, lateness, attempts, and supported provider operations. The model-spend field is currently a target, not an enforced dollar cap. Independently granted shell, browser, subscription, or API credentials are outside CrewX's protected provider executor. The routine policy is not an operating-system sandbox.

Cloud and local execution

CrewX stores each scheduled occurrence on the server. Keeping a browser or desktop app open is not the scheduling mechanism. Actual execution still requires the deployed scheduler, queue services, and an available agent with the required access.

A local agent needs its enrolled machine and Bridge to be available. When it is offline, the occurrence waits within its deadline. CrewX does not silently substitute a cloud agent. A cloud agent likewise needs a working provisioned computer and runtime.

Each occurrence has separate work context. A continuation after a supported wait resumes that occurrence. When work overlaps its next due date, CrewX records missed dates rather than launching an unlimited backlog.

Live sleep, reconnect, process-loss, and all-harness acceptance remain release requirements. Shared APIs and adapter tests alone do not prove these cases.

Follow results and requests for help

Open a routine to inspect its schedule and individual runs. Shared History lists completed occurrences separately, including repeated runs of the same responsibility. Original revision and timezone remain with their run records.

Worker completion may still need verification. An unresolved external action remains visible even if the occurrence has ended. A deployment being live, a page responding, and an SEO improvement are different findings.

The owner-private routine inbox retains requests for help and selected result notices. Its preference controls normal outcome notifications; required attention still appears. Marking a notice read does not approve work, return computer control, or resume a run. This inbox does not promise email or push delivery.

Change or stop a responsibility

Pause a responsibility to stop future scheduling. Editing creates a new inactive revision that needs review and activation. Cancel an active occurrence explicitly when it must stop. Archiving retains history.

When CrewX cancels a still-active assignment, its chat delivery label changes to Cancelled instead of continuing to show it as queued or working. A worker that had already completed keeps its completion evidence; that does not mean the routine passed verification. The routine's history records the occurrence outcome separately, including deadline expiry.

Cancellation cannot undo an external write already sent. If a provider response is uncertain, inspect the retained action and recovery state before retrying. CrewX's supported recovery checks existing effects instead of assuming a timeout means nothing happened.

Before using routines for production changes

Occurrence history distinguishes confirmed model spend from unresolved reserved exposure when managed request accounting is available. Missing attribution does not mean a run was free. An unresolved-charge notice asks for billing review; marking it read does not release the reservation or resend the request. These measurements do not yet cover every runtime or enforce the model-spend target.

The development build also provides Model usage attention for workspace owners and administrators. It covers unresolved routine, conversation and task charges, even when new routines are disabled. Review holds shows reserved credits and a support reference, not private work or credentials. Copy the reference for CrewX support; refreshing the panel never retries work or releases credits. This financial panel has no mark-read action. Native GUI and live-provider acceptance remain part of the unreleased work.

The development branch includes scoped GitHub draft/merge and Render deployment/checking paths. Full release acceptance still requires compatible rollback, merge-queue and revision recovery, request-level spend enforcement, live cloud/local and native UI coverage, and a real multi-day unattended test. An SEO example is not evidence that all integrations or an automatic merge/deploy loop are ready.

Start with a small report whose sources and output you can inspect. Expand standing authority only after verifying the exact workflow. See tasks and approvals for accepting work and permissions and safety for access boundaries.