Use a CI schedule when the job is deterministic and must be auditable, such as a scan or an export. Use an assistant's scheduled task when the work needs judgment over messy input, such as summarizing findings. Many good designs use both, with CI producing data and the assistant interpreting it.
The two approaches
A CI schedule runs a workflow file kept in your repository on a cron expression. An assistant scheduled task runs a saved prompt that a model interprets each time. Both start without a person, which is why they get confused. Their guarantees differ.
Side by side
| Question | CI schedule | Assistant scheduled task |
|---|---|---|
| Same input, same output? | Yes, if the steps are deterministic | No, model output varies |
| Change history | Version control, review on the workflow file | Product edit history, varies by product |
| Where it runs | Runners you choose | Vendor cloud or your machine |
| Access control | Repository and runner permissions, tokens | Account, connectors, permission mode or sandbox |
| Minimum interval | Five minutes on GitHub | One hour for Claude routines, one minute for local loops |
| Lateness | Can be delayed or dropped at high load | Jitter or several minute delay |
| Failure mode | Job fails visibly | Run succeeds but answer is wrong |
| Fit | Scans, builds, exports, checks | Triage notes, summaries, drafts, explanations |
Facts about intervals and delays come from GitHub's events documentation and Anthropic's scheduling pages, read on 19 October 2026. GitHub scheduled workflows also run only on the default branch and in public repositories are disabled after 60 days without activity.
How to decide
- Can you write it as steps? If yes, put it in CI. Cheaper, repeatable and reviewable.
- Does the output become evidence? Prefer CI so the run is reproducible. A model summary is a draft, not a record.
- Does it read untrusted text? An assistant task adds prompt injection risk that CI steps do not have. Limit access accordingly.
- Does it act on systems? A workflow's permissions are explicit in the file. A task's access hides in connectors and settings.
- Does it need judgment? Reading ten advisories and deciding which matter is where a model earns its place.
A pattern that works
CI runs the scanner nightly, writes structured results, and posts them to a place the assistant can read. A scheduled assistant task reads the results, groups them and drafts a summary for a human. The scanner's result is the record. The summary is a convenience. If the assistant task fails or drifts, the evidence is untouched.
Keep both on a leash
Pin third party actions, use least privilege tokens and prevent script injection in workflows. For the assistant side, scope connectors and sandbox. Least privilege tokens for security automation covers the CI half.
Worked example: weekly vulnerability digest
A security team wants a Monday digest of open critical findings for leadership. They consider two designs.
Design one is a pure assistant task. A routine connects to the findings tool, asks the model to pull open critical items, group them by product and write a summary. It is quick to build. Problems appear in review: some Mondays the model groups by team, some by product; numbers in the summary occasionally disagree with the tool's own counts; and the run is green even on weeks when the connector returned an error and the model wrote a plausible paragraph from memory.
Design two splits the work. A CI scheduled workflow queries the findings system through its API, writes a structured file with exact counts and a list of items, and commits it to a reports repository on the default branch. A scheduled assistant task then reads that file, drafts a plain language summary with a fixed template, and posts it as a draft for the security lead to approve. The numbers come from deterministic code. The words come from the model. If the workflow fails, the file is missing and the assistant task says so.
Design two takes more work to set up and is easier to defend: the counts are reproducible, the report is evidence, and the model has less room to be wrong.
Questions that point to the right tool
| If this is true | Lean toward |
|---|---|
| The steps never change | CI schedule |
| The output is evidence you may need to reproduce | CI schedule |
| The input is messy text that needs interpretation | Assistant task |
| A person will read and edit the result | Assistant task is fine |
| The task acts on production | CI schedule with explicit permissions, or human approval |
| You need a precise start time | Neither, use an event or a proper job scheduler |
Security properties compared
CI workflows have a mature set of controls: version controlled definitions, required review of changes to workflow files, pinned actions, explicit token permissions and runner isolation. Assistant tasks have newer ones: permission modes, sandbox levels, connector lists, environments and organization toggles. Both require attention to who the identity is and what it can reach. Both start without a person and both can be forgotten. GitHub's own notes that scheduled workflows can be disabled after 60 days of repository inactivity on public repositories show that neither side is set and forget.
Cost of failure
A failed CI job is usually loud and visible. A failed assistant task can be quiet and plausible. When the cost of a wrong but confident answer is high, put a deterministic step in front of the model and a check behind it.
A migration path
Many teams start with an assistant prototype because it is fast. Once the task proves useful, move the repeatable parts into CI and leave the model with the interpretation. Use the prototype's transcripts to learn what the workflow needs to fetch.
Where the Safeguard CLI fits
The download page describes the Safeguard CLI as a single binary that can scan from a terminal or run in a CI/CD pipeline, so it can be the deterministic step in a design like the one above. The CLI can also write code, and the page lists a Local agent and a Cloud agent as Available.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch what a recurring check reports and how a change shows up between runs.
Quick check
Can an assistant task replace a scheduled scan?
Not as the system of record. A deterministic scan gives repeatable evidence. An assistant can help interpret the results.
Which is easier to audit?
A CI workflow, because its definition lives in version control and the steps are fixed.
Can I put both in one pipeline?
Yes. A common pattern is a deterministic CI job that produces data and an assistant task that summarizes it, with a human approving anything that leaves the team.
Sources
- Events that trigger workflows (GitHub Docs)
- Run prompts on a schedule (Claude Code docs)
- Automate work with routines (Claude Code docs)
Last reviewed: 19 October 2026.
