Scheduled agents

Scheduled agents run on a cron cadence — daily, hourly, weekly — and execute tasks based entirely on your custom instructions and enabled tools. Unlike triggered agents that react to a specific ticket, scheduled agents work without any PSA entity. They’re ideal for proactive operations like compliance audits, account hygiene, and recurring M365 administration.

Think of triggered agents as reactive (something happened, go handle it) and scheduled agents as proactive (go check on things, take action if needed).

Running the same job every week and want it to come out identical each time — same shape, same numbers, same format? Capture the procedure as a custom skill and point the agent at it. The skill freezes the exact steps so the output stops drifting run to run.

Triggered vs scheduled agents

	Triggered Agent	Scheduled Agent
Starts when	A PSA event occurs (ticket created, updated, etc.)	A schedule fires (daily at 8 AM, every hour, etc.)
Works on	A specific ticket or time entry	No entity — runs from custom instructions alone
Context	Ticket details, end client company, contact	MSP-wide context, available tools, custom instructions
Use case	Resolve issues, triage, communicate with users	Audits, hygiene, compliance, recurring admin tasks
Conversation	Continues across runs on the same ticket	Fresh conversation each schedule fire
Credits	Once per run, at the highest tier among the tools you chose	Each tool call at that tool’s tier. A run with ten API calls costs ten times one call.

A scheduled agent without a ticket is not billed like a ticket-triggered agent. The builder’s Built-in Capabilities list (skills and always-on tools) shows no prices, and skills themselves are free to load — but every tool those skills use still spends credits. External API Request is 3 credits per call. Test mode blocks writes; it does not stop billing. See Tool credit costs for the full table and a worked example.

How it works

Schedule fires

At the configured cadence (e.g., daily at 6 AM), the agent starts a new execution.

Agent reads instructions

The agent loads your custom instructions, enabled tools, and any loaded skills. There is no ticket to analyze — your instructions define the task.

Agent uses tools

The agent executes the task: querying M365 environments, searching documentation, running RMM scripts, or any other enabled tool.

Results and approvals

The agent can request technician approval (TIL) before sensitive actions, send notifications via Teams or email, and create tickets for issues it finds.

If the agent requests Technician-in-the-Loop approval or kicks off an RMM script, the execution pauses until the technician responds or the script completes. The agent then resumes with full context of what it was doing.

Setting up a scheduled agent

Create a new agent

Go to Workflows → Create and select Agent.

Set the trigger to Scheduled

Under Trigger, select Scheduled and configure your cadence (e.g., daily at 6:00 AM, weekly on Mondays).

There is no ticket filter to set

A scheduled agent has no Filters tab. Nothing is missing: a filter narrows the tickets that start a run, and a scheduled run starts from the clock instead. The agent chooses what to work on while it runs — see Choosing which companies a run covers.

Enable tools

Select the tools the agent needs. For M365 tasks, the relevant Microsoft 365 tools are auto-enabled based on your integration’s permission groups. This agent bills per tool call — check Tool credit costs before you enable write access or External API Request.Other commonly used tools for scheduled agents:

Search tools — Find Documentation, Find Tickets by Content/Metadata
Communication tools — Send Teams Message, Send Email
Management tools — Create New Ticket, Trigger or Schedule Workflow
Resolution tools — Execute RMM Script

Write custom instructions

This is the most important step. Your custom instructions define exactly what the agent does each run. Be specific about:

What to check or audit
How the agent picks the companies to work on — see Choosing which companies a run covers
What thresholds or criteria to act on
What action to take when issues are found
How to report results

See use cases below for examples.

Configure safety controls

Test mode: Start with test mode on. The agent will log what it would do without taking real actions.
Technician-in-the-Loop: Enable TIL on your M365 permission groups for any write operations. The agent will pause and request approval before making changes.
Access profiles: Use the Helpdesk or IT Admin preset to ensure TIL is required on sensitive operations.

Set the schedule and enable

Configure your schedule cadence, set execution windows if needed (e.g., only during business hours), and enable the workflow.

Choosing which companies a run covers

You say it in the custom instructions. That is the whole answer, and it is where the scope belongs. There is no Filters tab for a scheduled agent and you do not need one — a filter narrows the tickets that start a run, and a scheduled run starts from the clock instead. The agent finds its own companies and works through them.

Write the rule, not the list

The instruction can name a company outright:

Run this for Northwind Manufacturing.

For a set, describe the set instead of pasting the names:

Run this for every client whose "Monthly Reporting" custom field is set to Yes.
Read that list from the PSA at the start of each run.

A rule holds a few hundred companies in one sentence, and your PSA stays the list — so a client that joins or leaves is picked up on the next run with nobody editing the agent. A pasted list of names has to be maintained by hand and nothing tells you when it has gone stale. The one thing you do have to grant is the access: enable PSA API with the Companies permission group so the agent can read the list. Neo injects your PSA credentials at the network layer, so nothing in the run handles them, and every call carries the permissions you granted this agent.

Leave the method to the agent

