Crons

A cron sends a saved prompt to the projects you pick in a workspace, or to none, on a schedule. Each time it fires, Sensei starts one run covering all selected projects in a sandbox of its own. Every cron belongs to one workspace, or to you alone: see Personal crons. Create one from New cron in the workspace's … menu in the sidebar. Its Crons row in the sidebar opens the page where you read what every run did. Every workspace cron run spends the workspace's Credentials and credits, never a member's Subscription.

Create a cron

1. In the sidebar, hover the workspace's row, press its … and choose New cron. You can also open its Crons row and press New cron. This opens Crons / New cron.
2. Enter a name in the large field at the top.
3. Write the Prompt in the Markdown editor on the left. Type / or $ to pick a skill.
4. In Settings on the right, pick a Schedule. The Frequency tabs offer Hourly, Daily, Weekly, Monthly and Custom. Each preset fills the five crontab boxes, which you can edit. The schedule reads back in words with Next run ….
5. Check the next runs in the read-only Details box. It also shows the Workspace Timezone.
6. In Settings, pick the Model and Repositories.
7. Press Create. This turns the cron on and opens its page. Enter in the name or a crontab box also creates it. Cancel leaves without creating it.

The page starts on Daily at 09:00 (0 9 * * *), Default model, and the workspace's first repository, or the repository filtered in the list. The breadcrumb shows the workspace. A cron stays in its workspace, and you cannot move it to another one.

Errors appear in place: "Name is required.", "Prompt is required.", a crontab error, or "Could not create the cron."

The information tooltip beside Prompt explains what each run does and whose credits it spends. See Whose credentials a run spends.

Leave Model on Default to run on the workspace's default model. The picker lists only models the workspace's Credentials can run.

The Repositories picker lists every project in the cron's workspace, and no other. Search it, tick the projects you want, or press Select all. Picking none is allowed: the cron then runs without a repository. The cron keeps the projects you picked when you saved it. A project created later joins only when you edit the cron and add it.

With several projects picked, / offers only the skills every picked project has.

Frequency	Crontab	Fires
Hourly	0 * * * *	At the start of every hour
Daily	0 9 * * *	Every day at 09:00
Weekly	0 9 * * 1	Every Monday at 09:00
Monthly	0 9 1 * *	On the 1st of every month at 09:00
Custom	Your own	Five fields, in this order: minute, hour, day of month, month, day of week

A crontab is read in the Workspace Timezone. It may not fire more often than every 15 minutes.

If the create page says "Connect workspace Credentials to create crons", the workspace has no Credentials a cron can run on. Ask an admin to connect a provider in Settings > your workspace > AI Providers. Until then, Create stays off.

The Workspace Timezone

Every cron in a workspace runs in one timezone, the workspace's. A cron has no timezone of its own, so 0 9 * * * fires at 09:00 in the Workspace Timezone. Every cron time Sensei shows is in that zone too, whatever your own clock says: the next three runs, the next run, the times of past runs. A workspace starts on UTC.

The information tooltip beside Workspace Timezone says "The workspace timezone. Change it in Workspace settings."

Owners and admins set it in Settings > your workspace > General, under Timezone. Picking a zone saves it. Every enabled cron's next run moves to the new zone, except a cron that is already due, which fires on its slot first. Members see the zone but cannot change it. With the CLI, run kosuke workspaces timezone set.

Sensei refuses a new zone when it would make a cron fire more often than every 15 minutes, or never, and names those crons. Nothing changes then. Edit those crons first, then set the zone again.

What a run does

Each fire starts one run covering all selected projects in its own disposable sandbox. The Cron Agent receives the prompt word for word. It clones each repository's default branch at /app/projects/<slug>. It can edit the clones, run the project’s checks and commit there. A workspace Cron never pushes, opens a pull request or writes anything else on GitHub, and a Personal Cron does so only when its prompt asks (see What a run can reach on GitHub). Otherwise a code change becomes a ticket it sends as a message to a member's Sensei, with the patch in an Artifact. The main sandbox and its live checkout stay untouched. A clone failure is reported for that project; the other projects remain available.

On a Claude, Codex or Meta model the Cron Agent runs in its sandbox as a coding session's agent does: as root, with no folder it is kept out of. It can install dependencies, run builds whose tools write their settings and caches in its home (Wrangler, npm, Next), and commit in its clones. On a Grok or Gemini model it runs as a user of its own, which owns its clones and its home, so the same builds and commits work there too. On either, the run holds only its own Sensei key and its own GitHub token, never the sandbox's.

