# Build a recurring AI agent and put it on a schedule By the end of this guide you will have an AI agent that knows one job, has exactly the access you decided to give it (no more), and runs on its own on a schedule you set. Think of a "Monday morning review" that reads last week's plans and drafts a summary before you sit down, or a "tidy my inbox notes" agent that proposes cleanups every evening. The point is not magic automation. It is automation you can trust, because you set the permissions first and you can read back exactly what each run did. The order here matters. You connect a provider, then save the agent and lock down what it can touch, then test it on real material before you trust it, and only then hand it the keys to run unattended. Permissions come before the schedule on purpose: an unattended agent is only as safe as the access you gave it while you were watching. Each step below links into the reference page that owns the exact mechanics. Follow those links when you need the precise fields and switches. This page is the path through them. ## Step 1: Connect a provider An agent needs an AI to run on, so this comes first. Undra does not have its own AI brain. It connects to one you choose: a Claude or ChatGPT subscription you already pay for, or a free model running locally on your own computer. Why first: everything after this assumes a working provider. If you skip it, your agent has nothing to think with. Walk through [Setting up AI](/docs/getting-started/setting-up-ai/) to turn AI on and connect a provider. Once you can chat with AI, you are ready for the next step. Your agent will run on whatever provider you connected here, so there is no separate model to wire up for a basic agent. :::tip Picking a provider for unattended work If the agent will run on a schedule while you are away, a connected subscription (Claude or ChatGPT) is the smoothest path, since it does not depend on a local model app being open. A local model works too, but it has to be running when the routine fires. ::: ## Step 2: Save the agent and decide what it can touch Now create the agent itself. An agent is a saved job: a standing set of instructions plus the skills and permissions it should always carry. The whole reason to save one instead of retyping a prompt is that it becomes reusable, understandable, and, crucially, governed by permissions you set once. The full create flow (where agents live, the fields you fill in, and what each one does) is on the [Agents](/docs/workspace/agents/) page. Two parts of that page matter most for a recurring agent: - **The instructions are the job.** Write the brief as standing instructions: "every time, do X, then Y," not "this time, do X." Whatever you used to type into the chat every Monday goes here once. Attach any skills it should always apply so its guidance is baked in rather than remembered. - **The permissions are the guardrails.** This is the part you cannot skip before scheduling. The Agents page covers each switch in detail; the dial that matters is read-only versus propose-edits. ### Read-only or propose-edits Decide up front how much rope the agent gets, because once it runs on a schedule you are not standing over it. - **Read-only** lets the agent read your workspace and answer or summarize, but it has no way to change anything. This is the right starting point for a review, research, or digest agent. If all you want is "read last week and tell me what happened," stop here. - **Propose-edits** lets the agent draft real changes, but they arrive as proposals you review and approve rather than silent writes. This is the right setting for a "tidy this note" or "draft release notes" agent. The [Agents permissions section](/docs/workspace/agents/) explains exactly which switches produce each of these, and that Undra enforces them at the point the agent runs, not just as a polite request in the prompt. Turn on what the job needs and nothing more. :::warn Set permissions before you automate, not after A permission you forgot to tighten is a small thing while you are watching every run and a real one while the agent runs unattended at 7am. Get read-only versus propose-edits right here, before Step 4, so the schedule inherits a safe agent rather than a loose one. ::: ## Step 3: Test it on real context Before you trust an agent to run on its own, watch it run once. Give it a sample request close to the real job and read what it produces. The [Agents page](/docs/workspace/agents/) describes the built-in test panel; the important property is that test runs are read-only and cannot change your files, so you can iterate on the wording safely. Why this step exists: a prompt that reads well in your head often misbehaves on your actual notes. Testing on real workspace context is where you catch a brief that is too vague, an agent reaching for context you did not expect, or output in the wrong shape. Fix the instructions, run again, repeat until the output is the thing you would have written yourself. If you chose propose-edits, this is also where you see the propose, review, apply loop in action: the agent surfaces a proposed change, you read exactly what would be written, and you decide. Get comfortable with how its proposals look now, while you are present, so an unattended run later holds no surprises. ## Step 4: Put it on a schedule A tested, permission-bounded agent is now ready to run without you. Turning it into something that fires on a daily or weekly schedule, or at a regular interval, is the job of a routine. Routines, schedules, and the run record live on the [Workflows](/docs/workspace/workflows/) page. That is where you set when it runs and connect your agent as the step that does the work. The agent carries the same instructions, skills, and permissions you just set, so scheduling does not loosen anything: a read-only agent stays read-only on a timer, and a propose-edits agent still surfaces its changes for review. Why a routine instead of just remembering to run it: the value is consistency and a record. The job happens whether or not you think of it, in the same shape every time, and each run leaves something you can read back. ## Step 5: Inspect a run afterward The last habit to build is reading the run record. After an agent has run on its own, do not take the result on faith. Open the run and see what actually happened: its status, how long it took, what each step produced, and what, if anything, got written back into your workspace. The [Workflows](/docs/workspace/workflows/) page details the run inspector. Use it for two things: confirming a good run really did the job, and, when something looks wrong, tracing back to the exact step that produced the bad output instead of guessing. A scheduled agent you never inspect is a black box. A scheduled agent whose runs you skim is a teammate you can trust. :::note The run is the receipt, not the backup The run record explains how a result got made, but the saved notes and plans are the durable thing. Treat the inspector as the account of what changed, and keep the actual items as the result you rely on. ::: ## Where to go next - **[Agents](/docs/workspace/agents/)**: the full create flow, every permission switch, and the test panel. - **[Workflows](/docs/workspace/workflows/)**: routines, schedules, and how to read a run record. - **[Local-First Trust](/docs/workspace/local-first-trust/)**: why a permission-bounded, inspectable agent is safe to leave running.