Guides

This is the recurring check pattern: every morning, an agent goes and looks at something, writes up what it found, and puts that in front of a person. Nobody has to remember, and the record of what was checked builds up in one conversation.

The example here checks a client's code repository for risky changes, because that's an example we can make concrete end to end. The shape is the same whichever thing you check: backups, patch compliance, unusual sign-ins, certificates about to expire. See pointing it at your own systems at the bottom.

One piece of advice before you build it. Ask for it by hand for a week first. A daily check that produces noise gets ignored inside a fortnight, and once your team has learned to ignore it, the day it finds something real you won't notice either. Get the signal right, then approve a routine.

What you'll build

• Scout inspecting a repository and writing up what it found.
• A review request, so the service desk lead sees the finding and can leave notes.
• A routine that repeats the whole thing at 08:30 on weekdays.

Before you start

• GitHub connected, with access to acme/api.
• An agent named Scout granted github.code.search, github.file.get, and mobius.self.list_users, and nothing else. Read-only, deliberately.
• A Mobius user to receive the reviews. You'll need their email address.

1. Ask for the check by hand

Start a conversation with Scout and ask for one run of it:

Search acme/api for risky changes around authentication, API keys, billing
checks, and webhook verification. Give me a risk summary, evidence links, and a
recommendation. If there is nothing worth reporting, say so in one line.

Read what comes back. Then read tomorrow's. This is the week that decides whether anyone will trust the check later.

That last sentence matters more than it looks. Agents are reluctant to say "all clear" unless you explicitly tell them it's an acceptable answer, and a check that always finds something is a check nobody reads.

2. Add the review

Once the finding is worth reading, add the human step to the request:

Same check, and when you're done, ask the platform lead to review it. Find them
with mobius.self.list_users by their email lead@northwind.example, and open a
request_review interaction with your note in it, asking them to mark it clear
or say what follow-up to open.

Scout writes the note, calls mobius.open_interaction, and the turn suspends. It costs nothing while it waits, and it survives a restart.

The reviewer sees it under Inbox in the left rail, reads the note, and answers. The turn resumes with their answer, and Scout can respond to what they said.

mobius.open_interaction is built in. There is nothing to grant for it.

3. Put it on a schedule

Still in the same conversation:

Do this every weekday at 8:30am, including the review request.

Scout answers with a proposal card. It states the instructions it will repeat, when it fires and in which timezone, who can see each occurrence, which connections it may act through, and the per-occurrence and daily spending ceilings.

Read the instructions line on the card. It is what actually runs, and it is the agent's summary of what you asked for rather than your words verbatim. If it dropped the review, say so and Scout proposes again.

Click Approve routine. Nothing is scheduled until you do.

Read it the next morning

Each occurrence is an ordinary turn in the same conversation: the 08:30 instruction, Scout's searches, its note, the review request, and the reviewer's answer, in order. Yesterday's check sits directly above today's, which is the record you wanted.

An occurrence that says skipped means the previous one was still running when this one was due. That happens when a review sits unanswered overnight, and it is usually the right outcome: one open review at a time.

If it gets noisy

It will, at first. Two fixes, in order:

Narrow what it looks at. A check across everything finds something every day, and most of it doesn't matter. One repository, or one risk area, produces a finding worth reading. Edit the routine rather than starting a new one.

Tell it what "nothing to report" looks like. Say plainly that an all-clear is an acceptable answer, and give it the one-line shape you want. The noise drops sharply.

A check reviewers trust is worth ten checks they skim.

Variations

Only bother a person when something's wrong. Tell Scout to open the review only when it found something, and to answer in the conversation otherwise. Clean days finish silently.

Post a digest instead. Grant slack.message.post and have it post the note when the team wants visibility but not a review queue.

Open a follow-up automatically. Grant github.issue.create and tell Scout to open an issue once the reviewer says to.

Give it a workspace. Use a managed environment when the check needs to download files and inspect them rather than just search.

Pointing it at your own systems

The pattern here has nothing to do with code. Swap Scout's tools and you have:

• A backup check. Read last night's backup results, flag anything that failed or didn't run, write it up.
• A patch compliance check. Pull device patch status, flag machines that are behind, group by client.
• A certificate check. List certificates expiring in the next 30 days.
• A sign-in review. Look at unusual authentication activity and summarize what's worth a second look.

If the system holding that data has an API, build a custom HTTP action to read from it and grant that action to Scout. If the data lands in a spreadsheet or a table instead, read it from there. Everything else in this guide stays exactly the same.

Next

• Understand what you approved: routines.
• Grant tools through tools and skills.
• Pause for review with interactions.
• Keep long checks bounded with guardrails.