You do not have to say how the work gets done, and you are better off not trying. Every agent has a sandbox — it is on by default, with nothing to enable — and Neo tells the agent when to use it. For a report across many companies, the agent writes a script. That script pulls each company’s data at once rather than one company at a time, and where the report needs written analysis it produces that inside the same script. A few hundred companies is an ordinary size for this. You do not need to break the job up on the agent’s behalf. A second shape exists for a different kind of work: when each company needs its own decisions and actions in your systems, rather than a section in a report, the agent can run parallel subagents. That one is capped at 50 companies per run, so it is worth knowing which kind of job you are describing. Reporting is almost never the second kind. A scheduled agent bills per tool call, so a wider scope costs more. Watch the spend on Billing for the first few runs rather than estimating it. The rule tells the agent which companies to report on. It is not a permission boundary — the agent can still read any company your integration reaches. Grant Read Only unless the agent has to write, and require Technician-in-the-Loop on anything that does.

Get it working, then freeze it

Ask Neo Support to run the agent for you and read the real output before the schedule fires, instead of waiting a month to see what it produced. Once a run comes out right, save the procedure as a custom skill. Later runs load the skill rather than rebuilding the approach, so the output stops changing between runs.

Use cases

Scan for new admin accounts

Goal: Detect unauthorized admin role assignments across M365 tenants daily.Tools: Microsoft 365 (Directory Roles, Audit & Reports)Custom instructions example:

For each connected M365 tenant:
1. List all current directory role assignments for privileged roles
   (Global Administrator, Exchange Administrator, SharePoint Administrator,
   Security Administrator, Privileged Role Administrator)
2. Compare against the audit log for role assignment events in the last 24 hours
3. If any new admin assignments are found, send a Teams notification to the
   security channel with: who was assigned, which role, when, and by whom
4. If no new assignments are found, do not send any notification

Disable inactive M365 accounts

Goal: Find and disable accounts with no sign-in activity for 90+ days.Tools: Microsoft 365 (User Management, Audit & Reports)Custom instructions example:

For each connected M365 tenant:
1. Search for user accounts where the last sign-in date is more than 90 days ago
2. Exclude service accounts and break-glass accounts (accounts containing
   "svc-", "breakglass", or "emergency" in the display name)
3. For each inactive account found, request technician approval before disabling
4. Once approved, block sign-in for the account
5. After processing all accounts, send a summary to the IT Admin Teams channel
   listing accounts disabled and any that were skipped

Always enable Technician-in-the-Loop for agents that disable accounts. A misconfigured filter could lock out active users.

Rotate admin and service account passwords

Goal: Monthly password rotation for privileged accounts.Tools: Microsoft 365 (Security, Directory Roles), Generate PasswordCustom instructions example:

For each connected M365 tenant:
1. List all users with Global Administrator or Privileged Role Administrator roles
2. Also list any service accounts (accounts with "svc-" in the display name)
3. For each account, generate a new secure password and request technician
   approval before resetting
4. Once approved, reset the password
5. Send the new credentials securely to the designated admin contact via
   a secure link
6. Log a summary of all rotated accounts as an internal note

Weekly documentation audit

Goal: Identify outdated KB articles based on recent ticket trends.Tools: Find Documentation, Find Tickets by Content, Send Teams MessageCustom instructions example:

1. Search recent resolved tickets from the past 7 days for recurring topics
2. For each topic, search the documentation library for related KB articles
3. Flag any articles that haven't been updated in 6+ months but relate to
   a topic with recent ticket activity
4. Send a summary to the documentation-review Teams channel with article
   titles and the ticket topics they relate to

Stale ticket report

Goal: Weekly summary of tickets that haven’t been updated in 7+ days.Tools: Find Tickets by Metadata, Send Teams MessageCustom instructions example:

Search for all open tickets that haven't been updated in the last 7 days
Group by assigned technician
Send a summary to the service-desk Teams channel listing each technician
   and their stale tickets, sorted by age

Coming soon: Audit enterprise applications (app registrations and service principals). This capability is on the roadmap and will unlock additional scheduled agent use cases.

Best practices

Start with test mode

Enable test mode for your first few runs. Review the agent’s execution log in Executions to verify it’s doing what you expect before enabling real actions.

Enable Technician-in-the-Loop for writes

Any agent that modifies accounts, resets passwords, or disables users should require TIL approval. Use the Helpdesk or IT Admin access profile on your M365 integration to enforce this.

Be specific in custom instructions

Scheduled agents have no ticket to provide context — your custom instructions are the entire task definition. Include: what to check, how to select the companies, what thresholds trigger action, and how to report results.

Pick the right cadence

Match the schedule to the urgency of the task. Security audits might run daily, password rotations monthly, documentation reviews weekly. Avoid running more frequently than needed.

State the scope as a rule, not a list of names

The custom instructions are where you say which companies a run covers. For a set, write the rule — “every client whose Monthly Reporting field is Yes” — and let the agent read that list from your PSA each run. A pasted list of names has to be maintained by hand. See Choosing which companies a run covers.

Getting started

Core

Triggered & Scheduled Agents

Chat Agents

Integrations

Product

Workflows

Customizing Neo

Triggered vs scheduled agents

How it works

Setting up a scheduled agent

Choosing which companies a run covers

Write the rule, not the list

Leave the method to the agent

Get it working, then freeze it

Use cases

Best practices

​Triggered vs scheduled agents

​How it works

​Setting up a scheduled agent

​Choosing which companies a run covers

​Write the rule, not the list

​Leave the method to the agent

​Get it working, then freeze it

​Use cases

​Best practices

Triggered vs scheduled agents

How it works

Setting up a scheduled agent

Choosing which companies a run covers

Write the rule, not the list

Leave the method to the agent

Get it working, then freeze it

Use cases

Best practices