Implementation
Background agents
Cron agents read the project on a schedule and propose what they find as new change requests.
Purpose
Some work never reaches the top of anyone's list: a missing test for a failure path, a dependency with a known weakness, a decision the code makes that the working model never recorded, a page that slowly got heavier. Teams that wait for someone to notice these usually notice them late. A regular, narrow check finds them while they are still small.
Roko Platform runs such checks as cron agents. Each one reads the project on a schedule, looks for one kind of problem, and proposes each problem it confirms as a new change request. It never changes code or the working model itself. People review its change requests like any other.
The cron agents
Mon · 09:00
Test Coverage Analyst
Missing high-value tests the Quality Plan calls for.
0 9 * * 1
Tue · 09:00
Security Auditor
Security weaknesses in the working model and the code.
0 9 * * 2
Wed · 09:00
Librarian
Context the code makes clear but the working model does not record.
0 9 * * 3
Thu · 09:00
Frontend Performance Analyst
Frontend performance problems, measured on a local build.
0 9 * * 4
Fri, Sat, Sun: no runs by default.
| Agent | Default schedule (UTC) | What it looks for |
|---|---|---|
| Test Coverage Analyst | Monday 09:00 | Missing high-value tests that the Quality Plan calls for. |
| Security Auditor | Tuesday 09:00 | Security weaknesses in the working model and the code. It does not scan or fuzz. It may run the dependency audit and the project's tests. At most five change requests per run. |
| Librarian | Wednesday 09:00 | Context that the code makes clear but the working model does not record. It drafts a scoped change request for each gap. |
| Frontend Performance Analyst | Thursday 09:00 | Frontend performance problems. It reads the frontend, then measures the suspect pages against a local build with Lighthouse and Playwright, never against a deployed environment. At most three change requests per run. |
Before it proposes anything, each agent lists the project's change requests to skip problems that are already proposed. A run that finds nothing new opens nothing. That is a normal result.
What they produce
A cron agent writes only new change requests, and only change requests it created in the same run. Its instructions allow three tools for that: create_change_request, set_change_request_section, and upsert_change_request_model_change. The change requests arrive In review and appear in the project's Change requests list with the rest.
Scheduling and configuration
Open Agents in the sidebar, under Implement. The Registry tab lists the Cron agents and the Workflow agents, with the columns Agent, Schedule, Model, History, and Last run. Each cron agent row has these controls:
| Control | What it does |
|---|---|
| Enabled / Disabled toggle | Turns the agent on or off for this project. Agents are on by default. |
| Edit schedule | Opens the Schedule dialog. Enter a cron expression in UTC, or pick one of the Presets, then press Save schedule. |
| Edit model | Picks the model this agent uses. On its default, it uses the project's default model. |
| Run | Starts a run now, outside the schedule. |
| View prompt | Shows the agent's system prompt. The prompt is defined in code and is read-only. |
The Runs tab lists every agent run in the project. Each run has its own Agent run page with its transcript.
How a run happens
- The platform checks every minute which agents are due in each project. It skips archived projects and disabled agents.
- It does not make up runs it missed, for example while the platform was down.
- A due run joins the same queue as implementation runs and has the same one-hour time budget. See Budgets.
- A cron agent needs a model, so the project needs a model provider. See Model provider.
Best practices
- Fill in the working model first. The agents compare the code against the working model. Test Coverage Analyst reads the Quality Plan, and Librarian looks for what the model does not record. With empty documents, they have little to compare against.
- Triage their change requests like any other. Accept what is worth doing, and close the rest with a comment that says why. The next run reads the existing change requests and skips duplicates.
- Turn off what does not apply. A project with no frontend has no use for Frontend Performance Analyst.
- Spread the schedules. The defaults run one agent per weekday so their change requests do not arrive at once. Keep that spacing if you change them.
- Read the prompt before you rely on an agent. View prompt shows exactly what the agent checks and what it ignores.