Emily sent me this post one day and asked if we were doing anything like it.
I’d been running scheduled agent jobs on my personal projects for a while, and Kilo has supported scheduled Cloud Agent runs under Webhooks & Triggers since roughly March. The honest answer was: sort of. We’d had maintenance jobs running in a limited capacity on a few areas, but nothing across our primary repo as a whole and nothing formal.
So I set some up. Each job is a Cloud Agent prompt on a cron. It clones the repo, looks for one kind of problem, and opens a PR with the janitor label. The one rule we gave every job to start with: don’t send twenty fixes, pick the single change you’re most confident about and send that. As we evaluate the prompts we’ll increase the frequency or allow more work per PR.
What’s running
Five jobs, four of them daily:
Code dedupe consolidates logic that got implemented twice.
Test pruning removes tests that don’t test anything. Agents love writing these: a test that asserts a mock returns what the mock was told to return.
Dead code removal finds functions and files with no references.
Orphan dependencies finds packages declared in the manifest that nothing imports.
Flaky CI fixer runs weekly, because our cloud repo’s test suite is stable enough that there isn’t much for it to do.
After about a week, the jobs had opened 39 PRs and we’d merged all 39.
I reviewed the initial test runs myself to make sure the models could handle the task. Beyond that, approval comes from the on-call developers’ agents, and the PRs are set to automerge on approval, so all anyone has to do is hit the button. A human rarely reads these line by line, and I don’t think they need to. The next job I want to add is a dedicated reviewer: every other day, go through the open janitor PRs, approve the ones that are obviously safe, kick the rest back to a person. That’s how I run it on my own stuff already, and it closes the loop completely.
The one we’re extra careful with
We use Sentry for error tracking. The obvious job is: every couple of hours, read the new errors, triage, fix what’s fixable. Better still, once we can trigger agents the moment an error occurs or a deploy goes out, a cloud agent can watch a rollout as it happens. The profile for it is built and scheduled triggers support profiles, so it’s ready to go.
This is the area to be careful with, because of prompt injection. Sentry client keys are semi-public, so anyone can send fake errors into the project, and an “error” the agent reads and acts on can be an instruction to leak a token or push something malicious. Our repo being public makes that worse.
The fix I’m looking at is a judge step, running the task past one of Enkrypt’s judge models before the agent acts. If you’re pointing an agent at anything outsiders can write to, treat that input as hostile.
Read more about Enkrypt AI Safety Scores in one of the recent blogs.
Two practical notes
Model choice. Most of these jobs run on cheaper models, DeepSeek and GLM Flash among them, because they run daily and the tasks are narrow. That’s fine for dedupe and dead code. For anything reading untrusted input, use a frontier model; they’re noticeably harder to manipulate, and the cost difference isn’t worth the risk.
Cost visibility. Kilo doesn’t show per-job cost for scheduled or webhook runs yet. My workaround: develop the prompt as a normal Cloud Agent session, where each run’s cost is visible, then move it to a schedule once I’m happy with it. The move is a copy-paste today, which is on the list to fix.
Webhooks are the interesting part
Scheduled runs are the easy case. As far as I know, Kilo is the only platform where an external event can start a cloud agent; Cursor has scheduled agents, but I haven’t seen anyone else do webhook triggers.
A webhook trigger means anything that can POST to a URL can wake up an agent: a CI failure, a new issue, a deploy finishing, a Sentry alert. Same machinery as the janitor jobs, different prompt, and the same caveats about what it’s allowed to read.
If you want to try it, Webhooks & Triggers are here. Start with one job, one PR per run, and read everything it opens for a few weeks before you trust it with more.
Separating the autonomy to investigate from the autonomy to change things is the cleanest boundary. Read-only passes can run continuously unattended, while the change stays a patch file an engineer reviews.