No live app runs in this sandbox. Checks against a public address must change nothing. When the prompt asks to test or QA the running app, the Cron Agent files a session in a Collaboration project, labels it cron-run, starts it, follows its first turn, reads what it found into its Reply and archives it. It starts one at a time, only its own, and never answers a session's question. A project needs no Deploy before a cron can run, and a Deploy does not interrupt it.

The sandbox and the edits in its clones disappear when the run ends. Save anything else that must survive in an Artifact, the workspace's Files, or a ticket sent as a message. The Reply, transcript, Artifacts and filed sessions survive. The Cron Agent never asks a Clarification. It states assumptions in its Reply. Work it hands over goes into a ticket sent as a message to a member's Sensei, which can draw a card for approval, unless the prompt explicitly asks it to file Backlog tickets directly. A workspace cron's Reports to (--report-to, up to ten members) names who those messages may go to: with one member, every message goes to them; with several, the run chooses among them; empty, it chooses any member. Sensei refuses a run's message to anyone else, and a run cannot change the list.

A run opens no chat session of its own and does not appear on the Tasks page. You follow it on the cron's page. A ticket it sends appears on the Tasks page only once a member approves it, in the Backlog, and a member starts the work. The sessions it files directly, under that explicit instruction, appear in the Backlog at once. When an earlier run in the same project filed a session that is still in the Backlog, it edits that ticket instead of filing the same work twice.

Sensei creates the sessions the Cron Agent files and is their Assignee. The member who starts one acts on GitHub in its first Turn: the commits and the pull request come from their connected GitHub account, or from Kosuke App if they have not connected one. Each session runs on the model the prompt names, or else on the cron's model. A session booked to Sensei shows as unread and "waiting on you" for every member. Every workspace session uses workspace Credentials, whoever starts or reassigns it. To take it over, start it or reassign it. Starting it makes you its Assignee before its first Turn, and a reassign takes effect from the next Turn. It keeps workspace Credentials and loads the new Assignee's Personal Skills and Plugins. A Cron Run that starts it leaves it Sensei's.

The Cron Agent reaches the Project Skills in the checkout and Sensei's own Factory Skills. Call a Factory Skill as /kosuke:<name>, or $kosuke:<name> with a Codex model. A plain /<name> means the Project Skill of that name, or the Factory Skill of that name when the project has none.

A cron runs only the Factory Skills that read and report. Today that is kosuke:web-pentest, a white-box security test of the project's code and its running app. In a cron it tests public app addresses, so it sends only requests that change nothing, and its report says what it could not check without a change. Its findings land as an Artifact on the run, and as tickets sent as messages when the prompt asks for them. For example:

/kosuke:web-pentest Then send every finding as a ticket in this project, one message per finding.

The other Factory Skills, such as kosuke:ship, kosuke:open-pr and kosuke:sync-branch, work on a chat session's branch, its pull request or a member's answers. The Cron Agent passes their call, word for word, to the ticket it sends, and does the same for a skill the project does not have. When running that skill was the cron's whole job, the run fails and says which skill it could not run.

A run with no project

A cron saved with no project fires as one run all the same, in a sandbox of its own and on the workspace's Credentials, with no clone. The Cron Agent is told it has no repository: it can use the workspace's Files, Artifacts and integrations, and it files no session. The app keys a message to a member's Sensei and an event to a project, so such a run sends no message and raises no event. Its failure shows on its run page and as the red dot on the Crons row.

What a run can reach on GitHub

A run reads its project's repository on GitHub with gh and git. A workspace Cron is signed in as Kosuke App, with a token that covers that repository alone. A Personal Cron uses its owner's own GitHub connection, which reaches what the owner reaches. Sensei renews the token for as long as the run works. A run can read pull requests, reviews, checks, Actions runs, jobs and their logs, and commit statuses where the installation grants them, as far as the Kosuke App installation's permissions go.

