Scheduled and looping AI agents with rConfig MCP: choosing a runner
An agent you have to prompt is useful. An agent that checks the network every morning, or watches five devices every ten minutes during an incident, is useful without anyone remembering to ask. The playbooks in this section run on a schedule or in a loop, read rConfig over MCP, and report only what needs attention.
Best for: standing checks (drift, compliance, backups, advisories), watching a short list of devices during an investigation, anything you would otherwise check by hand every day. Tools: rConfig, an agent that can run unattended, and somewhere to send the result. rConfig tools used: all eight are read-only, so every playbook here can pre-approve them.
rConfig docsHow to connect an AI agent to rConfig V8 over MCPConnect Claude Code, Cursor, Gemini CLI, or any MCP-compatible agent to rConfig V8's read-only MCP server and generate an access token.Read the docs
Schedules and loops
| Schedule | Loop | |
|---|---|---|
| Starts | At fixed times, from cron, CI or n8n | From a prompt in an open agent session |
| Each run | A fresh agent with no memory of the last run | The same session, with the conversation so far |
| Stops | When you remove the schedule | When the session ends, or the loop expires |
| Use it for | Daily and weekly reports, overnight checks | Watching devices for a few hours during an incident or a change |
A scheduled run remembers nothing, so any comparison with “last time” needs state you keep yourself: a file in Git, a database row, or the previous report. Every playbook in this section says where its state lives.
Runners that work with rConfig
rConfig’s MCP server needs a client that speaks Streamable HTTP, sends a fixed Authorization: Bearer header, and can reach /mcp. These runners meet all three.
| Runner | How it repeats | Where it runs | Reaches a private rConfig | Shortest interval |
|---|---|---|---|---|
Claude Code /loop |
/loop 10m <prompt> in an open session |
Your machine | Yes | 1 minute; loops expire after 7 days |
Claude Code claude -p |
cron or a systemd timer | Your server | Yes | Whatever your scheduler allows |
Codex CLI codex exec |
cron or a systemd timer | Your server | Yes | Whatever your scheduler allows |
| n8n (self-hosted) | Schedule Trigger node | Your n8n server | Yes | Whatever the trigger allows |
| GitHub Actions | on: schedule cron |
GitHub’s runners, or your self-hosted runner | Only with a self-hosted runner | 5 minutes, and runs can be delayed |
Each runner’s own guide covers the connection: Claude Code, Codex CLI, n8n.
Runners with conditions
| Runner | Status with rConfig | Why |
|---|---|---|
| ChatGPT and Codex scheduled tasks | Doesn’t work | ChatGPT connectors support OAuth or no authentication and can’t present a custom API key, which is what an rConfig MCP token is. See ChatGPT and Claude on the web. |
| Cursor Automations | Only if /mcp is reachable from the internet |
Automations accept custom headers on HTTP MCP servers, but tool calls are proxied through Cursor’s cloud, not made from your network. |
Claude Code cloud scheduled tasks (/schedule) |
Not verified | They run in Anthropic’s cloud, at most hourly, so /mcp must be reachable from the internet. Anthropic doesn’t document passing a static Authorization header to a custom server from a cloud task. |
| Claude Desktop scheduled tasks | Check before relying on it | A local task is a Claude Code session in a local folder, so it should use that folder’s .mcp.json. It only runs while the app is open and the computer awake. Run the task by hand once and confirm rconfig is connected. |
Set up once, for every playbook
- Create a service user in rConfig, with a role that covers only the devices your scheduled jobs need. See Roles.
- Create an MCP token for that user (AI Center → MCP Server → New MCP Token, then Token for). Give it a name that says where it runs, such as “nightly drift check on ops-runner-01”, and an expiry you will remember to renew.
- Store the token in the scheduler’s secret store: a CI secret, an n8n credential, or an environment file readable only by the job’s account. Pass it as
RCONFIG_MCP_TOKEN. - Pre-approve rConfig’s tools so the run never waits for a person:
--allowedTools "mcp__rconfig__*"in Claude Code,default_tools_approval_mode = "writes"in Codex. - Give the job nothing else it doesn’t need. A scheduled agent with write access to chat or tickets should have only the tools to post its own report.
Writing prompts for unattended runs
A prompt nobody reads before it runs has to do more work than one you type:
- Name the scope: groups, tags or device names. “All devices” on a large estate means hundreds of history calls.
- Say what to do when there is nothing to report. “If nothing changed, output exactly
NO_CHANGES” lets the script skip the post. - Ask for a fixed format, ideally JSON, so a script can compare runs and decide whether to alert.
- Ask for evidence: backup times, version IDs and the lines that changed.
- Tell it to fail loudly: “If rConfig’s tools are unavailable or return an error, output
RCONFIG_UNAVAILABLEand stop.”
The playbooks
| Playbook | Runs | Runner |
|---|---|---|
| Nightly drift check against approved versions | Nightly | claude -p from cron |
| Incident watch loop | Every 10 minutes for a few hours | Claude Code /loop |
| Weekly compliance regression report | Weekly | n8n |
| Nightly advisory watch list | Nightly | GitHub Actions, self-hosted runner |
| Backup freshness and coverage audit | Daily, plus weekly | codex exec from cron |
| Hourly change reconciliation | Hourly | claude -p from a systemd timer |
For a plain daily summary of changes and compliance, start with Scheduled digests.
Related reference
- Connect an AI agent over MCP
- Roles and Permissions
- AI Center governance, audit trail and privacy
- Scheduled Tasks: the backups every playbook here depends on
Frequently asked questions
Can a ChatGPT scheduled task query rConfig?
Not today. ChatGPT's custom connectors support OAuth or no authentication, and OpenAI's documentation says ChatGPT cannot present custom API keys. rConfig's MCP server needs a bearer token, so there is no supported way to connect them. Use one of the runners on this page instead.
What is the difference between a schedule and a loop?
A schedule starts a fresh, unattended run at fixed times (cron, a CI schedule, n8n). A loop repeats a prompt inside one open agent session, such as Claude Code's /loop, and stops when the session ends. Schedules suit standing reports; loops suit watching something for a few hours.
Does a scheduled agent need a special rConfig licence or setting?
No. It is an ordinary MCP client. It needs an MCP token, a network path to /mcp, and an AI model of its own. rConfig's AI provider settings play no part.
How do I stop a scheduled agent seeing every device?
Create the MCP token for a dedicated rConfig user whose role covers only the devices the job needs. Every result the agent gets is limited to that user's devices.