Key Takeaways
- A scheduled agent works with no one watching, so its limits need to be settled before the first run.
- Agents grounded in an indexed, permissioned corpus can answer cross-system questions that tool calls alone handle poorly.
- Unattended runs should fail closed: actions that send, change, or delete wait for a person, and anything unplanned is refused.
- Every claim should trace to a source passage, and every run should stay open for review.
Putting an AI agent on a schedule takes about a minute. You write the instruction, pick a time, and save. The harder part is deciding what that agent may do overnight, while it works through your documents and nobody is around to stop it.
If a new colleague were about to start on the night shift with access to your files, you'd want a short conversation first. What can you open? Who signs off before anything leaves the building? Where will I find your work in the morning? A scheduled agent deserves the same interview, and most of the answers have less to do with the model than with the infrastructure around it.
A scheduled agent, for the purposes of this piece, is an AI agent given a standing instruction and a recurrence, such as "summarize the documents added to this project today" or "check new contracts for renewal clauses every Monday." Each run behaves like a conversation with the agent, except that no one is in it. What follows are the questions we'd ask before letting one run in a regulated environment, starting with the groundwork that decides how useful the agent can be at all.
What Does a Scheduled Agent Know About Your Business?
Only what it can reach, and only as well as it can search it. An agent connected to your systems through tools looks things up one system at a time. An agent grounded in an indexed corpus of your documents searches across all of them at once, with consistent ranking, classification, and permissions. For recurring work, that difference shows up in every run.
Take an instruction that sounds simple: every Monday, summarize what changed in our credit policies and flag anything that affects open deals.
To do that well, the agent needs to find every relevant document, wherever it lives. In a typical bank, the policies sit in SharePoint, the deal memos in a document management system, and the external changes that prompted the update arrive through a regulatory feed. An agent that reaches these through tool calls asks each system a question through that system's own search box, with its own ranking, its own result limits, and its own idea of relevance. Three systems, three notions of what "relevant" means.
A retrieval index built over all three changes the question. Documents are ingested once, broken into passages, and ranked by the same logic regardless of where they came from, so "everything that changed in credit policy since last Monday" becomes a filtered query across the whole corpus. The agent spends its effort reading the right passages, instead of hoping each system returned the right top results.
Ingestion is also where structure gets added. A classification step can tag each document with the counterparty, product, or regulation it concerns, which makes "every deal memo that mentions this facility type" something the agent can filter for. Where an organization maintains a knowledge graph, the agent can go a step further and follow relationships the documents only imply: a policy change affecting one counterparty can be traced to its subsidiaries and to the deals booked against them, a connection that keyword search alone tends to miss. The graph sharpens the answer. The agent runs on grounded retrieval without one.
Scheduled work gets one more benefit from the index, which is consistency. Because the agent searches the same corpus with the same logic every week, this Monday's summary is comparable to last Monday's. If this week's summary is longer, it's because more policies changed.
All of this assumes the agent respects who may see what, and can show where each claim came from. Both get their own question below.
Where Does It Run, and on Which Model?
Two further decisions are made long before the first run. The first is where the agent and its index live. Depending on an organization's security and sovereignty requirements, that can be a virtual private cloud, an on-premises data center, or an air-gapped environment with no connection to the internet at all. For an agent working through sensitive material with nobody watching, keeping the corpus inside a boundary you control is the simplest answer to the question of where your data goes overnight. Our six questions on sovereign AI infrastructure go deeper on that choice.
The second is which model does the work. An LLM-agnostic platform lets you set the model per agent by policy, and a subagent handling one part of a job can run on a different model from the agent that called it. Routine triage can go to a fast, inexpensive model, with a stronger reasoning model reserved for the synthesis at the end. Schedules compound this choice. A task that runs every weekday runs about 260 times a year, so a model that costs twice what the job needs costs twice as much 260 times over. And when a better or cheaper model arrives, or a provider changes its terms, the workflow moves with you.
Whose Access Does It Use?
A well-built scheduled agent retrieves under its owner's permissions, inherited from the source system and applied before the model reads a word. Each run acts as the person who created the task, so it can reach the documents and tools that person can reach, and nothing beyond them.
Picture a weekly digest of new documents in a shared project, set up by a team lead in operations. During the same week, HR uploads a draft restructuring memo to a folder that three people can open. The digest runs at the end of the week and never mentions the memo, because the team lead can't open that folder, and neither can anything acting on her behalf.
Two mechanisms make that work. The first is identity: each run acts as the task owner. A shared service account with wide access would be easier to set up and much harder to defend in an audit.
The second is that permissions travel with the documents. When content is ingested from a source such as SharePoint, the connector records which users and groups can open each item, and every search is filtered against those entries before results reach the model. For this to hold, people sign in to the AI platform through the same identity provider that governs the source system, so the platform knows that the person asking is the person SharePoint knows. Security teams already apply the principle of least privilege to people, as in control AC-6 of NIST SP 800-53, and this extends it to the agent working on their behalf. Our guide to fine-grained access control for AI covers the mechanics, and AI governance: what it is and where it gets enforced places them in the wider control stack.
One design decision stays with you. A digest reflects its owner's access, so if it's forwarded to a wider group, the recipients may read summaries of documents they couldn't open themselves. Who owns a team's scheduled tasks deserves the same thought as who owns a shared mailbox.
How Far Can It Be Talked Into Going?
No further than its configuration allows. Scope and model choice are set by policy, and no request can widen them, however politely it's phrased. That includes instructions hidden inside a document the agent happens to read.
The fear here has a name. Prompt injection, ranked first in the OWASP Top 10 for LLM Applications 2025, covers text crafted to redirect a model, including text planted in files the model reads, and an agent reading hundreds of new documents a week makes a natural target. The defense that holds up is structural, in the form of settings a request cannot change. We've written more about why the threat to AI agents sits inside the perimeter.
In practice, an administrator can lock an agent to a defined slice of the corpus, such as one regulatory domain or one client book, and that lock overrides anything a user or a request asks for. Knowledge graphs outside an agent's scope can't be queried, even by a call that names them directly. The set of permitted models can be locked for the whole project and narrowed further for each agent, and an agent can never widen it.
What Needs a Human Signature?
Anything that sends, changes, or deletes something outside the conversation. When such an action comes up and no one is present, a well-built agent parks the run and waits for a person to approve it. An action that nobody wrote a rule for is refused.
Consider an overnight task that prepares a weekly update for a client portfolio and has permission to email it. Reading positions, searching the client file, and drafting the message carry little risk, so they run without interruption. Sending is different. When the agent reaches the send step, the run pauses with the draft ready, and a relationship manager approves or rejects it when she gets in. If she approves, the run picks up exactly where it stopped.
Behind that behavior sit approval rules, matched by the name of each action. A rule gives a sensitive action one of a handful of answers:
- Allow the action without asking.
- Refuse it, and let the agent plan around the refusal.
- Ask the person in a live conversation before it runs.
- Defer it, parking the run until someone approves it later.
- Hide the tool entirely, so the agent never tries to use it.
The default is what makes this safe for unattended work. When an action needs approval and matches no rule, a live conversation asks the person in it, while a scheduled run, with nobody to ask, refuses. Approval policy is set centrally for the whole project, and the rules attached to an individual task can only make it stricter. A task can defer an email the project would allow, but it can't approve a deletion the project refuses. A scheduled run also can't create or reschedule other tasks, and it can't change the agent's configuration, so one task can never spawn a chain of others.
An action no one planned for should be refused when no one is present. A platform that defaults the other way has made that choice on your behalf. OWASP lists excessive agency as LLM06 in its 2025 Top 10, and requiring a human to approve high-impact actions is among the mitigations it recommends. For a worked example of where those approval points sit in a real process, see human in the loop for AI agents.
Agents act only through the tools an administrator assigns. Actions that send, change, or delete can require approval, and an unattended run parks until a person approves or rejects the call. Approval policy is set centrally, and individual tasks can only tighten it.
Can You Check Its Work?
You should be able to, line by line. Every claim in a scheduled agent's output should trace to the passage it came from, and every run should stay open for review afterward, so the person reading Monday's summary can check any sentence in it.
Where did this number come from? With a grounded agent, the answer is a citation that opens the source document at the highlighted passage, with its origin and creation date shown alongside. A run record worth trusting lets you retrace four things:
- The sources. Each claim linked to the passage it rests on.
- The run. Each run kept as a conversation you can reopen and read in full, and retry if it failed or stopped partway.
- The configuration. The instructions, tools, and limits the agent ran under, reviewed and versioned before they were deployed.
- The telemetry. Traces and logs that the platform team can feed into its existing observability tools.
For high-risk systems, Article 12 of the EU AI Act requires that the system technically allow events to be logged automatically over its lifetime. Many scheduled agents will fall outside that category, but it's a sensible benchmark for what a run record should capture. AI audit trails: what happens when the regulator calls walks through the same question from the examiner's side, and why auditability is the foundation of agentic AI makes the broader case.
Audit records vary in depth between platforms, and between deployments of the same platform. The practical test is to ask for a real one: pick a completed run and see how long it takes to get from a sentence in the output to the passage behind it.
What Happens When Something Changes?
The next run should reflect it. When a document is withdrawn, a person's access changes, or the agent's configuration is updated, a well-built platform carries the change through before the agent runs again, so last month's state doesn't leak into this month's output.
A policy is withdrawn. A compliance team replaces version four of a policy with version five and deletes the old file. Most teams have a colleague who always knows which version is current, and a scheduled agent needs its index to do the same job. When the ingestion pipeline detects deletions at the source, the old file leaves the index and the next digest stops quoting it. The same mechanics support data protection obligations such as the right to erasure under Article 17 of the GDPR, where a deletion needs to reach every copy of the data, including the one an AI system searches.
The owner leaves. Because each run acts as its owner, a task whose owner loses access to the project stops producing results. Access never outlives the person it was granted to. That's the right failure mode, even if it occasionally means someone has to recreate a useful digest.
The configuration is updated. Changes to agents, tools, and approval rules are written as configuration, checked before deployment, and versioned when they go live. A scheduled task always runs on the configuration currently deployed, and running a task never changes it, so what runs overnight is what the platform team reviewed and released. If a change needs to be undone, the team redeploys the previous version from its own repository.
Where Does the Work Land?
Ideally, wherever the team already works. The same index that grounds the agent can feed search, chat, and dashboards built for a specific team, and each viewer sees only what their own permissions allow.
The traditional destination for a recurring report is an inbox. A PDF arrives on Monday morning, gets opened by the people who asked for it, and is then filed somewhere sensible by people with good intentions. A few months later, the report is still arriving, and everyone has a rough idea of what it says.
A different pattern puts the output where the work happens. A legal team gets a dashboard tracking new legislation beside the agent's weekly summaries, and a research team gets an analytics view over the same corpus. Each dashboard is built around one team's questions, and it can sit next to a chat panel that answers follow-ups with citations. Because every query runs under the viewer's own session, two colleagues opening the same dashboard can see different documents, each seeing what they're cleared for.
The work that goes into ingesting, classifying, and permissioning the corpus serves every one of these surfaces. It also supports agents built for specific jobs, from helping sales reps find the right content to showing compliance teams what's missing from their controls.
What Should You Ask Before You Press Schedule?
Put the six questions above to any platform before an agent runs unattended, and ask for evidence alongside the answers. A real run record is a good start, and so is the same dashboard opened by two people with different access.
Most of the answers will come from the infrastructure underneath the agent: the index it searches, the permissions it inherits, the approval rules it can't loosen, and the record it leaves behind. A strong answer to each is specific enough to demonstrate on screen. Projects that skip these questions tend to stall later for the reasons covered in why agentic AI projects fail.
We started with the idea of interviewing an agent before it takes the night shift, and that's still the best way to run the evaluation. If you'd like to interview ours, talk to our team and bring the scheduled task you'd least like to leave unattended.