A workspace Cron's token is read-only, so the run itself cannot push, open a pull request, comment, label or review, in a YOLO project or a Collaboration project alike. Its commits stay in its clone. A prompt that asks for a GitHub write gets a ticket sent as a message instead, with the patch in an Artifact, or the run ends as Failed. Sensei's own write routes refuse it too: it cannot push, sync, merge, review, or open, close or move a pull request through kosuke. A chat session the Cron files and starts is another matter: it works with that session's own access, like any session. The test sessions a Cron starts are asked in their prompt not to push or open a pull request; Sensei does not enforce that ask. No Cron gives the go-ahead or sets a Merge rule. A Personal Cron uses its owner's own GitHub connection: it pushes, opens a pull request or comments when its prompt asks for it, and GitHub decides what that connection may do, by the repository's permissions and branch protection. Without that ask, a code change becomes a ticket as for a workspace Cron.

What a run gets depends on the project's installation:

Installation	What the run can read
Kosuke App with Actions and Checks permission	Code, pull requests, reviews, checks, Actions runs, jobs and logs
Without Actions or Checks permission	What the installation allows. Without Actions, no runs, jobs or logs. Without Checks, no checks
No GitHub installation	No GitHub clone for that project; other projects remain available

The run is told what it can and cannot reach, so it reports a gap as one instead of guessing. A prompt that needs data the run cannot reach ends the run as Failed. See Why a run fails after it starts.

Each clone has full history with file contents fetched as needed. The run never wakes or writes to a project’s main sandbox.

Each run spends credits for its Cron Agent and its own sandbox, including when it covers several projects. A run acts as the workspace, whoever created the cron or pressed Run now, and spends the workspace's Credentials. It reads the whole workspace and writes only in the projects it covers. It never changes the workspace's credentials, gives a go-ahead or deletes a project. A run has 5 hours and then fails.

A run can read platform traces and CPU profiles from the workspace’s Sentry connection. For example, search project:kosuke-core span.op:queue.process with kosuke integrations call sentry_search_spans. Read earlier agent work with kosuke_get_chat_session (jobs, transcript blocks and token totals), kosuke_get_cron_run (run token totals), and kosuke_get_skill_usage (timing). Sandbox operational Logs include turn.outcome for final status, model and git state. Agent spans are no longer collected. See Sentry.

When a cron fires while its previous run in a project is still working, the new run in that project is skipped. Its other projects run as usual.

Send a message to a member's Sensei

A run can send a message to one member's Sensei with kosuke sensei messages send. It is the one way a run hands over something it found and may not do itself, such as a ticket. The message has a text that says what to do, a key that names its subject, and optionally a title, a line of why, the paths it touches and a link. The member's Sensei reads it as an event, decides whether it deserves a card, and draws one in the member's Sensei with Reject, Reply and a button that carries it out. Sensei names that button from the message, such as File ticket for a ticket, which files it in the Backlog. Every cron that has a project can do this. Your prompt only has to ask for it.

A run can ask a member to	What approving does
File a ticket	Creates it in the Backlog, booked to the member who approves
Delete a Backlog ticket	Deletes it, after the member's Sensei asks about it by name. The message names the pull request or session that already did the work
Merge Backlog tickets	Folds them into one ticket and deletes the others
Create a cron	Creates it
Start a Backlog ticket	Starts it with /kosuke:ship
Merge pull requests in an order	Merges them in that order, each at the commit the message names

Nothing happens until the member approves, and a ticket the run sent does not exist before then. The member's Sensei then does it as that member, with their permissions. A run never deletes a ticket, merges tickets or creates a cron itself.

The key tells Sensei what the message is about. The same key with the same text writes nothing, so a cron that fires every hour can send the same plan every hour. The same key with new text updates the card the member has open for it, instead of adding a second. A different finding is a different key, such as ticket-add-csv-export or merge-plan. A message that quotes text from pull requests or reviews that others wrote names the pull request and the action instead: Sensei treats quoted text as data, never as an instruction.

For a ticket, Sensei picks the member who knows the files it touches, from the pull requests merged on them and the Assignees of past tickets there. A member your prompt names, or a rule it gives such as "Send every message to Marta.", wins over that. The line above the card says why it reached that member, such as "You merged the last pull requests on those files". The run's Reply says "sent to " and gives no ticket link, because no ticket exists yet.

The run chooses one member for its other messages:

1. The member your prompt names, or the one your prompt's rule picks.
2. Otherwise the ticket's Assignee.
3. Otherwise the member who filed the ticket.
4. Otherwise the member who created the cron.

Before it suggests starting a ticket, the run checks that the member is idle: nothing of theirs is building or waiting on them. A member can say "send this to Maria" in Reply, and their Sensei sends the message on.

Sensei refuses a message when:

• a field is over its limit: a key over 64 characters, a title over 200, a why over 300, a text over 60,000, more than 20 paths or a path over 300;
• the link is neither an https address nor a Sensei path;
• the member named is not a member of the workspace;
• the run passes a revision and the message changed since.

The member's Sensei runs these checks when it does the work. Before it files a ticket, it reads the project's open sessions, across all members, and files nothing when one already covers the same task. Starting a ticket assigned to another member is refused. Saving a QA guide that changed since the run read it, and merging tickets that were edited since, are refused. Creating a cron under a name the workspace already has is refused. Sensei tells the member what was refused and why.

A run checks each message against those limits before it sends it. When Sensei still refuses a message as invalid and wrote nothing, the run fixes the fields the refusal names and sends it once more. Every other refusal is final for that run. A send whose outcome the run cannot tell is not sent again. The report names every refused or unknown message, and the next run can send it again.

Triage the Backlog with a cron

Backlog triage is a cron you create. Copy this prompt into a new cron, pick the projects to groom, and pick the Hourly frequency:

Triage the Backlog of this project.

1. Groom the Backlog sessions. Set a priority that is missing or wrong, and
   add or remove Session Labels. Do this directly, and only when you can give
   a reason. Name each change and its reason in your report.
2. Read the code each ticket is about, so you judge it from the repository
   and not from its title.
3. Compare the Backlog with what merged. When a pull request or a session
   already did what a ticket asks, send a message with the key delete-<ticket> that
   asks to delete it, naming that pull request or session as the evidence.
4. When several tickets ask for the same thing, send one message with the key
   merge-<ticket> that asks to merge them into the clearest ticket and holds
   what all of them say.
5. When the same chore keeps coming back as a ticket, send a message with the key
   cron-<name> that asks to create a cron for it.

Change nothing else. When there is nothing to do, say so in one line.

The prompt names only the task. The Cron Agent already knows the commands. For a ticket it sends, Sensei picks the member who knows the files unless your prompt names one. Add a line such as "Send every message to Marta." to choose yourself.

What to know before you rely on it:

• The run sets priority and labels itself, as the workspace. Both are cheap to undo. Each change is in the run's Reply, not in anyone's Sensei chat.
• One run covers all selected projects. Save the cron with every project it should groom.
• It fires on its crontab whether or not anything changed, and every run spends the workspace's credits. Pick a slower schedule for a quiet Backlog. The fastest is every 15 minutes.
• Deletes, merges, new crons and tickets the run sends wait for a member to approve them.

Follow a cron and its runs

Each workspace has its own Crons page, opened from its Crons row in the sidebar. Its title reads the workspace's name, then Crons. The row is there for every workspace, also when it has no cron yet. Once it has one, the row shows how many it has, and a red dot when the last run of one of them failed. An old link to a cron or a run that has no workspace in it, such as /crons/..., opens the same page in the cron's workspace.

The Crons page lists every cron in the workspace, with its projects, schedule, model, next run and status. The Projects column shows the first project and +2 for two more. Hover it to see them all. You can search by name or prompt and filter by project, which keeps every cron that includes it.

Status	What it means
Enabled	The cron fires on schedule
Last run failed	The cron is on, and the latest run failed
Paused	A member paused it
Disabled	The cron turned itself off. Its page says why

Select a cron to open its page. The prompt is the main document on the left, rendered as Markdown, with Runs and Artifacts tabs below it. Settings on the right holds Enabled, Schedule, Model and Repositories. The read-only Details box has a lock icon and shows Next runs, Timezone, Created by and Created. Updated appears once it differs from Created. On the Runs tab, each run has a summary, its projects, a status, a duration and the time it ran.

Two filters on the Runs tab narrow the list. All projects keeps the runs of the projects you tick, and All statuses keeps the runs with the statuses you tick. Press Clear to show every run again.

Run status	What it means
Running	The Cron Agent is working
Succeeded	The Cron Agent finished and did what the prompt asks. The summary is the first line of its Reply
Failed	The run could not start, the Cron Agent failed or ran out of time, or the Cron Agent could not do what the prompt asks. The summary gives the reason
Cancelled	The cron's creator or a workspace admin stopped the run
Skipped	The previous run of the cron was still in progress, or another fire of the cron was already starting, so nothing started

Select a run to open its page. It shows the Cron Agent's transcript, its Reply, the Artifacts it wrote and, under Tasks it filed, each task with its status and whether it waits for an answer. It also shows the projects, the model and how long the run took. A run that failed shows the reason under Run failed, and keeps its Reply and Artifacts when it wrote them. In the Runs tab, a skipped run has no link to open and no transcript, because nothing started.

Cron Run videos are deleted 30 days after the run finishes and then show Video expired on <date>. Other artifacts stay readable.

To stop a run that is still going, press Stop on its page. The run ends as Cancelled. Its Artifacts and the sessions it already filed stay.

When a run fails, the app writes one event carrying all its projects in that cron's thread in the creator's Sensei. A run with no project writes none. The next successful run after a failure writes a recovery event, including a run on a different subset of projects. For causes the creator can fix, such as no AI provider for the workspace or credits at the limit, Sensei can draw a card with a way to fix the cause and close it on success. Cron runs that succeed or fail also appear in Activity for each covered project. See Cron cards. See Overview, Needs you and Activity.

Why a run fails to start

Reason on the run	What to do
No workspace AI provider is configured.	Ask an admin to connect workspace Credentials
Credit limit reached	See Plans and billing
No AI model is available for this cron.	Edit the cron and pick a model the workspace can run

Why a run fails after it starts

A run ends as Failed when the Cron Agent finishes but could not do what the prompt asks. That happens when a result the prompt wants could not be made because the run lacked the data or the means, such as GitHub access the project's installation does not give. The reason reads "The Cron Agent could not do what the Cron's prompt asks", followed by the first line of its Reply. Its Reply and Artifacts stay, and the run page shows the reason above the Reply.

A finding that the evidence shows nothing is not a failure. A report of "no flaky jobs in 14 days of runs" succeeds. A report of "flaky jobs: N/A, no access" fails.

A run fails the same way when the Cron Agent ends without saying whether it did the job. Its Reply stays.

Like any failed run, it counts toward disabling the cron. See When a cron is disabled.

When a cron is disabled

After 5 failed runs in a row, the cron disables itself and shows the reason. A successful run resets the count. Cancelled and skipped runs leave it unchanged. A red note under Enabled says why Sensei turned it off. Fix the cause, then turn Enabled on. This resumes the cron, resets the failure count and clears the note. Saving an edit also resets the count but leaves a disabled cron off.

When a project is deleted

Deleting a project removes it from every cron that includes it, while its runs and transcripts stay, naming the remaining projects. The cron's other projects keep firing. A cron whose last project is deleted stays, disabled, and its page reads "No projects left", though a cron saved with no project runs. Click Repositories, pick at least one repository and press Save. Then turn Enabled on. Resuming and Run now stay refused until a save picks a repository, and a save that picks none, such as a rename, keeps the reason.

Pause, resume, run now, edit or delete

On the cron's page, Share, Run now and Delete are in the header. Narrower windows fold them into one … menu. In the list, open the menu at the end of the row.

• Enabled in Settings acts at once. Turn it off to pause the cron. Turn it on to resume it and reset the failure count. The list's row menu still has Pause and Resume.
• Run now fires the cron once, paused or not, exactly as a scheduled fire would. It opens one run covering every selected project, or a run with no project when the cron has none.
• To run in only some projects, open the arrow beside Run now, or Run on some projects… in the list's menu. Tick the projects, then press the button, such as Run on 2 projects. The run covers only the projects you tick. A Personal Cron has a plain Run now button.
• Click the name in the title, the prompt, the schedule or the repositories to edit it in place. Each field saves alone with Save or Enter; use ⌘Enter (Ctrl+Enter on Windows and Linux) in the prompt. Cancel or Escape restores the old value. Picking a Model saves it at once. A short Saved appears beside the field. An error appears under the field that failed and keeps your change. Saving resets the failure count. Edit in the list's menu opens the cron's page.
• Share is an icon button that copies the link to the cron's page. The link opens for signed-in members of the cron's workspace.
• Delete asks you to confirm. The schedule stops, and its runs, their transcripts and their Artifacts are removed with it. The sessions its runs filed stay.

Any member can read every cron and its runs, and share its link. Only the cron's creator or a workspace admin can edit, pause, resume, run, stop a run of, or delete it. For everyone else, editing and those controls are disabled, and Stop is not shown.

Whose credentials a run spends

A run acts as the workspace: as Sensei, an admin of the cron's workspace, whoever created the cron. Activity names Sensei and the cron that acted. It spends the workspace's Credentials and credits, never a member's Subscription, the creator's included. So does every workspace session the Cron Agent files, including after a member starts or reassigns it. A cron keeps firing after its creator leaves the workspace. If the workspace loses its Credentials, each run fails with "No workspace AI provider is configured." See AI providers for whose credentials run what.

Cron sandbox time appears under Cron in workspace Usage.

Personal crons

A personal cron belongs to you and to no workspace. Open it from the Crons row of the Personal card in the sidebar. Its crontab is read in a timezone of its own, and it follows the same 15-minute minimum and five-failures rule. Only you read or change it.

Create a personal cron from New cron in your Crons list. It uses the same create page, with no repository picked and your browser's time zone. Its Time zone sits with Schedule in Settings and can be edited there. For a cron without repositories, Details shows Thread. The information tooltip beside Prompt explains where each run works and what it spends.

What a personal cron does depends on its Repositories. The picker lists your personal repositories and apps, and no workspace project. With or without repositories, Model offers Default and your Subscription models. Auto - Sensei free is also offered while you have no Subscription.

• With no repository, the prompt runs word for word as your message in the cron's own Sensei thread, on your selected Subscriptions or Sensei free. Without its own choice, it runs on the thread's model, or else your Default Model. Open thread appears once its first run has made the thread.
• With personal repositories or apps, the cron runs as one run of the Cron Agent in a sandbox of its own, as a workspace cron does. It clones each repository and can run its procedures and commit there. It pushes, opens a pull request or comments only when its prompt asks, with your own GitHub connection (see What a run can reach on GitHub); otherwise a code change becomes a ticket sent to your Sensei, with the patch in an Artifact. Its run page shows the Cron Agent's transcript, live stream, Artifacts and the sessions it filed. The editor offers the repositories' skills.

Connecting the first Subscription moves a Free thread cron to Default and a Free sandbox cron to the provider's catalog default model from its next turn. Removing the last moves both kinds of cron to Free. A running turn keeps its source. Limits, reconnects and provider failures never move it to Free. Each Free fire spends one prompt from your shared rolling 7-day allowance. With no prompts or no available Free account, the fire is skipped and records why. These skips never count toward the five-failure pause. If admission is refused before the runtime request is sent, the prompt returns and the fire is skipped. Failures after the request is sent count normally.

A sandbox run uses your Subscriptions, or Sensei free while you hold none, never a workspace's Credentials. Choose a Model your Subscription can run, or Auto - Sensei free with none. Sensei checks the Model when you save, and again whenever you change the repositories. An invalid choice is refused, with the error under the field you saved. A Model you can no longer run fails the run and counts toward the five failures, naming the Model. Sensei picks one Source for each Free Cron run and moves it automatically if the Source reaches its limit, is paused or is removed. The model, Source and provider stay hidden on its run page and live stream. The run acts as you inside your personal space: it reaches your personal integrations, the Personal space’s workspace integrations and your Personal Files, and no other workspace’s connections. Sensei Thread runs use the same integration reach. Connect workspace integrations for your own work in Settings > Workspace > Integrations, choosing Personal. Restricted integrations need a grant for that Personal space. Workspace Crons use their workspace’s integrations only, never their creator’s personal connections. Sensei pays its sandbox time.

At most two personal cron sandboxes run at once for you, apart from your three session sandboxes. A fire over that is skipped before any sandbox starts, says so, and does not count as a failure. Stop a sandbox run from its page. A personal cron raises no cron event and sends no failure notification: a failure shows on the run's page and as the red dot on the Crons row, which reads the latest run that was not skipped. Remove every repository and the cron goes back to its thread. Delete the last repository and the cron disables itself with "No projects left", as a workspace cron does.

Limits

• A crontab may not fire more often than every 15 minutes.
• A cron may have no project.
• A workspace session the Cron Agent files always runs on workspace Credentials, whoever starts or reassigns it.
• The agent inside a chat session acts as the session's Assignee, when the Assignee sent the turn. It can create, change, run, stop and delete crons as they could. When anyone else sent the turn, it acts as the workspace, like a run.
• A run sends a message that asks for a ticket, a delete, a merge or a new cron. It never does one itself, except that a prompt which says to file Backlog tickets directly makes it file them.

To create and manage crons from a script, see Schedule recurring work.

Next steps

• AI providers
• Skills
• Schedule recurring work